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

into samba.org:/home/anton/ppc64/for-linus-ppc64

into samba.org:/scratch/anton/linux-2.5_ppc64

into samba.org:/home/anton/ppc64/for-linus-ppc64

into samba.org:/scratch/anton/sfr

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

into samba.org:/home/paulus/kernel/for-linus-ppc

into samba.org:/home/paulus/kernel/for-linus-ppc

into samba.org:/home/paulus/kernel/for-linus-ppc

into samba.org:/scratch/anton/sfr

There was one place where we missed an unlock, in addition some more
code cleanups.

I had to rewrite the code from scratch to understand what it does,
but at least it doesn't OOPS anymore on boot..

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

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

  Also added \n to some error messages.

Now that we have working up-calls to userspace,
CROSSMNT makes sense.
If CROSSMNT is set for an export, and we too a
LOOKUP which crosses a mountpoint, we initiate an
upcall to find out if and how that filesystem
is exported.

becase nohide is the user-space visible name
for the flag, and we are about to define a real
CROSSMNT.

1/ call cache_fresh when replacing a cache entry (instead of only
  when updating) so that up-calls waiting on the replaced entry continue.

2/ in svcauth_unix_accept, don't put the verifier until all tests have
   succeeded.

3/ calculate size of request-being-deferred correctly.

nlmsvc_lock calls nlmsvc_create_block with file->f_sema
held.
nlmsvc_create_block calls nlmclnt_lookup_host which might
call nlm_gc_hosts which might, eventually, try to claim
file->f_sema for the same file -> deadlock.

nlmsvc_create_block does not need any protection under
any lock as lockd is single-threaded and _create_block
only plays with internal data structures.

So we release the f_sema before calling in, and make sure
it gets claimed again afterwards.

From: Trond Myklebust <trond.myklebust@fys.uio.no>


knfsd needs to disable soft interrupts when calling
csum_partial_copy_to_xdr().

At the moment there's a nasty conflict between the RPC server and
client. The problem arises when you get to xdr_partial_copy_from_skb()
(and the kmap_atomic()); the RPC client can end up calling the same
function from a ->data_ready() soft interrupt, and corrupt any data
the knfsd process may have copied.

Superblock format '1' resolves a number of issues with
superblock format '0'.
It is more dense and can support many more sub-devices.
It does not contains un-needed redundancy.
It adds a few new useful fields

The code to understand a specific superblock format is
already highly localised in md.  This patch defines a
user-space interface for selecting which superblock format
to use, and obeys that selection.

Md currently has a concept of 3 version numbers:
 A major version number
 A minor version number
 A patch version number

There historically seems to be some confusion about whether
these refer to a version of the superblock layout,
or a version of the software.

We will now define that:
   the "major_version" defines the superblock handler.
      '0' is the current superblock format.  All new formats
          will need new numbers.
   the "minor_version" can specify minor variations in the
      superblock, such as different location on the device
   the "patch_version" will be used to indicate new extenstions
      to the software.. patch_version=1 will mean multiple superblock
      support.

A superblock version number is selected by specifing major_version
in SET_ARRAY_INFO ioctl.

This patch:
  Updates Documentation/md.txt with details of new interface.
  Generalises desc_nr handling and makes sure that an array never
  has two devices with the same desc_nr.
  makes sure mddev->major_version is always valid and is 0 by default.
  uses mddev->major_version to select superblock handlers.
  Modifies set_array_info to just record version number if raid_disks==0
  Makes sure max_disks is always set correctly.
  Determines device size when reading superblock, or a hot-add/add-new.

Normally the data stored on a component of a RAID array is stored
from the start of the device.  This patch allows a per-device
data_offset so the data can start elsewhere. This will allow
RAID arrays where the metadata is at the head of the device
rather than the tail.

Md devices (raid1/raid5) can resync or recover.
There are similar but importantly different.
resync happens after an unclean shutdown
recovery happens when a failed drive is being replaced by a hot spare.

The sync-checkpoint code confused the two somewhat and this causes
problems.

This patch makes sure "recovery_cp" only relates to resync,
not recovery.
It also fixes a small problem with recording spares in
the superblock.

From: Angus Sawyer <angus.sawyer@dsl.pipex.com>

If there are no writes for 20 milliseconds, write out superblock
to mark array as clean.  Write out superblock with
dirty flag before allowing any further write to succeed.

If an md thread gets signaled with SIGKILL, reduce the
delay to 0.


Also tidy up some printk's and make sure writing the
superblock isn't noisy.

The md_recoveryd thread is responsible for initiating and cleaning
up resync threads.
This job can be equally well done by the per-array threads
for those arrays which might need it.

So the mdrecoveryd thread is gone and the core code that
it ran is now run by raid5d, raid1d or multipathd.

We add an MD_RECOVERY_NEEDED flag so those daemon don't have
to bother trying to lock the md array unless it is likely
that something needs to be done.

Also modify the names of all threads to have the number of
md device.

It is needed for kernel_fpu_*

Md uses ->recovery_running and ->recovery_err to keep track of the
status or recovery.  This is rather ad hoc and race prone.

This patch changes it to ->recovery which has bit flags for various
states.

It is (now) too trivial to even have an inline.