This fixes a race between try_to_free_buffers' call to
__remove_inode_queue() and other users of b_inode_buffers
(fsync_inode_buffers and mark_buffer_dirty_inode()).  They are
presently taking different locks.

The patch relocates and redefines and clarifies(?) the role of
inode.i_dirty_buffers.

The 2.4 definition of i_dirty_buffers is "a list of random buffers
which is protected by a kernel-wide lock".  This definition needs to be
narrowed in the 2.5 context.  It is now

"a list of buffers from a different mapping, protected by a lock within
that mapping".  This list of buffers is specifically for fsync().

As this is a "data plane" operation, all the structures have been moved
out of the inode and into the address_space.  So address_space now has:

list_head private_list;

     A list, available to the address_space for any purpose.  If
     that address_space chooses to use the helper functions
     mark_buffer_dirty_inode and sync_mapping_buffers() then this list
     will contain buffer_heads, attached via
     buffer_head.b_assoc_buffers.

     If the address_space does not call those helper functions
     then the list is free for other usage.  The only requirement is
     that the list be list_empty() at destroy_inode() time.

     At least, this is the objective.  At present,
     generic_file_write() will call generic_osync_inode(), which
     expects that list to contain buffer_heads.  So private_list isn't
     useful for anything else yet.

spinlock_t private_lock;

     A spinlock, available to the address_space.

     If the address_space is using try_to_free_buffers(),
     mark_inode_dirty_buffers() and fsync_inode_buffers() then this
     lock is used to protect the private_list of *other* mappings which
     have listed buffers from *this* mapping onto themselves.

     That is: for buffer_heads, mapping_A->private_lock does not
     protect mapping_A->private_list!  It protects the b_assoc_buffers
     list from buffers which are backed by mapping_A and it protects
     mapping_B->private_list, mapping_C->private_list, ...

     So what we have here is a cross-mapping association.  S_ISREG
     mappings maintain a list of buffers from the blockdev's
     address_space which they need to know about for a successful
     fsync().  The locking follows the buffers: the lock in in the
     blockdev's mapping, not in the S_ISREG file's mapping.

     For address_spaces which use try_to_free_buffers,
     private_lock is also (and quite unrelatedly) used for protection
     of the buffer ring at page->private.  Exclusion between
     try_to_free_buffers(), __get_hash_table() and
     __set_page_dirty_buffers().  This is in fact its major use.

address_space *assoc_mapping

    Sigh.  This is the address of the mapping which backs the
    buffers which are attached to private_list.  It's here so that
    generic_osync_inode() can locate the lock which protects this
    mapping's private_list.  Will probably go away.


A consequence of all the above is that:

    a) All the buffers at a mapping_A's ->private_list must come
       from the same mapping, mapping_B.  There is no requirement that
       mapping_B be a blockdev mapping, but that's how it's used.

       There is a BUG() check in mark_buffer_dirty_inode() for this.

    b) blockdev mappings never have any buffers on ->private_list.
       It just never happens, and doesn't make a lot of sense.

reiserfs is using b_inode_buffers for attaching dependent buffers to its
journal and that caused a few problems.  Fixed in reiserfs_releasepage.patch

- Add a debug check to catch people who are marking non-uptodate
  buffers as dirty.

  This is either a source of data corruption, or sloppy programming.

- Fix sloppy programming in ext3 ;)

Anton Blanchard has a workload (the SDET benchmark) which is showing some
moderate lock contention in do_pagecache_readahead().

Seems that SDET has many threads performing seeky reads against a
cached file.  The average number of pagecache probes in a single
do_pagecache_readahead() is six, which seems reasonable.

The patch (from Anton) flips the locking around to optimise for the
fast case (page was present).  So the kernel takes the lock less often,
and does more work once it has been acquired.

	- fix copy_{to,from}_user error handling (thanks to Rusty for pointing this out)

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

Not a big change, but make provides the current directory,
so why not use it ;-)

Don't print the actual command to call make in a subdir, make will
print 'Entering directory <foo>' anyway, so we don't lose that
information.

This Makefile would add irlan/irlan.o to $(obj-m) when selected as
modular, which is wrong. The module will get compiled just fine after
descending into that subdirectory anyway (whereas in the current
directory we have no idea how to build it).

Make CFLAGS_foo.o work also when generating preprocessed (.i) and
assembler (.s) files.
  
Same for AFLAGS_foo.o.

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.make

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

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

	- fix copy_{to,from}_user error handling (thanks to Rusty for pointing this out)

	- fix copy_{to,from}_user error handling (thanks to Rusty for pointing this out)

.<object>.flags are gone, but we have .<object>.cmd instead now and
surely don't want to add the to the repository.

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

into conectiva.com.br:/home/acme/bk/oss-copy_tofrom_user-2.5

	- fix copy_{to,from}_user error handling (thanks to Rusty for pointing this out)

fs/intermezzo/kml.c
fs/intermezzo/psdev.c

	- fix copy_{to,from}_user error handling (thans to Rusty for pointing this out)

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

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

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

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

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.make-as

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.isdn

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.make.next

into tp1.ruhr-uni-bochum.de:/home/kai/kernel/v2.5/linux-2.5.make

This patch makes nfsd_open use init_private_file to initilize
the file pointer the caller had allocated on stack.  In addition
a number of small cleanups:

 - format comments to be readable on 80char ANSI terminal
 - don't fop_get (and fop_put in nfsd_close), out file already
   is a reference to the inode so they can't go away.
 - don't decrement f_count on failure - it won't be checked anyway
 - don't check for filp->f_op n nfsd_close, it can't be NULL

Separate checks for !FS_REQUIRES_DEV and missing fsid option
and missing export operations, second check for missing export
operations and a small cleanup as side effect.

With this patch raid5 works.  There is still some more
work to though.

- uses bio instead of buffer_head
- stripe cache is now a fixed size.
   If read requests are smaller, we read the whole block anyway
   If write reqeusts are smaller, we pre-read.
- stripe_head is now variable sized with an array of structures at
  the end.  We allocate extra space depending on how many devices
  are in the array.
  stripe_head has it's very own slab cache.
- store and use bdev for each device in array

by-passing the cache for reads is currently disabled.  I need to
think through the implications (and implementation) of allowing
large bion that are larger than the stripe cache to go directly
to the device (if it isn't failed of-course).

- remove md_ prefix from some calls that used to be
  defined in md_compatability.h

- remove "raid5_" prefix from some static functions,
  in line with recent changes to raid1.c

?? should cpu_has_mmx be moved to in processor.h ?

The current code hits the page cache for the block device
which requires memory allocation which can sometimes cause
a deadlock (if it blocks the raid5d thread).

This code takes the page that holds the superblock, and
passes it to submit_bh in a suitable bio wrapper.

I under-allocated the space that RPC needs for transmit on a UDP
socket.   We need lots of space to be allowed (though we may not use
much) so that a lack of un-commited transmit space will not cause new
requests to be blocked.

This fixes reiserfs compile warnings for a few bitops calls.

This patch5 changes reiserfs_new_inode to end the transaction on errors
(like -ENOSPC), so that it can call iput without deadlocking against the
journal.

Currently sys_read/sys_pread and sys_write/sys_pwrite basically contain
lots of duplication of the same checks/code.

This moves all that into vfs_read/vfs_write helpers that have the same
prototypes as the read/write file operations.  In addition I have
choosen to export these interfaces to module so people doing inkernel
file reading/writing can use these instead of duplicating the checks
(which is very likely to be done wrong).

A long time ago there was thread group code that at exit time tried to
reparent a task to another task in the thread group.  I discovered a major
race condition in this code, and submitted a patch that removed it.  This
patch was accepted in, I think, 2.4.12.  The code reappeared in 2.4.18 and
sometime in the 2.5 tree before 2.5.15, breaking applications that use
thread groups.

As part of chasing this down, I figured out a way to remove the race
condition while still preserving this behavior.  I've attached a patch
against 2.5.15 that fixes it.

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