this fixes two instances of GFP_KERNEL from completion handlers.

On Mon, Dec 01, 2003 at 11:21:58AM -0800, Greg KH wrote:
> Can't you use xsane without the scanner kernel driver?  I thought the
> latest versions used libusb/usbfs to talk directly to the hardware.
> Because of this, the USB scanner driver is marked to be removed from the
> kernel sometime in the near future.

After a bit of mucking around (and possibly finding a bug with debian's
libusb/xsane/hotplug interaction, nothing seems to run
/etc/hotplug/usb/libusbscanner and thus only root can scan, anyone whose
got this working please let me know), the problem does not exist if I
only use  libusb xsane.

How about the following:

This patch fixes some obvious errors in the jumpshot and datafab drivers.

This should close out Bugzilla bug #1408

> Date: Mon, 1 Dec 2003 12:14:53 -0500 (EST)
> From: Alan Stern <stern@rowland.harvard.edu>
> Subject: Patch from Eduard Hasenleithner
> To: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
> cc: USB Storage List <usb-storage@one-eyed-alien.net>
>
> Matt:
>
> Did you see this patch?  It was posted to the usb-development mailing list
> about a week ago, before I started making all my changes.  It is clearly
> correct and necessary.
>
> Alan Stern

If a device can't be configured, the current test9 code forgets
to clean it out of sysfs.  This resolves that issue, so the retry
in usb_new_device() stands a chance of working.

The enumeration code still doesn't handle such errors well, but
at least this way that hub port can be used for another device.

They should be bound to the interface the driver is attached to, not
the device.

The problem was that the cursor was in the list being walked, and when
the pointer pointed to the cursor the list_del/list_add_tail pair would
oops trying to find the entry pointed to by the prev pointer of the
deleted cursor element.

The solution I found was to move the list_del earlier, before the
beginning of the list walk. since it is not used during the list walk and
should not count in the list enumeration it can be deleted, then the
list pointer cannot point to it so it can be added safely with the
list_add_tail without oopsing, and everything works as expected.

I am unable to oops this version with any of my test programs. 

Patch acked by Al Viro.

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

Based upon a patch from devik.

From Javier Achirica:

Delay MIC activation to prevent Oops

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.

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

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.

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.

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.

      Tracked down by Rohit Seth.