The change on 2004-09-03 by ianw@gelato.unsw.edu.au appears to have
a typo, which causes builds of configurations which define both
CONFIG_VIRTUAL_MEM_MAP and CONFIG_DISCONTIGMEM to emit some 890
warnings for redefines of each of pfn_valid, page_to_pfn,
pfn_to_page.

This shows up compiling sn2_defconfig, the SN2 config of arch ia64.  I
believe that this is a simply typo, an extra "#else" line.  Removing
this exta line enables sn2_defconfig to build as before.

Acked by Jesse Barnes <jbarnes@engr.sgi.com>
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into kernel.bkbits.net:/home/davem/sparc-2.6

Signed-off-by: Pozsar Balazs <pozsy@uhulinux.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>

ip_ct_log_invalid was added without testing that it compiles without
CONFIG_SYSCTL.  Since sysctl is the only way of turning it on, there
should be no references to it if \!CONFIG_SYSCTL.  Also, that turns off
CONFIG_PROC_FS, which elicits more warnings.  Squish them too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

these are called by dev.c for every device (and nowhere else)
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

compat_sys_setsockopt() is a little overzealous about converting 32-bit
stuff into 64-bit. It should match on level _and_ optname, not just
optname. Currently it eats the IPV6_V6ONLY sockopt because its value
(26) happens to match SO_ATTACH_FILTER.

This makes it at least check 'level' for everything but
IPT_SO_SET_REPLACE == IPT6_SO_SET_REPLACE, because that does seem to be
the same in different levels. But do_netfilter_replace() is another can
of worms entirely -- it doesn't actually work either, because some
netfilter modules (like ipt_limit) include kernel-only bits which change
size in the structure they share with userspace.
Signed-off-by: David S. Miller <davem@davemloft.net>

Fixes: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131569
Dead lock in bridge when removing device interface module. br_del_if
assumes br->lock not held.

This fixes case of:
	brctl addbr b0
	brctl addif b0 eth0
	rmmod eth0
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Recommended by Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Every arch defines them the same without exception
and with this we only need to update one spot when
adding new socket types.
Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Signed-off-by: David S. Miller <davem@davemloft.net>

With suggestions from Herbert Xu
Signed-off-by: David S. Miller <davem@davemloft.net>

So here is a patch to make sure that there is a barrier between the
reading of dev->*_ptr and *dev->neigh_parms.

With these barriers in place, it's clear that *dev->neigh_parms can no
longer be NULL since once the parms are allocated, that pointer is never
reset to NULL again.  Therefore I've also removed the parms check in
these paths.

They were bogus to begin with since if they ever triggered then we'll
have dead neigh entries stuck in the hash table.

Unfortunately I couldn't arrange for this to happen with DECnet due
to the dn_db->parms.up() call that's sandwiched between the assignment
of dev->dn_ptr and dn_db->neigh_parms.  So I've kept the parms check
there but it will now fail instead of continuing.  I've also added an
smp_wmb() there so that at least we won't be reading garbage from
dn_db->neigh_parms.

DECnet is also buggy since there is no locking at all in the destruction
path.  It either needs locking or RCU like IPv4.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Using the automated source checker at coverity.com, they picked up
on some code in packet_release() where a NULL check was done
after dereferencing.  Patch below.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Nicolas Pitre

At least with gcc-3.4.1...
Error: use of old and new-style options to set FPU type

Signed-off-by: Nicolas Pitre 

Patch from Nicolas Pitre

This patch removes a bunch of inline functions from unistd.h on ARM. Some of
them were conflicting with gcc's idea of how they should normally be declared,
and none of them are used anymore.

Signed-off-by: Nicolas Pitre 

Patch from Nicolas Pitre

warning: use of conditional expressions as lvalues is deprecated

Signed-off-by: Nicolas Pitre 

Patch from Nicolas Pitre

Reduce code duplication.  Resulting assembly is identical.

Signed-off-by: Nicolas Pitre 

Patch from Nicolas Pitre

Signed-off-by: Nicolas Pitre 

Add flush_cache_user_page() to handle sys_cacheflush.  Userspace
wants to use this call to ensure I/D cache coherency for runtime-
built code (eg, used by Java etc).  This does not fit well with
the purpose of flush_cache_range(), so provide
flush_cache_user_range() instead.

Fix flush_dcache_page() for ARMv6 VIPT aliasing caches, and ignore
it for non-aliasing caches.

This fixes the copy and clear user page functions for ARMv6 aliasing
caches.  When we copy data into a page destined for user space, we
must make sure that there are no dirty cache lines associated with
the kernel space mapping of this page.

Add cache_is_xxxx() functions so we can easily identify the cache
type of the CPU we're running on.

Move flush_dcache_page into flush.c - it shouldn't be in the middle
of the VIVT mmap alias coherency code.

It needs to be set so that congestion window
calculations have a valid value to work with.
This means that doing it at write queue running
time is too late.
Signed-off-by: David S. Miller <davem@davemloft.net>

Eliminate tp->mss_tso_factor.  Instead, we calculate the
SKB tso factor as we walk the write queue for initial
transmit or fragment SKBs.
Signed-off-by: David S. Miller <davem@davemloft.net>

Previously TSO would not abide by the congestion
window properly.  Essentially, each TSO packet would
be trated just like 1 normal packet, even though a TSO
packet generates more than 1 normal packet.  This
violates congestion window rules entirely.

So now we record the TSO factor, a count of how many
real packets a TSO packet will generate, and include
this in all the packet counting routines.

This initial version has a bug in that skb_entail() is
not the correct time to figure out the TSO factor for
the SKB, and tp->mss_tso_factor is not necessarily the
right value for a given SKB.  Will fix this up next.
Signed-off-by: David S. Miller <davem@davemloft.net>

This undoes bugs introduced by the generic
out-of-line spinlock patches.
Signed-off-by: David S. Miller <davem@davemloft.net>