linux/drivers, branch v2.6.29.6

dm: sysfs skip output when device is being destroyed

2009-07-02T23:40:59Z

commit 4d89b7b4e4726893453d0fb4ddbb5b3e16353994 upstream. Do not process sysfs attributes when device is being destroyed. Otherwise code can cause BUG_ON(test_bit(DMF_FREEING, &md->flags)); in dm_put() call. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm mpath: validate hw_handler argument count

2009-07-02T23:40:59Z

commit e094f4f15f5169526c7200b9bde44b900548a81e upstream. Fix arg count parsing error in hw handlers. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm mpath: validate table argument count

2009-07-02T23:40:58Z

commit 0e0497c0c017664994819f4602dc07fd95896c52 upstream. The parser reads the argument count as a number but doesn't check that sufficient arguments are supplied. This command triggers the bug: dmsetup create mpath --table "0 `blockdev --getsize /dev/mapper/cr0` multipath 0 0 2 1 round-robin 1000 0 1 1 /dev/mapper/cr0 round-robin 0 1 1 /dev/mapper/cr1 1000" kernel BUG at drivers/md/dm-mpath.c:530! Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

qla2xxx: Correct (again) overflow during dump-processing on large-memory ISP23xx parts.

2009-07-02T23:40:57Z

commit e18e963b7e533149676b5d387d0a56160df9f111 upstream. Commit 7b867cf76fbcc8d77867cbec6f509f71dce8a98f ([SCSI] qla2xxx: Refactor qla data structures) inadvertently reverted e792121ec85672c1fa48f79d13986a3f4f56c590 ([SCSI] qla2xxx: Correct overflow during dump-processing on large-memory ISP23xx parts.). Signed-off-by: Andrew Vasquez Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

pcmcia/cm4000: fix lock imbalance

2009-07-02T23:40:55Z

commit 69ae59d7d8df14413cf0a97b3e372d7dc8352563 upstream. Don't return from switch/case, break instead, so that we unlock BKL. Signed-off-by: Jiri Slaby Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3

2009-07-02T23:40:54Z

commit f62795f1e892ca9269849fa83de97621da7e02c0 upstream. According to the PCI PM specification (PCI Bus Power Management Interface Specification, Rev. 1.2, Section 5.4.1) we are supposed to reinitialize devices that have PCI_PM_CTRL_NO_SOFT_RESET clear during all transitions from PCI_D3hot to PCI_D0, but we only do it if the device's current_state field is equal to PCI_UNKNOWN. This may lead to problems if a device with PCI_PM_CTRL_NO_SOFT_RESET unset is put into PCI_D3hot at run time by its driver and pci_set_power_state() is used to put it back into PCI_D0, because in that case the device will remain uninitialized after pci_set_power_state() has returned. Prevent that from happening by modifying pci_raw_set_power_state() to reinitialize devices with PCI_PM_CTRL_NO_SOFT_RESET unset during all transitions from D3 to D0. Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

PCI PM: Fix handling of devices without PM support by pci_target_state()

2009-07-02T23:40:53Z

commit d2abdf62882d982c58e7a6b09ecdcfcc28075e2e upstream. If a PCI device is not power-manageable either by the platform, or with the help of the native PCI PM interface, pci_target_state() will return either PCI_D3hot, or PCI_POWER_ERROR for it, depending on whether or not the device is configured to wake up the system. Alas, none of these return values is correct, because each of them causes pci_prepare_to_sleep() to return error code, although it should complete successfully in such a case. Fix this problem by making pci_target_state() always return PCI_D0 for devices that cannot be power managed. Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

parport_pc: set properly the dma_mask for parport_pc device

2009-07-02T23:40:52Z

commit dfa7c4d869b7d3d37b70f1de856f2901b6ebfcf0 upstream. parport_pc_probe_port() creates the own 'parport_pc' device if the device argument is NULL. Then parport_pc_probe_port() doesn't initialize the dma_mask and coherent_dma_mask of the device and calls dma_alloc_coherent with it. dma_alloc_coherent fails because dma_alloc_coherent() doesn't accept the uninitialized dma_mask: http://lkml.org/lkml/2009/6/16/150 Long ago, X86_32 and X86_64 had the own dma_alloc_coherent implementations; X86_32 accepted a device having dma_mask that is not initialized however X86_64 didn't. When we merged them, we chose to prohibit a device having dma_mask that is not initialized. I think that it's good to require drivers to set up dma_mask (and coherent_dma_mask) properly if the drivers want DMA. Signed-off-by: FUJITA Tomonori Reported-by: Malcom Blaney Tested-by: Malcom Blaney Signed-off-by: Alan Cox Acked-by: Jeff Garzik Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

parport_pc: after superio probing restore original register values

2009-07-02T23:40:52Z

commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50 upstream. CONFIG_PARPORT_PC_SUPERIO probes for various superio chips by writing byte sequences to a set of different potential I/O ranges. But the probed ranges are not exclusive to parallel ports. Some of our boards just happen to have a watchdog in one of them. Took us almost a week to figure out why some distros reboot without warning after running flawlessly for 3 hours. For exactly 170 = 0xAA minutes, that is ... Fixed by restoring original values after probing. Also fixed too small request_region() in detect_and_report_it87(). Signed-off-by: Jens Rottmann Signed-off-by: Alan Cox Acked-by: Jeff Garzik Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

vt_ioctl: fix lock imbalance

2009-07-02T23:40:50Z

commit a115902f67ef51fbbe83e214fb761aaa9734c1ce upstream. Don't return from switch/case directly in vt_ioctl. Set ret and break instead so that we unlock BKL. Signed-off-by: Jiri Slaby Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman