Add a warning if enable_kernel_{fp,altivec} is called with preempt
enabled since this is always an error, and make sure the alignement
exception handler properly disables preempt when doing FP operations.

We don't set the task state to TASK_INTERRUPTIBLE _before_ checking for
kthread_should_stop in do_stop.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

From Dave Jones.

Oops.

   Check for valid application pointer inside api spinlock
   in diva_send_message().

Since pdflush was converted to be launched by the kthread infrastructure it
has inherited keventd's `nice -10' setting.  That hurts interactivity when
pdflush is doing lots of work writing back through the dm-crypt layer.

So set pdflush back to `nice 0'.

From: Mike Christie <michaelc@cs.wisc.edu>

A couple of drivers can sometimes fail the first segments in a bio then
requeue the rest of the request.  In this situation, if the last part of
the bio completes successfully bio_pair_end_* will miss that the beginging
of the bio had failed becuase they just return one when bi_size is not yet
zero.  The attached patch moves the error value test before the bi_size to
catch the above case.

From: Jens Axboe <axboe@suse.de>

Samuel Rydh wrote:

If a MODE_SENSE(6) command is sent to an IDE cd using the CDROM_SEND_PACKET
ioctl, then the kernel freezes solidly. To reproduce this, one can take the
SCSI cmd [1a 08 31 00 10 00] and a 16 byte data buffer.

After some bug hunting, I found out that the following is what happens:

- ide-cd recognizes that MODE_SENSE(6) isn't supported and tries
  to abort the request from ide_cdrom_prep_pc by returning BLKPREP_KILL.

- in elv_next_request(), the kill request is handled by
  the following code:

	while (end_that_request_first(rq, 0, rq->nr_sectors))
		;
	end_that_request_last(rq);

The while loop never exits. The end_that_request_first() doesn't do anything
since rq->nr_sectors is 0; it just returns "not-done" after handling those 0
bytes (rq->bio->bi_size is 16).

into nuts.davemloft.net:/disk1/BK/net-2.6

We've now narrowed down the issue of kernel oopses in combination with
'LIST_DELETE' syslog messages happening in certain setups.

Apparently people who do not enable CONFIG_IP_NF_NAT_LOCAL and do
DNAT/REDIRECT and want to connect locally from the gateway via DNAT to
the DNAT'ed address experience the bug ;)

Patch courtesy of KOVACS Krisztian and Henrik Nordstrom

Acked by Grant Grundler and Matthew Wilcox.

Acked by David Miller.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Here's one for -rc...  either this bit is assumed on most modern drives,
or nobody uses the 6-byte commands for read/write (which is very
likely).  Either way it definitely wants fixing.

Since we use the modern "LBA" method of addressing sectors, this bit
must be present in the Device register when issuing a read or write. 
There are three code paths that need this bit, and only two of them
actually set it.  This patch fixes the third (and apparently never used)
code path.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Acorn decided to use an esoteric method for handling the year.
Update RTC implementation to follow this method.

- Since the coherent DMA allocator is not currently compatible with
  HUGETLB, ensure that we fail at compile time should this option be
  selected.
- Move struct device/dma mask handling into consistent_alloc().
- Complain if someone tries to allocate coherent memory larger than
  their DMA mask will permit.
- Rename consistent_alloc() to __dma_alloc() to ensure that there
  is no confusion that consistent_alloc() has gone.
- Ensure warnings and errors report the correct function name.

Since we've eliminated users of these functions, we can unexport
them.  Instead, drivers should use the DMA API interfaces.

This is mainly for ARM framebuffer drivers, some of which are
presently either open-coding this functionality, or using some
internal ARM architecture function to get what they want.

It's a bit late in 2.6.5-rc for this, but it does fix a significant bug: for
the first five minutes after boot, prior to the jiffy wrap, /bin/sync doesn't
write all of the dirty data.

We currently record an inode's time-of-first-dirtying in the address_space.
This causes a few problems with dirty block special inodes: when the device
node for /dev/hda1 needs to be written back we bogusly inspect the timestamp
for the address_space, which belongs to a different inode.

So move the inode's dirtying time up into the inode itself.

This means that for block-special inodes, inode->dirtied_when represents the
time at which the inode itself was dirtied.

For regular files it represents the time at which the inode or its pages were
dirtied.

For blockdevs, the time-of-first-dirtying is recorded in the kernel-internal
blockdev inode.  Only I_DIRTY_PAGES makes sense on these inodes.

The reason all this works is that when dirtying a page we always run

	__mark_inode_dirty(page->mapping->host);

which refers to the kernel-internal blockdev inode.

From: Andi Kleen <ak@muc.de>

We are in production now. No more debugging needed.

From: Olaf Hering <olh@suse.de>

Further to the recent removal of CDROMs from /proc/partitions.

From: Hugh Dickins <hugh@veritas.com>

There's an irritating extra space upsetting alignment in the 2.6
/proc/swaps, which already arranges a space to separate the fields.

From: Jeff Garzik <jgarzik@pobox.com>

I pretty much said 'no' to everything "(NEW)", so any "=y" you see are the
result of Kconfig rules, not me.

From: Pavel Machek <pavel@ucw.cz>

Suspend/resume support in ide seems to work okay these days, so this should
be applied.

From: mike.miller@hp.com

If no device is attached we now return -ENXIO instead of some bogus
numbers.  Prevents applications from trying to access non-existent disks.
Also adds HDIO_GETGEO_BIG IOCTL that fdisk uses.

From: <mike.miller@hp.com>

This change is required to support the new MSA30 storage enclosure.  If you
do a SCSI inquiry to a SATA disk bad things happen.  This patch prevents
the inquiry from going to SATA disks.

From: Luiz Fernando Capitulino <lcapitulino@prefeitura.sp.gov.br>

sound/oss/opl3sa2.c:163: warning: `opl3sa2_lock' defined but not used

From: Andi Kleen <ak@suse.de>

ptrace/access_process_vm was passing current to get_user_pages as task, but
it should have been clearly the child task instead.

This fixes the fault accounting in ptrace and the vsyscall debugging on
x86-64 (it needs the correct task_struct to map the vsyscall pages)

From: Luiz Fernando Capitulino <lcapitulino@prefeitura.sp.gov.br>

sound/oss/cmpci.c: In function `cm_release_mixdev':
sound/oss/cmpci.c:1465: warning: unused variable `s'

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

From: Srivatsa Vaddagiri <vatsa@in.ibm.com>

Hit a couple of (cpu hotplug) races in slab allocator during my tests.
Mostly it was because of continuous loading/unloading fs/minix/minix.ko
while simultaneously doing offline/online of CPUs.  As part of its init and
exit routines, minix.ko create/destroys caches, which lead to several
oopses.

1. kmem_cache_create
	In brief, kmem_cache_create does:
		a) calls enable_cpucache to create per-cpu cache for all
		   online CPUs. 
		b) adds the cache to the global list of caches

	These two are not done atomically and thats what causes problems.

	For ex: lets say that at the time of step a) CPU1 is not online.
	Hence no per-cpu cache is created for CPU1 (cachep->array[1] is NULL). 
	However CPU1 is not completely dead in the sense that CPU_DEAD
	processing for it is not yet over.  By the time CPU_DEAD processing 
	starts for CPU1, step b) is complete. So cpuup_callback finds this
	cache and tries freeing it's per-cpu cache associated with CPU1.
	In the process it dereferences a NULL pointer and dies.

2. kmem_cache_destroy
	In brief, kmem_cache_destroy does:
		a) deletes the cache from the global list of caches
		b) Drain per-cpu cache (drain_cpu_caches), which
		   basically uses smp_call_function to run do_drain
		   on all online CPUs.

	One possible race is let's say that CPU1 is coming up.
	By the time CPU_UP_PREPARE is processed for CPU1, step a) is
	complete. Hence cpuup_callback does not allocate any per-cpu cache
	for the cache that is being destroyed.

	However by the time step b) is run, CPU1 is completely online
	(taking interrupts). It receives the IPI and tries draining
	it per-cpu cache (which is NULL) and dies there.

I think we need to serialize kmem_cache_create/destroy against CPU hotplug
to prevent these problems.  Patch below does that by taking CPU Hotplug sem
(which is OK since kmem_cache_create/destroy are not very frequently
used?).

From: Joe Korty <joe.korty@ccur.com>

The following fixes a problem where a SCHED_FIFO task would on occasion be
moved to the end of its runqueue when returned to from a preemption.  Cause
was due to some SCHED_OTHER code in schedule() which was being run for tasks
of every policy.

From: NeilBrown <neilb@cse.unsw.edu.au>

This helps raid5 work on at least 1 very large array..

Thanks to Evan Felix <evan.felix@pnl.gov>