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

unmap_vmas() eventually calls tlb_start_vma(), where most architectures
flush caches as necessary.  The flush here seems to make the
flush_cache_range() in zap_page_range() redundant, and therefore can be
removed.

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

This contains the following changes:
 - export some driver parameters in sysfs
 - use new module parameter definitions

This contains the following changes:
 - EOT detection fixed when writing in fixed block mode
 - asynchronous writes in fixed block mode and write threshold removed
   to enable the EOT fixes (the parameter accepted for compatibility)

This contains the following changes:
 - ILI fixed to work with really old drives
 - message printed in case block larger than read()
 - long timeout used when creating a tape partition

I managed to add a bug to the local APIC NMI watchdog's
resume procedure in the driver model conversion for 2.5.67.
The problem is that the resume procedure simply calls the
enable procedure. If the NMI watchdog has been disabled by
another driver (like oprofile or perfctr), then the NMI
watchdog will incorrectly be re-enabled.

I discovered this when updating the perfctr driver for 2.5.67
and seeing unexpected NMIs after a resume from apm --suspend.

We can fix this by unregistering the NMI watchdog from the
driver model when disabling it (like the code did before the
driver model changes), or by remembering the previous state
at suspend and checking it at resume. The patch below uses
the second, simpler, approach. Tested, please apply.

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

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

Following recent changes removing blk_queue_empty(), we were
incorrectly plugging the queue some times (most often as part of
the SCSI scan process).  This was causing a non-deterministic panic
in the scan code because a destroyed queue was sometimes being
unplugged and run.

Patch from cam mayor

when setting up the framebuffer on the clps711x platform, the code checks to see if your allocated memory area is less than 38400 bytes.  If it is, a comment is sent to the kernel output suggesting it could be placed into SRAM.  This patch modifies the check so that it is suggested if the allocated memory area is less than OR EQUAL TO 38400 bytes.  This value is important as 38400 bytes is exactly the size of a 320 x 240 x 4bpp screen.  

into kernel.bkbits.net:/home/davem/net-2.5

Patch from Ian Molton

missed a bit. apply ontop of earlier patch.

Patch from Ian Molton

See summary

Patch from Ian Molton

see summary

Patch from Dirk Behme

Please see mail thread '[patch] Cleanup of head.S?' from 25 Feb 2003. Let us remove the third part now. The mapping set by this code is done already.

The comment of rmk was

'I suspect we can kill (3) without hurting stuff that's merged into the
-rmk tree, although I'm sure there's a reason it existed.  I'll have
to check my mail archives, but I think there was a machine that required,
but it appears not to be merged.'

So, let's try and see if somebody cries...

into nuts.ninka.net:/home/davem/src/BK/sparc-2.5

into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5

compile fix for PA-RISC

This fixes a build error caused by other changes in 2.5.67.

into kozmo.(none):/usr/src/fbdev-2.5

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

When the last device in a raid1 array is failed (or missing) the r1bio
structure can be released (especially on very fast devices) before
make_request has finished using it.

This patch gets and puts an extra reference to the r1_bio around the
submission loop, and uses the status in r1_bio to maintain the request status
if the last refernce is held by make_request.

This is also more correct for write requests, as a write should succeed
if any write succeeded, not only if the last write succceeded.

A new file "nfs4state.c", and nfs4_setclientid{,_confirm} are moved there,
with lots of code.

The removal of "struct nfsctl_uidmap" from "nfsctl_fdparm" broke
binary compatiblity on 64-bit platforms (strictly speaking: on all
platforms with alignof(void *) > alignof(int)).  The problem is that
nfsctl_uidmap contained a "char *", which forced the alignment of the
entire union to be 64 bits.  With the removal of the uidmap, the
required alignment drops to 32 bits.  Since the first member is only
32 bits in size, this breaks compatibility with user-space.  Patch
below fixes the problem.

Currently, an NFSv3 ACCESS check for READ permission on an
eXecute-only file will succeed where it should fail.

This is because nfsd_permission allows READ access to eXecute only
files so that mode 711 executables can be loaded and run, and
nfsd_access simply uses nfsd_permission.

This patch changes nfsd_permission to only map eXecute permission to
read permission of MAY_OWNER_OVERRIDE was set.  This is only set
when trying to read from a file, so ACCESS will no longer be tricked.

This change will only affect callers of nfsd_permission that specify
MAY_READ and not MAY_OWNER_OVERRIDE, and nfsd_access is the only
routine that calls nfsd_permission (via fh_verify) that way.

There was a missing exp_put in export.c so that after a client
mounts an exported filesystem, the server would never be able to
unmount, even after trying to unexport.  This is fixed by the last
chunk of this patch.

Also assorted cleanups to the code found while hunting.

From: Rusty Russell <rusty@rustcorp.com.au>

Introduce _sinittext and _einittext (cf. _stext and _etext), so kallsyms
includes __init functions.

TODO: Use huffman name compression and 16-bit offsets (see IDE
oopser patch)

From Alex Tomas and myself

It is identical in concept to the block allocator change.  It uses the same
hashed spinlock.

From Alex Tomas and myself

ext2 currently uses lock_super() to protect the filesystem's in-core block
allocation bitmaps.

On big SMP machines the contention on that semaphore is causing high context
switch rates, large amounts of idle time and reduced throughput.

The context switch rate can also worsen block allocation: if several tasks
are trying to allocate blocks inside the same blockgroup for different files,
madly rotating between those tasks will cause the files' blocks to be
intermingled.

On SDET and dbench-style worloads (lots of tasks doing lots of allocation)
this patch (and a similar one for the inode allocator) improve throughout on
an 8-way by ~15%.  On 16-way NUMAQ the speedup is 150%.

What wedo isto remove the lock altogether and just rely on the atomic
semantics of test_and_set_bit(): if the allocator sees a block was free it
runs test_and_set_bit().  If that fails, then we raced and the allocator will
go and look for another block.

Of course, we don't really use test_and_set_bit() because that
isn'tendian-dependent.  New atomic endian-independent functions are
introduced: ext2_set_bit_atomic() and ext2_clear_bit_atomic().  We do not
need ext2_test_bit_atomic(), since even if ext2_test_bit() returns the wrong
result, that error will be detected and naturally handled in the subsequent
ext2_set_bit_atomic().

For little-endian machines the new atomic ops map directly onto the
test_and_set_bit(), etc.

For big-endian machines we provide the architecture's impementation with the
address of a spinlock whcih can be taken around the nonatomic ext2_set_bit().
 The spinlocks are hashed, and the hash is scaled according to the machine
size.  Architectures are free to implement optimised versions of
ext2_set_bit_atomic() and ext2_clear_bit_atomic().

ext2 and ext3 per-blockgroup metadata needs locking.  An fs-wide lock is
expensive, and a per-blockgroup lock consumes too much storage (up to 32768
blockgroups per filesystem).  We need something in-between.

blockgroup_locks are very simple hashed spinlocks which provide this
compromise.  The size of the lock is scaled by NR_CPUS to implement an
additional speed/space tradeoff.

These locks are actually fairly generic.  However I presented it as something
which is specific to ext2 and ext3 so that people wouldn't go using them all
over the place.  They consume a lot of storage.

Several places in ext2 and ext3 are using filesystem-wide counters which use
global locking.  Mainly for the orlov allocator's heuristics.

To solve the contention which this causes we can trade off accuracy against
speed.

This patch introduces a "percpu_counter" library type in which the counts are
per-cpu and are periodically spilled into a global counter.  Readers only
read the global counter.

These objects are *large*.  On a 32 CPU P4, they are 4 kbytes.  On a 4 way
p3, 128 bytes.

From: Dave Hansen <haveblue@us.ibm.com>

Documents the information in /proc/meminfo

From: Matt Porter <porter@cox.net>

There was a thread a while back on lkml where Dave Hansen proposed this
simple vmalloc usage reporting patch.  The thread pretty much died out as
most people seemed focused on what VM loading type bugs it could solve.  I
had posted that this type of information was really valuable in debugging
embedded Linux board ports.  A common example is where people do arch
specific setup that limits there vmalloc space and then they find modules
won't load.  ;) Having the Vmalloc* info readily available is real useful in
helping folks to fix their kernel ports.

From: David Mosberger <davidm@napali.hpl.hp.com>

interrupts_open() can easily try to kmalloc() more memory than
supported by kmalloc.  E.g., with 16KB page size and NR_CPUS==64, it
would try to allocate 147456 bytes.

The workaround below is to allocate 4KB per 8 CPUs.  Not really a
solution, but the fundamental problem is that /proc/interrupts
shouldn't use a fixed buffer size in the first place.  I suppose
another solution would be to use vmalloc() instead.  It all feels like
bandaids though.

From: Brian Gerst and David Mosberger

The previous fix to the kmalloc_sizes[] array didn't null-terminate the
correct array.

Fix that up, and also avoid running ARRAY_SIZE() against an array which is
really a null-terminated list.