When analysing a stripe in handle_stripe we set bits
 R5_Wantread or R5_Wantwrite
to indicate if a read or write is needed.  We don't actually schedule the
IO immediately as this is done under a spinlock (sh->lock) and
generic_make_request can block.  Instead we check these bits after
the lock has been lifted and then schedule the IO.

But once the lock has been lifted we aren't safe against multiple
access, and it is possible that the IO will be scheduled never, or twice.

So, we use test_and_clear to check and potentially schedule the IO.

This wasn't a problem in 2.4 because the equivalent information was
stored on the stack instead of in the stripe.

We also make sure bi_io_vec[0] has correct values as a previous
call to generic_make_request may have changed them.

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

1. Null pointer dereference in end_sync_read

   r1_bio->read_disk is not initialised correctly in sync_request .

   this is used in end_sync_read to reference the structure
   conf->mirror[read_disk].rdev which with one disk missing is NULL.


2. Null pointer dereference in mempool_free()

   This is a race between close_sync() conf->r1_bufpool =3D NULL and put_buf()
   mempool_free().

   bio completion -> resume_device -> put_buf -> mempool_free(r1_bufpool)
				|
			   [ wakeup]
				|
			   close_sync()	-> r1_bufpool = NULL;

   The patch attached  reorders the mempool_free before the  barrier is released
   and merges resume_device() into put_buf(), (they are only used together).
   Otherwise I have kept the locking and wakeups identical to the existing code.
   (maybe this could be streamlined)

3.  BUG() at close_sync() if (waitqueue_active(&conf->wait_resume).

   This occurs with and without the patch for (2).

   I think this is a false BUG().  From what I understand of the device barrier
   code, there is nothing wrong with make_request() waiting on wait_resume when
   this test is made.  Therefore I have removed it (the wait_idle test is still
   correct).

4. raid1 tries to start a resync if there is only one working drive,
   which is pretty pointless, and noisy.  We notice that special case and
   avoid the resync.

Roughly in order of patch:

1/ xor.h is never needed in md.c
2/ set sb_loaded when we 'sync' mddev to rdev as well as when we load
   sb into rdev from disk.
2/ due to lifetime changes, active count can be 2 when we stop array
3/ due to lifetime changes, we need to explicitly clear the ->pers when we
   stop an array
4/ autostart can only work for 0.90.0 superblocks.
   None others would be silly enough to store device numbers for
   all devices in the superblock...
5/ we had lost the setting of 'sb' when auto-starting an array.
6/ Code currently calls export_rdev(start_rdev) when
   IS_ERR(start_rdev), which causes an oops.
7/ /proc/mdstat contents error:
       code does not take into account that delayed
       resyncs can wait with curr_resync = 1 or 2.
8/ There is a premature "return NOTIFY_DONE", that possibly was in
   for debugging once...

Make sure we drain the entire list of pages that failed to get added
to the mapping.

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

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

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

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

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

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

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

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

We can't allow quota state changes on a read-only device,
this would kick of a failing transaction & shut down the fs.
Previously the test was quota/no quota but we need to disallow
any change wrt user and/or group quota state.

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

a separate file, xfs_iomap.c out of xfs_lrw.c. Remove some parts
of the code which were not doing anything for us. This is step
one in some major reorgs of this code.

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

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

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

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

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

the layout of a log record for a buffer, the linux code deals with buffers
which are not contiguous in memory - this only applies to an inode buffer.
This adds one more fragmentation case to the code, and a line was missing
from this. The end result would be the logging of too much data if this
was not the last component of the buffer.

The code was definitely wrong, but I think the chances of hitting this were
pretty slim, and the resulting error would only matter if there was a
crash shortly afterward.

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

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

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

devices (log/realtime).  path_init was missing the LOOKUP_POSITIVE
flag, so it would fail to tell us if the file doesn't exist, there
was a spot where we were returning the wrong signedness for the code,
and when mount is failing, we can call into xfs_blkdev_put with a
NULL pointer depending on which devices were initialised and which
weren't.

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

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

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

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

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

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

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

the standard permission bits, and remove existing attrs
if acls are reduced to standard permissions.

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

longer needs to be declared globally here.

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

and struct inodes down in with the rest of the Linux-specific code.

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

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

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

with a directory block size larger than the filesystem (and hence attr)
blocksize.  This does not affect filesystems built with default mkfs.xfs
parameters, and only hits when a large number of attributes are set on
an inode.

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

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

headers.  Allows us to not repeat the xfs_stratcb declaration in several
places.  Also rename linvfs_set_inode_ops to xfs_set_inodeops since its
an auxillary routine not a linvfs method.

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

a few weeks ago with the rework of the target device pointer between the
xfs_mount and pb_target structures.

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

a kernel panic on certain option strings.

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