into kernel.bkbits.net:/home/lord/xfs-2.6

SGI Modid: 2.5.x-xfs:slinx:159477a

SGI Modid: 2.5.x-xfs:slinx:159439b

SGI Modid: 2.5.x-xfs:slinx:159439a

into home.osdl.org:/home/torvalds/v2.5/linux

We do though need an I-cache flush on spitfire chips when
doing a module load.

Happily this allows us to kill off flush_cache_all() from
sparc64.

into nuts.ninka.net:/disk1/davem/BK/net-2.5

into penguin.americas.sgi.com:/src/lord/bitkeeper/xfs-2.6

Balazs Scheidler pointed out that we can fail to call ip_nat_setup_info
for local NAT, which causes the connection to be added twice. Boom.
Also move the hash table insertion into ip_nat_setup_info.

This patch introduces the /proc/sys/net/ipv4/netfilter/ directory for=20
the tuneable parameters of the conntrack engine of netfilter.

The parameters which can currently be fine-tuned (if required at all)=20
are the ip_conntrack_max, and the conntrack timeout parameters in seconds.

The default timeout value for the TCP CLOSE_WAIT state is raised to 3
days, which should cause less problems with long-lived half-closed TCP
sessions.

For the sake of compatibility with 2.4,=20
/proc/sys/net/ipv4/netfilter/ip_conntrack_max is duplicated as=20
/proc/sys/net/ipv4/ip_conntrack_max as well.

the 25_natcore-nohelper.patch (incorporated in 2.4.22) did actually make
things not better.  If a NAT rule was matched, num_manips can still be 0.
However, some helpers (like PPTP) need to _always mangle the packets,
even if there is no NAT mapping for a particular connection.
On the other hand, as soon as CONFIG_IP_NF_LOCAL_NAT was disabled,
we did end up half-mangling local (non-NAT'ed) connections.  This patch
removes the LOCAL_OUT hook from the NAT core unless CONFIG_IP_NF_NAT_LOCAL
is enabled.

get without a put!  Fix code for preemptable kernels.

SGI Modid: 2.5.x-xfs:slinx:159379a

into kernel.bkbits.net:/home/lord/xfs-2.6

This removes the remains of some debugging stuff which was never really
enabled properly - it never reported memory leaks.  Its not useful for
anyone but me. 

A proper solution involves counting all requests in flight and all
threads but we'll probably put that just into mm.

sget() is pessimistic and assumes it won't find a superblock - and as a
result it always pre-allocates a new one before even searching for an
existing entry.  If it finds an existing one, it free's the extra one it
just allocated.

Especially with /proc usage it usually _does_ find an existing
superblock, so this is all extra work.  It should allocate a new one
only if it couldn't find an old one (and re-search).

The same way as iget() does it.

This one won't cause hangs, but can trip some WARNs.

into kernel.bkbits.net:/home/davem/net-2.5

Rather than not kfree'ing the UDF data in the case of a bad inode (which
still _may_ have had the UDF data already allocated to it), make sure to
initialize the pointer to NULL properly when we're done with it.

From: Arun Sharma <arun.sharma@intel.com>

Based on some earlier discussion:

http://marc.theaimsgroup.com/?t=106015010700002&r=1&w=2

here's a new patch that attempts to disable BLK_DEV_FD on platforms which
don't support it.  The patch also attempts to remove the duplication of the
logic in compat_ioctl.h.

From: James Morris <jmorris@redhat.com>

From: Arun Sharma <arun.sharma@intel.com>

A minor bug fix to the ioctl32 code handling SG_IO.  sgio->dxferp is not
initialzed properly.

From: Geert Uytterhoeven <geert@linux-m68k.org>

Make that allyesconfig works on architectures that don't support HugeTLBs.

From: Andries.Brouwer@cwi.nl

 `generic_NCR5380_biosparam' declared `static' but never defined

From: Rick Lindsley <ricklind@us.ibm.com>

One typo corrected, and the references to 2.5 are minimized and mostly
changed to 2.6.

From: Roland McGrath <roland@redhat.com>

gdb really needs some way to know the AT_SYSINFO_EHDR value for a process
being debugged or for the dead process described by a core file.  Without
this value, it can't find the information necessary to show backtraces of
threads waiting in system calls.  There are any number of ways this
information could be made available.  Here is one solution that provides
more debugging information in a clean and general fashion.

I've added access to the AT_* values passed to a process for third parties
to examine for debugging purposes.  The same data passed on the stack at
startup is made available in /proc/PID/auxv and is written in an NT_AUXV
note in core dumps.  (Both of these are consistent with what Solaris does
using the same names.)

Here are two different patches that implement the same thing differently.
The first patch uses a ref-counted data structure to copy the aux vector
and shares among forked mm's until they exec and get a new one.  The second
patch avoids the complexity of that data structure by simply expanding the
mm_struct with space to hold a copy of the data.  Both patches work
correctly; I have examined the new /proc/PID/auxv file and core dumps.

I hope you will consider including one of these patches, or at least some
way of getting at this information from the debugger.  I am certainly open
to other suggestions on implementing this feature, and to suggestions on
alternative interfaces for getting the AT_SYSINFO_EHDR value cleanly.