into home.osdl.org:/home/torvalds/v2.5/linux

The bug is probably impossible to trigger on x86, due to its
fairly strong coherency model (the SMP-safe bitops end up being
memory barriers etc), but other architectures - notably ppc64 -
can apparently trigger a race whereby the signal sender doesn't
wake up the target because it doesn't notice that it has gone to
sleep.

The optimization also optimizes only what appears to be the
uncommon case, where the signal happens for an already-running
process.

This makes the AIO submit path holds an extra reference until just
before returning.  This fixes the referencing a free kiocb. 

Without this patch the kernel will oops if the AIO completes early.

Noticed by Petr Vandrovec.

In the out-of-memory case, do_wp_page() would unlock page_table_lock
twice - once before allocating, and once in the exit path.

Rewrite the exit paths to be more readable, and don't try to share
the code between all the exit cases, since they are very different. 

into home.osdl.org:/home/torvalds/v2.5/linux

Display of cpumask for /proc/irq/prof_cpu_mask has a botch in the print
loop - should consume 2 bytes per loop.

into home.osdl.org:/home/torvalds/v2.5/linux

Found by Russell King.

Since 2.6.x by default does not remap the disk partitions any more, it
would be a good idea to warn when we see EZD or DM signatures.  That
informs the user to fix his setup (or pass in "hdx=remap" on the kernel
command line).

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

* flush host FIFO after sending data to DIMM window
* don't set SCR addresses, as the hardware doesn't have SCRs
  (cosmetic)

From: James Bottomley <James.Bottomley@SteelEye.com>

The cpu_callout_map differs from the prototype in asm-i386/smp.h by a
volatile.  gcc-3.3 now treats this as an error, so voyager support will
only compile with older gcc's.  The fix is to remove the spurious volatile.

This fixes a JBD assertion failure (goes BUG) in __journal_remove_journal_head().

When the journal had aborted due to earlier internal consistency errors (or
I/O errors) it is possible that we free journal_heads which still have
attached copyout buffers.  So just free them up.

From: Mike Tran <mhtran@us.ibm.com>

This fixes the RAID1 recovery problems; it seems to be a simple thinko:
sync_request_write() is passing "ok=0" into md_done_sync().  Clearly, `ok'
should be true here.

(acked by neilb)

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

Module aliases are all of form "char-major-<major>-<minor>".  char_dev.c
calls request_module with "char-major-<major>".

It's not ready for prime time yet, so hide it until the additional work has
been done.

If this CPU decides that an ext2 block group has a free block it will then go
in and try to acquire it.  No locks are held, so another CPU can come in and
steal the last block.

In this case we will bogusly report a corrupted filessytem.

Fix it by just restarting the scan - this will choose a different blockgroup
or will generate -ENOSPC.

Only include mca.h if CONFIG_MCA: only ia32 and ia64 have <asm/mca.h>

From: Nick Piggin <piggin@cyberone.com.au>

as_completed_request() can be called for requests which were not generated by
the generic block layer.  Handle these, to avoid a subsequent WARN_ON (at
least).

Also kill a separate WARN_ON which is bogusly triggering.

into hera.kernel.org:/home/davem/BK/net-2.5

An extra dput was introduced in nfsd_rename 20 months ago....

time to remove it.

The __start___ex_table and __start___bug_table symbols could end up
pointing a few bytes before the actual __ex_table and __bug_table
sections, if the preceding section had an odd length.  This led to
oopses in some situations.  Patch from Sam Ravnborg.

into nuts.ninka.net:/disk1/davem/BK/net-2.5

into home.osdl.org:/home/torvalds/v2.5/linux

If we are unable to deliver a signal to the process (eg, due to stack
pointer corruption) block the signal so other fatal signals can kill
off the process.

K8 has an erratum (#100) that essentially causes some compat mode processes
to fault occassionally. The issue can be worked around in the OS. It only
applies to x86-64, in 32bit it is fine.

This adds a check to the page fault handler that checks for addresses >4GB
from compat mode. If they happen just return; the CPU will reexecute
the instruction and the condition that caused the problem is gone.

More details in Opteron/Athlon64 specification update on the AMD website.

Also I removed a left over debugging printk in the prefetch handling code.

default values after probing

This sets the mouse to 100 samples/second, 200 dpi, 1:1 mapping, which
is a standard setting, as close to 2.4 XFree86 behavior as possible, and
a good performance setting, too. 

It also in the case of 'psmouse_noext' doesn't probe and set anything
all, though it still issues the RESET command. This is as safe as one
can get.

The only real problem remaining is that the report rate and resolution
cannot be set from XFree86 config and only is available as a
kernel/module parameter. The fix is, howewer not 2.6.0 material.

The K8 IOMMU code had some broken BUG_ON()s that hit with <4K aligned IO
through the IOMMU.

This patch fixes this. Without this database raw IO is often broken.

into hera.kernel.org:/home/davem/BK/net-2.5

While using PRIVACY extensions, I sometimes get a hang when I remove the
interface. But I can reproduce this every time using the test script at
the end of the mail (hang depends on the order of address deletion).

The bug is in ipv6_del_addr() where if a temp address is being deleted, it
does an __in6_ifa_put() of the main address from which it was derived
(basically the autoconf prefix address). So if the main address was
deleted first, it's ifp ref count would be 1 and it would 'wait' to be
freed till it's temp address was freed first. When the temp address is
deleted, the __put() routine drops the main address's ifp ref count to 0,
but not free it. unregister_netdevice() hangs giving message that ref
count is 1. Fix tested overnight.

Also, the code at the top of the routine is unnecessary, the same is being
done when the address is found a little later in that routine.

The code that sends a signal needs to "kick" the target process if it
runs on another CPU and wasn't woken up by the signal to let it know
that it has a new event.

Otherwise it might take a long time until the target actually notices
and acts on the signal.