Fixes security leak
Fixes a crash
Updates to use the new ac97

This is the newer audio used in later ALi chipsets.

This is used by some MIPS systems

This deals with several things
- Codecs that think they are modems but are not
- Abstracting modem detection out of drivers
- Abstracting digital switching out of drivers
- Codecs that have no volume control
- Codec plugins for specific setups
- Codec plugins for things like touchscreen/batmon on AC97
- More codec handlers

The plugin API is intentionally modelled on the other driver_register
type interfaces.

#ra1

[Not tested as I no longer have the card]

fix cifs distributed caching - send oplock release immediately after flush of writebehind data on oplock break from server

into hostme.bitkeeper.com:/repos/c/cifs/linux-2.5cifs

We should only account file system requests, ones originating from
__make_request(). Otherwise it skews the counters and they go negative
really fast.

From: Davide Libenzi <davidel@xmailserver.org>

Fix epoll to allow pushing of multiple file descriptors sharing the same
kernel's file*

From: Andrey Borzenkov <arvidjaar@mail.ru>

I finally hit a painfully trivial way to reproduce another long standing devfs
problem - deadlock between devfs_lookup and devfs_d_revalidate_wait. When
devfs_lookup releases directory i_sem devfs_d_revalidate_wait grabs it (it
happens not for every path) and goes to wait to be waked up. Unfortunately,
devfs_lookup attempts to acquire directory i_sem before ever waking it up ...

To reproduce (2.5.74 UP or SMP - does not matter, single CPU system)

ls /dev/foo & rm -f /dev/foo &

or possibly in a loop but then it easily fills up process table. In my case it
hangs 100% reliably - on 2.5 OR 2.4.

The current fix is to move re-acquire of i_sem after all
devfs_d_revalidate_wait waiters have been waked up.  Much better fix would be
to ensure that ->d_revalidate either is always called under i_sem or always
without.  But that means the very heart of VFS and I do not dare to touch it.

The fix has been tested on 2.4 (and is part of unofficial Mandrake Club
kernel); I expected the same bug is in 2.5; I just was stupid not seeing the
way to reproduce it before.

From: Andrey Borzenkov <arvidjaar@mail.ru>

Doing concurrent lookups for the same name in devfs with devfsd and modules
enabled may result in stack coruption.

When devfs_lookup needs to call devfsd it arranges for other lookups for the
same name to wait. It is using local variable as wait queue head. After
devfsd returns devfs_lookup wakes up all waiters and returns. Unfortunately
there is no garantee all waiters will actually get chance to run and clean up
before devfs_lookup returns. so some of them attempt to access already freed
storage on stack.

It is trivial to trigger with SMP kernel (I have single-CPU system if it
matters) doing

while true
do
  ls /dev/foo &
done

Without spinlock debug system usually hung dead with reset button as the only
possibility.

I was not able to reproduce it on 2.4 on single-CPU system - in 2.4
devfs_d_revalidate_wait does not attempt to remove itself from wait queue
so it appears to be safe.

The patch makes lookup struct be allocated from heap and adds reference
counter to free it when no more needed.

From: Russell King <rmk@arm.linux.org.uk>

Interrupts can sometimes occur before the socket thread is started.

From: Daniel Ritz <daniel.ritz@gmx.ch>

init_socket() enables interrupts, and the interrupt handler does a wakeup.
Let's initialise that waitqueue head before turning on the interrupts.

From: William Lee Irwin III <wli@holomorphy.com>

There are reports of kernel threads being killed by the oomkiller.  We
think this is because the oom killer tries to kill a task after it has
exitted and set its ->mm to zero.  The oom killer will then try to kill all
other tasks which have a null ->mm.

Attempt to detect that case and fix it up.

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

fsync_super() calls ->sync_fs() just after ->write_super().  But
write_super() will start a commit.  In this case, ext3_sync_fs() will not
itself start a commit, and it hence forgets to wait on the commit which
ext3_write_super() started.

Fix that up by making journal_start_commit() return the transaction ID of
any currently-running transaction.

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

start_this_handle() takes into account t_outstanding_credits when calculating
log free space, but journal_next_log_block() accounts for blocks being logged
also.  Hence, blocks are accounting twice.  This effectively reduces the
amount of log space available to transactions and forces more commits.

Fix it by decrementing t_outstanding_credits each time we allocate a new
journal block.