linux/drivers/base, branch v2.6.14.4

[PATCH] gfp flags annotations - part 1

2005-10-08T22:00:57Z

- added typedef unsigned int __nocast gfp_t; - replaced __nocast uses for gfp flags with gfp_t - it gives exactly the same warnings as far as sparse is concerned, doesn't change generated code (from gcc point of view we replaced unsigned int with typedef) and documents what's going on far better. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

[PATCH] fix class symlinks in sysfs

2005-09-22T14:58:24Z

The class symlinks in sysfs don't properly handle changing device names. To demonstrate, rename your network device from eth0 to eth1. Your pci (or usb, or whatever) device will still have a 'net:eth0' link, except now it points to /sys/class/net/eth1. The attached patch makes sure the class symlink name changes when the class device name changes. It isn't 100% correct, it should be using sysfs_rename_link. Unfortunately, sysfs_rename_link doesn't exist. Signed-off-by: Bill Nottingham Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] Driver Core: fis bus rescan devices race

2005-09-22T14:58:24Z

bus_rescan_devices_helper() does not hold the dev->sem when it checks for !dev->driver(). device_attach() holds the sem, but calls again device_bind_driver() even when dev->driver is set. What happens is that a first device_attach() call (module insertion time) is on the way binding the device to a driver. Another thread calls bus_rescan_devices(). Now when bus_rescan_devices_helper() checks for dev->driver it is still NULL 'cos the the prior device_attach() is not yet finished. But as soon as the first one releases the dev->sem the second device_attach() tries to rebind the already bound device again. device_bind_driver() does this blindly which leads to a corrupt driver->klist_devices list (the device links itself, the head points to the device). Later a call to device_release_driver() sets dev->driver to NULL and breaks the link it has to itself on knode_driver. Rmmoding the driver later calls driver_detach() which leads to an endless loop 'cos the list head in klist_devices still points to the device. And since dev->driver is NULL it's stuck with the same device forever. Boom. And rmmod hangs. Very easy to reproduce with new-style pcmcia and a 16bit card. Just loop modprobe ;cardctl eject; rmmod . Easiest fix is to check if the device is already bound to a driver in device_bind_driver(). This avoids the double binding. Signed-off-by: Daniel Ritz Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] drivers/base/*: use kzalloc instead of kmalloc+memset

2005-09-13T15:22:27Z

Fixes a bunch of memset bugs too. Signed-off-by: Lion Vollnhals Signed-off-by: Jiri Slaby Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] dmapool: Fix "nocast type" warnings

2005-09-10T17:06:29Z

Fix the sparse warning "implicit cast to nocast type" Signed-off-by: Victor Fusco Signed-off-by: Domen Puncer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[SCSI] Re-do "final klist fixes"

2005-09-08T01:44:33Z

With the previous commit that introduces the klist enhancements, we can now re-do 2b7d6a8cb9718fc1d9e826201b64909c44a915f4 again.

[PATCH] fix klist semantics for lists which have elements removed on traversal

2005-09-08T01:26:54Z

The problem is that klists claim to provide semantics for safe traversal of lists which are being modified. The failure case is when traversal of a list causes element removal (a fairly common case). The issue is that although the list node is refcounted, if it is embedded in an object (which is universally the case), then the object will be freed regardless of the klist refcount leading to slab corruption because the klist iterator refers to the prior element to get the next. The solution is to make the klist take and release references to the embedding object meaning that the embedding object won't be released until the list relinquishes the reference to it. (akpm: fast-track this because it's needed for the 2.6.13 scsi merge) Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[SCSI] Revert "final klist fixes"

2005-09-08T00:50:58Z

Revert commit 2b7d6a8cb9718fc1d9e826201b64909c44a915f4. The "fix" was known to not even compile. Duh. That's not a fix. That's just stupid. Signed-off-by: Linus Torvalds

Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-for-linus-2.6

2005-09-08T00:31:27Z

[PATCH] modified firmware_class.c to support no hotplug

2005-09-07T23:57:26Z

Upgrade the request_firmware_nowait function to not start the hotplug action on a firmware update. This patch is tested along with dell_rbu driver on i386 and x86-64 systems. Signed-off-by: Abhay Salunke Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds