linux/drivers, branch v2.6.18.2

[PATCH] usbfs: private mutex for open, release, and remove

2006-11-04T01:33:50Z

The usbfs code doesn't provide sufficient mutual exclusion among open, release, and remove. Release vs. remove is okay because they both acquire the device lock, but open is not exclusive with either one. All three routines modify the udev->filelist linked list, so they must not run concurrently. Apparently someone gave this a minimum amount of thought in the past by explicitly acquiring the BKL at the start of the usbdev_open routine. Oddly enough, there's a comment pointing out that locking is unnecessary because chrdev_open already has acquired the BKL. But this ignores the point that the files in /proc/bus/usb/* are not char device files; they are regular files and so they don't get any special locking. Furthermore it's necessary to acquire the same lock in the release and remove routines, which the code does not do. Yet another problem arises because the same file_operations structure is accessible through both the /proc/bus/usb/* and /dev/usb/usbdev* file nodes. Even when one of them has been removed, it's still possible for userspace to open the other. So simple locking around the individual remove routines is insufficient; we need to lock the entire usb_notify_remove_device notifier chain. Rather than rely on the BKL, this patch (as723) introduces a new private mutex for the purpose. Holding the BKL while invoking a notifier chain doesn't seem like a good idea. Cc: Dave Jones [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212952] Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] JMB 368 PATA detection

2006-11-04T01:33:50Z

The Jmicron JMB368 is PATA only so has the PATA on function zero. Don't therefore skip function zero on this device when probing Signed-off-by: Alan Cox Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] PCI: Remove quirk_via_abnormal_poweroff

2006-11-04T01:33:49Z

My K8T800 mobo resumes fine from suspend to ram with and without patch applied against 2.6.18. quirk_via_abnormal_poweroff makes some boards not boot 2.6.18, so IMO patch should go to head, 2.6.18.2 and everywhere "ACPI: ACPICA 20060623" has been applied. Remove quirk_via_abnormal_poweroff Obsoleted by "ACPI: ACPICA 20060623": Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 Signed-off-by: Karsten Wiese Cc: Bob Moore Acked-by: Len Brown Acked-by: Dave Jones Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] ISDN: fix drivers, by handling errors thrown by ->readstat()

2006-11-04T01:33:49Z

This is a particularly ugly on-failure bug, possibly security, since the lack of error handling here is covering up another class of bug: failure to handle copy_to_user() return values. The I4L API function ->readstat() returns an integer, and by looking at several existing driver implementations, it is clear that a negative return value was meant to indicate an error. Given that several drivers already return a negative value indicating an errno-style error, the current code would blindly accept that [negative] value as a valid amount of bytes read. Obvious damage ensues. Correcting ->readstat() handling to properly notice errors fixes the existing code to work correctly on error, and enables future patches to more easily indicate errors during operation. Signed-off-by: Jeff Garzik Cc: Karsten Keil Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] ISDN: check for userspace copy faults

2006-11-04T01:33:49Z

Most of the ISDN ->readstat() implementations needed to check copy_to_user() and put_user() return values. Signed-off-by: Jeff Garzik Cc: Karsten Keil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] rtc-max6902: month conversion fix

2006-11-04T01:33:49Z

Fix October-only BCD-to-binary conversion bug: 0x08 -> 7 0x09 -> 8 0x10 -> 15 (!) 0x11 -> 19 Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7361 Cc: Raphael Assenat Cc: Alessandro Zummo Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] fix Intel RNG detection

2006-11-04T01:33:49Z

Previously, since determination whether there was an Intel random number generator was based on a single bit, on systems with a matching bridge device but without a firmware hub, there was a 50% chance that the code would incorrectly decide that the system had an RNG. This patch adds detection of the firmware hub to better qualify the existence of an RNG. There is one issue with the patch: I was unable to determine the LPC equivalent for the PCI bridge 8086:2430 (since the old code didn't care about which of the many devices provided by the ICH/ESB it was chose to use the PCI bridge device, but the FWH settings live in the LPC device, so the device list needed to be changed). Signed-off-by: Jan Beulich Signed-off-by: Michael Buesch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] Watchdog: sc1200wdt - fix missing pnp_unregister_driver()

2006-11-04T01:33:48Z

[WATCHDOG] sc1200wdt.c pnp unregister fix. If no devices found or invalid parameter is specified, scl200wdt_pnp_driver is left unregistered. It breaks global list of pnp drivers. Signed-off-by: Akinobu Mita Signed-off-by: Wim Van Sebroeck Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] SCSI: aic7xxx: pause sequencer before touching SBLKCTL

2006-11-04T01:33:48Z

[SCSI] aic7xxx: pause sequencer before touching SBLKCTL Some cards need to pause the sequencer before the SBLKCTL register is touched. This fixes a PCI related oops seen on powerpc macs with this card caused by trying to ascertain the bus signalling before beginning domain validation. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] sky2: 88E803X transmit lockup (2.6.18)

2006-11-04T01:33:47Z

The reason sky2 driver was locking up on transmit on the Yukon-FE chipset is that it was misconfiguring the internal RAM buffer so the transmitter and receiver were sharing the same space. It is a wonder it worked at all! This patch addresses this, and fixes an easily reproducible hang on Transmit. Only the Yukon-FE chip is Marvell 88E803X (10/100 only) are affected. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright