This patch does a few cleanups/fixes with __verify_write:
 - Only compile it when needed.
 - Move test for KERNEL_DS out of line.
 - The mmap semaphore is needed to access the vma list.
 - Use fixmap for the WP test.
 - Removes an obsolete comment in fixmap.h

It was copied from i386 and is unused.

This fixes PTRACE_GETFPREGS to initilize the fpu struct correctly on
cpus with fxsr, as well as removing redundant code.

 - fixes an idiocy with floppy_find() et.al. - they forgot to set
   *part to 0.  As the result, open() on anything other than fd0 had
   lead to interesting effects...

 - fixes off-by-1 in set_disk_ro().

implementation. The optimized versions only work
for large areas, make sure we don't use them for
anything else.

configuration system, and instead just cleanly show
the dependency.

The ifdef <actual cpu selection> is very bad style, we usually introduce
feature CONFIG_ options in config.in instead.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into kroah.com:/home/greg/linux/BK/pci_hp-2.5

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

 - cleanup
 - remove unneeded mark_inode_dirty() in fat_extend_dir()

This removes fat_cvf stuff, and adds printk() level. As far as I
know, all the challengers gave up porting of fat_cvf.
(This patch from Christoph Hellwig)

This removes the conv option. This option does nothing, now.
(This patch from René Scharfe)

into kroah.com:/home/greg/linux/BK/pnp-2.5

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 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

  - ICE1712 - fixed Midiman M-audio Delta1010LT code
  - fixed typos in comments (es1938, intel8x0)
  - fixed quirks for Edirol UA-20 and UA-700 (USB driver)

into suse.cz:/home/perex/bk/linux-sound/linux-sound

Right now, various fields in struct request are just scattered
throughout the struct. This makes for bad cache behaviour. This patch
puts commonly referenced together fiels in the same cache lines and also
removes the prefetches in deadline_merge(). The latter was actually
hurting performance here now that struct request is sanely laid out wrt
cache.

This is worth ~40% less deadline_merge() runtime during disk intensive
tests!

Move the export to block/scsi_ioctl.c as well.

block/scsi_ioctl.c uses scsi_command_size[] to get from opcode to length
of cdb, but that is only available with SCSI enabled. Move to
block/scsi_ioctl.c from scsi/scsi.c.

When someone deleted scsi_merge, they also killed the fixes I sent to
you earlier...

- add locking comments to do_mmap_pgoff(), filemap.c

- used unsigned long for cpu flags in aio.c (Andi)

- An x86-64 typo fix from Andi.

- Fix a tpyo

- Fix an unused var warning in the stack overflow check code

- mptlan compile fix (Rasmus Andersen)

- Update misleading comment in ia32 highmem.c

- "attempting to mount an ext3 fs on a stopped md/raid1 array caused a
   divide by 0 error in ext3_fill_super.  Fix duplicates check already
   in ext2." - Angus Sawyer <angus.sawyer@dsl.pipex.com>

- Someone changed the return type of inl() again! Fix up compiler
  warnings in 3c59x.c again.

There's no need to take down pagecache after performing direct-IO reads
from a file or a blockdevice.

And when using direct access to a blockdev which has a filesystem
mounted it creates unnecessary disturbance of filesystem activity.

From Ingo

- performance optimization: do not kill threads in the same thread group
  as the OOM-ing thread. (it's still necessery to scan over every thread
  though, as it's possible to have CLONE_VM threads in a different thread
  group - we do not want those to escape the OOM-kill.)

- to not let newly created child threads slip out of the group-kill. Note
  that the 2.4 kernel's OOM handler has the same problem, and it could be
  the reason why forkbombs occasionally slip out of the OOM kill.

shrink_slab() wants to calculate

	nr_scanned_pages * seeks_per_object * entries_in_slab /
		nr_lru_pages

entries_in_slab and nr_lru_pages can vary a lot.  There is a potential
for 32-bit overflows.

I spent ages trying to avoid corner cases which cause a significant
lack of precision while preserving some clarity.  Gave up and used
do_div().  The code is called rarely - at most once per 128 kbytes of
reclaim.

The patch adds a tweak to balance_pgdat() to reduce the call rate to
shrink_slab() in the case where the zone is just a little bit below
pages_high.

Also increase SHRINK_BATCH.  The things we're shrinking are typically a
few hundred bytes, and a batchcount of 128 gives us a minimum of ten
pages or so per shrinking callout.

There's more work to do on these, for well-aligned copies.
Arjan has some stuff for that.   First step on that path is
to clean the code up, get it uninlined and have a framework for
making per-CPU-type decisions.

This patch speeds up copy_*_user for some Intel ia32 processors.  It is
based on work by Mala Anand.

It is a good win.  Around 30% for all src/dest alignments except 32/32.

In this test a fully-cached one gigabyte file was read into an
8192-byte userspace buffer using read(fd, buf, 8192).  The alignment of
the user-side buffer was altered between runs.  This is a PIII.  Times
are in seconds.

User buffer	2.5.41		2.5.41+
				patch++

0x804c000	4.373		4.343
0x804c001	10.024		6.401
0x804c002	10.002		6.347
0x804c003	10.013		6.328
0x804c004	10.105		6.273
0x804c005	10.184		6.323
0x804c006	10.179		6.322
0x804c007	10.185		6.319
0x804c008	9.725		6.347
0x804c009	9.780		6.275
0x804c00a	9.779		6.355
0x804c00b	9.778		6.350
0x804c00c	9.723		6.351
0x804c00d	9.790		6.307
0x804c00e	9.790		6.289
0x804c00f	9.785		6.294
0x804c010	9.727		6.277
0x804c011	9.779		6.251
0x804c012	9.783		6.246
0x804c013	9.786		6.245
0x804c014	9.772		6.063
0x804c015	9.919		6.237
0x804c016	9.920		6.234
0x804c017	9.918		6.237
0x804c018	9.846		6.372
0x804c019	10.060		6.294
0x804c01a	10.049		6.328
0x804c01b	10.041		6.337
0x804c01c	9.931		6.347
0x804c01d	10.013		6.273
0x804c01e	10.020		6.346
0x804c01f	10.016		6.356
0x804c020	4.442		4.366

So `rep;movsl' is slower at all non-cache-aligned offsets.

PII is using the PIII alignment.  I don't have a PII any more, but I do
recall that it demonstrated the same behaviour as the PIII.

The patch contains an enhancement (based on careful testing) from
Hirokazu Takahashi <taka@valinux.co.jp>.  In cases where source and
dest have the same alignment, but that aligment is poor, we do a short
copy of a few bytes to bring the two pointers onto a favourable
boundary and then do the big copy.

And also a bugfix from Hirokazu Takahashi.

As an added bonus, this patch decreases the kernel text by 28 kbytes.
22k of this in in .text and the rest in __ex_table.  I'm not really
sure why .text shrunk so much.

These copy routines have no special-case for constant-sized copies.  So
a lot of uaccess.h becomes dead code with this patch.  The next patch
which uninlines the copy_*_user functions cleans all that up and saves
an additional 5k.

From Rik.

"this trivial patch, against 2.5-current, exports nr_running and
 nr_iowait_tasks in /proc/stat.  With this patch in vmstat will no
 longer need to walk all the processes in the system just to determine
 the number of running and blocked processes."

When performing lookups against very sparse trees
radix_tree_gang_lookup fails to find nodes "far" to the right of the
start point.  Because it only understands sparseness in the leaf nodes,
not the intermediate nodes.

Nobody noticed this because all callers are incrementing the start
index as they walk the tree.

Change it to terminate the search when it really has inspected the last
possible node for the current tree's height.

Sort-of-but-not-really from High Dickins.

We're doing a lot of buslocked operations in the page allocator just
for debug.  Plus when they _do_ trigger, there are so many BUG_ONs in
there that it's rather hard to work out from user reports which one
actually triggered.

So redo all that and also print out some more useful info about the
page state before taking the machine out.

(And yes, we need to take the machine out.  Incorrect page handling in
there can cause file corruption).

Provide a function in core kernel to initialise a file_ra_state structure.

Perviously this was all taken care of by the fact that new struct
file's are all zeroed out.  But now a file_ra_state may be
independently allocated, and we don't want users of it to have to know
how to initialise it.