into redhat.com:/spare/repo/libata-2.5

Noticed and fixed by David Woodhouse.

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

I stumbled on a couple trivial bugs in ia64 numa/discontig support.
The first just sets the default number of nodes to something reasonable
for a generic kernel, otherwise it's really easy to start walking over
your initdata (more error checking should probably be added).  The
second fixes a memcpy to a physical address.

Without this patch, if a signal handler tried to access TLS data (via %gs), things break, because the GS descriptor is zero.

To be compatible with i386, we shouldn't be touching the segment descriptors
before getting into signal handlers.

their NR_IRQ_VECTORS.

	do_tty_hangup() does fput() on redirect struct file too early -
it could've been the only holder of tty_struct we are working with and in
that case we'll end up freeing it from fput() and then both reading and
modifying kfreed memory.

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

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

early_serial_setup() doesn't validate the array index, so a caller could
corrupt memory after serial8250_ports[] by supplying a value of port->line
that's too large.

I haven't seen a failure related to this, but it seems fragile to rely on
callers to know how many ports the driver supports.

Need to null-terminate that table.

From: Patrick Gefre <pfg@sgi.com>

Add ia64 Altix serial console driver.

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

when PROC_FS=n, arlan.h will define init_arlan_proc() and
cleanup_arlan_proc() as macros.  So, whitout the #ifdef/#endif here, we have
two definitions.

From: Pavel Machek <pavel@ucw.cz>

This printk is unneccessary for quite a long time, please kill it. [I
added it, so it should be okay for me to request it being killed..]

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

ia64 needs more complete checking on the offset which is passed into reads
or writes of /dev/mem.

This patch factors out the range checking so that the architecture can
implement a private version.

From: "Noah J. Misch" <noah@caltech.edu>

Two gameport drivers need __devexit_p wrapped around their remove
functions.  A newer binutils caught this is a link error.  This patch fixes
that.

Wrapped a __devexit_p around the 'remove' functions of two gameport
drivers.  The lack of __devexit_p was wrong according to linux/init.h,
differed from the practices in nearby files, and caused a link error with
binutils 2.14.90.0.5.

From: miles@lsi.nec.co.jp (Miles Bader)

The cb_pic_handle_irq function on this platform hadn't been updated to
use irqreturn_t; do so.

From: miles@lsi.nec.co.jp (Miles Bader)

This reservation is handled by platform-independent code in 2.6.0, but some
platforms _also_ did it in platform-specific code (left over from 2.4.x).

From: miles@lsi.nec.co.jp (Miles Bader)

Use `late_initcall' instead of just `__initcall' as a workaround for
the fact that (1) simcons_tty_init can't be called before tty_init,
(2) tty_init is called via `module_init', (3) if statically linked,
module_init == device_init, and (4) there's no ordering of init lists.

We can do this easily because simcons is always statically linked, but
other tty drivers that depend on tty_init and which must use
`module_init' to declare their init routines are likely to be broken.

From: "Noah J. Misch" <noah@caltech.edu>

Allows the Toshiba SMM driver to compile with CONFIG_PROC_FS=n.

It is missing an up() on an error path.

Peter Osterlund <petero2@telia.com> notes oopses in the anticipatory
scheduler with slab poisoning enabled due to arq->rb_node.rb_right being
uninitialised.  So wipe the whole thing when we allocate it.

deadline seems to have the same problem.

Backport this fix from 2.4

If you have an MCA kernel on non-MCA hardware and load an MCA driver,
mca_find_unused_adapter() ends up dereferencing NULL. 

Teach it about the absence of MCA buses.

With CONFIG_MCA=y and no MCA bus present, drivers go oops deep in the kobject
code when calling mca_register_driver().  Because there is no MCA subsystem
registered against the driver.

Plug this in mca_register_driver().

From: John Mock <kd6pag@qsl.net>

If 'parport_pc' is compile as a module, it fails to properly return certain
ioport resources after being removed.

If you try to load a DRM module when agpgart is not present, modprobe says
"Cannot allocate memory", which is rather misleading.

Make it return -EINVAL instead.

With CONFIG_MODULES=n this file does not compile because the type of
module->owner is not known.

Gven that card->owner is probably a null pointer when this driver is
statically linked, best thing to do is to just not poke around inside
card->owner at all.

Expand printk's traditional handling of null pointers so that anything in the
first page is considered a null pointer.

This gives us better behaviour when someone (acpi..) accidentally prints a
string which is embedded in a struct, the pointer to which is null.

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

Fix bluetooth build when CONFIG_PROC_FS=n

From: jbarnes@sgi.com (Jesse Barnes)

The patch adds a symlink from /sys/devices/system/node/nodeM/cpuN to the
/sys/devices/cpu/cpuN directory so that a userspace program can determine
which CPUs belong to which nodes easily.  Non-NUMA systems can simply pass
NULL in for the root arg and everything will work like it used to.

cache_grow() will call kmem_freepages() if the call to alloc_slabmgmt()
fails.  But the pages have not been marked PageSlab at this stage, so
kmem_freepages() goes BUG.

It is more symmetrical to mark the pages as PageSlab in kmem_getpages().

The patch also prunes a bunch of incorrect comments.

(PageSlab doesn't actually do anything: its only value is as a debug check.
I think the LKCD patch uses it).

Plug the two-megabyte-per-day memory leak.

I happened to spot this kfree(of complete garbage) - it is on an
oh-we-raced-retry path which is obviously exceedingly rare,

From: Peter Bergner <bergner@vnet.ibm.com>

In fs/binfmt_elf.c:load_elf_binary() (both 2.6 and 2.4), there is some
minimal checking whether the interpreter it's about to load/run is a valid
ELF file, but it fails to check whether the interpreter is of the correct
arch.  We ran into this when a borked powerpc64-linux toolchain set the
interpreter on our 64-bit app to our 32-bit ld.so.  Executing the app
caused the kernel to really chew up memory.  I'm assuming x86_64 and
sparc64 might possibly see the same behavior.

Note I'm not sure of the history behind INTERPRETER_AOUT, so I added the
test for INTERPRETER_ELF so as not to change it's behavior in case someone
still relies on it.

As an aside, it seems the elf_check_arch() macros should really be checking
for more than a valid e_machine value.  I'd think checking one or more of
the e_ident[EI_CLASS], e_ident[EI_DATA] and e_ident[EI_OSABI] values would
be required as well, no?

From: Jesper Juhl <juhl-lkml@dif.dk>