into redhat.com:/spare/repo/net-drivers-2.5

Clean up the tests while at it.

From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
   
   Such poisoning can cause oopses either because the refcount is not
   zero when the poisoning occurs, or due to kernel debugging options
   being enabled.

The driver was calling pci_unregister_driver for each _device_, and then
again at the end of the module unload routine.  Remove the call that's
inside the loop, pci_unregister_driver should only be called once.
   
Caught by Don Fry (and many others)

Fixes oops some were seeing on module unload.

Caught by Jon Burgess.

Driver was calling pci_unregister_driver for each _device_, and then
again at the end of the module unload routine.  Remove the call that's
inside the loop, pci_unregister_driver should only be called once.

Caught by Don Fry (and many others)

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

into redhat.com:/spare/repo/net-drivers-2.5

We should not allow mmap() with PROT_EXEC on mounts marked "noexec",
since otherwise there is no way for user-supplied executable loaders
(like ld.so and emulator environments) to properly honour the
"noexec"ness of the target.

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

This patch fixes i2c_smbus_write_byte() being broken for i2c-nforce2.
This causes trouble when that module is used together with eeprom (which
is also in 2.6). We have had three user reports about the problem.

Credits go to Mark D. Studebaker for finding and fixing the problem.

The scheduler is completed b0rked on x86_64, and I finally found out
why.  sched_clock() always returned 0, because rdtscll() always returned
0.  The 'a' in the macro doesn't agree with the 'a' in the function,
yippe :-)

This is a show stopper for x86_64.

Such poisoning can cause oopses either because the refcount is not
zero when the poisoning occurs, or due to kernel debugging options
being enabled.

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

The pid_alive() check within the loop is incorrect.  If we are within
the tasklist lock and the thread group leader is valid then the thread
chain will be fully intact.

Instead, the check should be _outside_ the loop, since if the group
leader no longer exists, the whole list is gone and we must not try
to access it.

Move the check around, and add comment.

Bug-hunting and fix by Srivatsa Vaddagiri

When doing sync wakeups we must not skip the notification of other cpus
if the task is not on this runqueue.

We need to initialize st->state in tcp_seq_start().  Otherwise
tcp_seq_stop() is run with previous st->state, and it calls the unneeded
unlock etc, causing a kernel crash.

into hostme.bitkeeper.com:/repos/t/typhoon/typhoon-2.5

I've got a lot more changes than what's included here.  I've put this
down to the bear minimum to get things working sanely.

Mainly, I just want to get all the people hit by this a chance to use
2.6.0 without having to get our tree. Changes itemized:

 - Fix deadlock possibility in csr.c:read_maps()
 - Fix kmalloc to use ATOMIC in highlevel.c.
 - s/in_interrupt/irqs_disabled/ in ieee1394_transactions.c to fix
   warnings when transactions occured.
 - Introduce a release callback for the host driver and use it correctly.
 - Reorganize the nodemgr probe so we do an initial scan to discover
   devices, check IRM/CycleMaster, then do a final full probe when things
   are kosher. Fixes a problem where device registration and hotplug
   would cause some serious problems when a bus reset was forced in the
   middle of the probe.

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

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

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

There are /proc handles there setup by proc_tty_register_driver, but there is
no module ownership association, so anything that reads after module unload
will blow.

The trivial fix is to propagate the owner of tty_driver to proc entry.

This fixes a small, but important bug in smsc-ircc2.c.

Without this the driver tries release the same region twice.

* Avoid short timeouts when waiting for a reset
* Fix issue with loading runtime image on newer versions of the sleep image
* Fix link status reporting

      Tracked down by Rohit Seth.

Do not special case ENOMEM as an error code, we should free up
the packet for all errors.

Most of the breakage came from cset 1.838.10.3

The br_netfilter_{init,fini}() calls need to be guarded by
BRIDGE_NETFILTER, from Michal Janusz Miroslaw.

When bringing an interface down do not forget to clear the
IF_RS_SENT and IF_RA_RCVD flags.