From: Alex Tomas <bzzz@tmi.comex.ru>

We have a race wherein the block allocator can decide that
journal_head.b_committed_data is present and then will use it.  But kjournald
can concurrently free it and set the pointer to NULL.  It goes oops.

We introduce per-buffer_head "spinlocking" based on a bit in b_state.  To do
this we abstract out pte_chain_lock() and reuse the implementation.

The bit-based spinlocking is pretty inefficient CPU-wise (hence the warning
in there) and we may move this to a hashed spinlock later.

From: Alex Tomas <bzzz@tmi.comex.ru>

This is a port from ext2 of the fuzzy counters (for Orlov allocator
heuristics) and the hashed spinlocking (for the inode and bloock allocators).

From: Alex Tomas <bzzz@tmi.comex.ru>


This patch weans ext3 off lock_super()-based protection for the inode and
block allocators.

It's basically the same as the ext2 changes.


1) each group has own spinlock, which is used for group counter
   modifications

2) sb->s_free_blocks_count isn't used any more.  ext2_statfs() and
   find_group_orlov() loop over groups to count free blocks

3) sb->s_free_blocks_count is recalculated at mount/umount/sync_super time
   in order to check consistency and to avoid fsck warnings

4) reserved blocks are distributed over last groups

5) ext3_new_block() tries to use non-reserved blocks and if it fails then
   tries to use reserved blocks

6) ext3_new_block() and ext3_free_blocks do not modify sb->s_free_blocks,
   therefore they do not call mark_buffer_dirty() for superblock's
   buffer_head. this should reduce I/O a bit


Also fix orlov allocator boundary case:

In the interests of SMP scalability the ext2 free blocks and free inodes
counters are "approximate".  But there is a piece of code in the Orlov
allocator which fails due to boundary conditions on really small
filesystems.

Fix that up via a final allocation pass which simply uses first-fit for
allocatiopn of a directory inode.

Move some lock_kernel() calls from the caller to the callee, reducing
holdtimes.

This is the start of the ext3 scalability rework.  It basically comes in two
halves:

- ext3 BKL/lock_super removal and scalable inode/block allocators

- JBD locking rework.

The ext3 scalability work was completed a couple of months ago.

The JBD rework has been stable for a couple of weeks now.  My gut feeling is
that there should be one, maybe two bugs left in it, but no problems have
been discovered...


Performance-wise, throughput is increased by up to 2x on dual CPU.  10x on
16-way has been measured.  Given that current ext3 is able to chew two whole
CPUs spinning on locks on a 4-way, that wasn't especially suprising.

These patches were prepared by Alex Tomas <bzzz@tmi.comex.ru> and myself.


First patch: ext3 lock_kernel() removal.

The only reason why ext3 takes lock_kernel() is because it is requires by the
JBD API.

The patch removes the lock_kernels() from ext3 and pushes them down into JBD
itself.

into home.transmeta.com:/home/torvalds/v2.5/linux

into tiger.hpl.hp.com:/data1/bk/lia64/to-linus-2.5

I must not ignore compiler warnings.
I must not ignore compiler warnings.
I must not ignore compiler warnings.

Avoid the linear list walk of get_exec_dcookie() when we've switched to a task
using the same mm.

Use the IO-APIC NMI delivery when the local APIC performance counter delivery is
not available. By Zwane Mwaikambo.

Reduce the possibility of dazed-and-confuseds.

 - Fix 'badness in local_bh_enable' warning

   This involved moving dev_queue_xmit() calls
   outside of sections with spinlock held.

 - Fix 'fix old protocol handler' warning

   This includes accounting for shared skbs,
   setting protocol .data field to non-null,
   and adding per device synchronization to
   receive handler.

This has been tested in PPP and Cisco modes
with and with out the keepalives enabled
on a SMP machine.

This patch creates fs/Kconfig.binfmt and converts all architectures to
use it.  I took the opportunity to spruce up the a.out help text for
the new millennium.

request might traverse several export points which may
have different uid squashing.

From: "William A.(Andy) Adamson" <andros@citi.umich.edu>

From: "William A.(Andy) Adamson" <andros@citi.umich.edu>

Put all clients in a LRU list and use a "work_queue" to
expire old clients periodically.

From: "William A.(Andy) Adamson" <andros@citi.umich.edu>

When readdir is enumerating a directory and finds a mountpoint,
it needs to do a bit of extra work to find the filehandle to be
returned in the readdir reply.

It is even possible that finding the filehandle requires an up-call,
so the request might be dropped to be re-tried later.

From: Hirokazu Takahashi <taka@valinux.co.jp>

In svc_tcp_listen_data_ready we should be waiting for
TCP_LISTEN, not TCP_ESTABLISHED.  The later only worked
by accident.

Also, if a socket is closed as soon as we accept it, we
must shut it down straight away as we will never get a 'close'
event.

The most significant fix is cleaning up properly when
nfs service is stopped.

Also fix some refcounting problems and other little bits.

svc_pushback_unused_pages must be ready of the possibility that
no pages were allocated or will need to be pushed back.

From Adrian Bunk.

into home.transmeta.com:/home/torvalds/v2.5/linux

Here enclosed an update for the new IRQ and module_param APIs.
eata.h and u14-34f.h are no longer used and will be deleted.

into home.transmeta.com:/home/torvalds/v2.5/linux

The parisc ports may use both the lasi700 and sim710 versions of this driver
Unfortunately, one must be memory mapped, and one must be IO mapped, so
add code to the driver for this case

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

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

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

Some socket hardware appears to "bounce" when a card is inserted - we
seem to receive more than one SS_DETECT event.  Unfortunately, this
causes us to initialise, setup the socket, and create the necessary
devices multiple times.

Fix this by ignoring card insertion events when we already know that
there is a card in the socket.