summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2009-07-02dm: sysfs skip output when device is being destroyedMilan Broz
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 <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02dm mpath: validate hw_handler argument countMikulas Patocka
commit e094f4f15f5169526c7200b9bde44b900548a81e upstream. Fix arg count parsing error in hw handlers. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02dm mpath: validate table argument countMikulas Patocka
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 <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02qla2xxx: Correct (again) overflow during dump-processing on large-memory ↵Andrew Vasquez
ISP23xx parts. 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 <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02pcmcia/cm4000: fix lock imbalanceJiri Slaby
commit 69ae59d7d8df14413cf0a97b3e372d7dc8352563 upstream. Don't return from switch/case, break instead, so that we unlock BKL. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3Rafael J. Wysocki
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 <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02PCI PM: Fix handling of devices without PM support by pci_target_state()Rafael J. Wysocki
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 <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02parport_pc: set properly the dma_mask for parport_pc deviceFUJITA Tomonori
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 <fujita.tomonori@lab.ntt.co.jp> Reported-by: Malcom Blaney <malcolm.blaney@maptek.com.au> Tested-by: Malcom Blaney <malcolm.blaney@maptek.com.au> Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02parport_pc: after superio probing restore original register valuesJens Rottmann
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 <JRottmann@LiPPERTEmbedded.de> Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02vt_ioctl: fix lock imbalanceJiri Slaby
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 <jirislaby@gmail.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02md/raid5: add missing call to schedule() after prepare_to_wait()Dan Williams
commit 7a3ab908948b6296ee7e81d42f7c176361c51975 upstream. In the unlikely event that reshape progresses past the current request while it is waiting for a stripe we need to schedule() before retrying for 2 reasons: 1/ Prevent list corruption from duplicated list_add() calls without intervening list_del(). 2/ Give the reshape code a chance to make some progress to resolve the conflict. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02IB/mlx4: Add strong ordering to local inval and fast reg work requestsJack Morgenstein
commit 2ac6bf4ddc87c3b6b609f8fa82f6ebbffeac12f4 upstream. The ConnectX Programmer's Reference Manual states that the "SO" bit must be set when posting Fast Register and Local Invalidate send work requests. When this bit is set, the work request will be executed only after all previous work requests on the send queue have been executed. (If the bit is not set, Fast Register and Local Invalidate WQEs may begin execution too early, which violates the defined semantics for these operations) This fixes the issue with NFS/RDMA reported in <http://lists.openfabrics.org/pipermail/general/2009-April/059253.html> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02floppy: provide a PNP device table in the module.Scott James Remnant
commit 83f9ef463bcb4ba7b4fee1d6212fac7d277010d3 upstream. The missing device table means that the floppy module is not auto-loaded, even when the appropriate PNP device (0700) is found. We don't actually use the table in the module, since the device doesn't have a struct pnp_driver, but it's sufficient to cause an alias in the module that udev/modprobe will use. Signed-off-by: Scott James Remnant <scott@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Philippe De Muyter <phdm@macqel.be> Acked-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02USB: usbtmc: fix switch statmentGreg Kroah-Hartman
commit a92b63e7e4c185b4dd9e87762e2cb716e54482d0 upstream. Steve Holland pointed out that we forgot to call break; in the switch statment. This probably resolves a lot of the bug reports I've gotten for the driver lately. Stupid me... Reported-by: Steve Holland <sdh4@iastate.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02ISDN: Fix DMA alloc for hfcpciKarsten Keil
commit 8a745b9d91962991ce87a649a4dc3af3206c2c8b upstream. Replace wrong code with correct DMA API functions. Signed-off-by: Karsten Keil <keil@b1-systems.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02char: moxa, prevent opening unavailable portsDirk Eibach
commit a90b037583d5f1ae3e54e9c687c79df82d1d34a4 upstream. In moxa.c there are 32 minor numbers reserved for each device. The number of ports actually available per device is stored in moxa_board_conf->numPorts. This number is not considered in moxa_open(). Opening a port that is not available results in a kernel oops. This patch adds a test to moxa_open() that prevents opening unavailable ports. [akpm@linux-foundation.org: avoid multiple returns] Signed-off-by: Dirk Eibach <eibach@gdsys.de> Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02bonding: fix multiple module load problemStephen Hemminger
[ Upstream commit 130aa61a77b8518f1ea618e1b7d214d60b405f10 ] Some users still load bond module multiple times to create bonding devices. This accidentally was broken by a later patch about the time sysfs was fixed. According to Jay, it was broken by: commit b8a9787eddb0e4665f31dd1d64584732b2b5d051 Author: Jay Vosburgh <fubar@us.ibm.com> Date: Fri Jun 13 18:12:04 2008 -0700 bonding: Allow setting max_bonds to zero Note: sysfs and procfs still produce WARN() messages when this is done so the sysfs method is the recommended API. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02atmel_lcdfb: correct fifo size for some productsNicolas Ferre
commit 53b7479bbdaedcc7846c66fd608fe66f1b5aa35b upstream. Remove wrong fifo size definition for some AT91 products. Due to a misunderstanding of some AT91 datasheets, a fifo size of 2048 (words) has been introduced by mistake. In fact, all products (AT91/AT32) are sharing the same fifo size of 512 words. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Andrew Victor <avictor.za@gmail.com> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02atkbd: add forced release quirks for four more keyboard modelsChuck Ebbert
Add atkbd forced key release quirks for four more notebook models. Rollup of: linux-2.6.git-391916985b009b8934d00f772a3bde0d8a495ebd.patch linux-2.6.git-adcb523eb39e0dd2f712d8dbd8e18b5d36a97825.patch linux-2.6.git-157f3a3e17cd498571db2a472dc3a15a7679ee3f.patch linux-2.6.git-e04126c79242d2740b469292d42c239bad7807cc.patch linux-2.6.git-9166d0f620d5dd4a128711bdeedb3e0f534d9d49.patch Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02PCI: disable ASPM on VIA root-port-under-bridge configurationsShaohua Li
commit 8e822df700694ca6850d1e0c122fd7004b2778d8 upstream. VIA has a strange chipset, it has root port under a bridge. Disable ASPM for such strange chipset. Tested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02firmware_map: fix hang with x86/32bitYinghai Lu
commit 3b0fde0fac19c180317eb0601b3504083f4b9bf5 upstream. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484 Peer reported: | The bug is introduced from kernel 2.6.27, if E820 table reserve the memory | above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000 | (reserved)), system will report Int 6 error and hang up. The bug is caused by | the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit | variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6 | error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this | bug. |====== |static int firmware_map_add_entry(resource_size_t start, resource_size_t end, | const char *type, | struct firmware_map_entry *entry) and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set. it turns out we need to pass u64 instead of resource_size_t for that. [akpm@linux-foundation.org: add comment] Reported-and-tested-by: Peer Chen <pchen@nvidia.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02r8169: fix crash when large packets are receivedEric Dumazet
commit fdd7b4c3302c93f6833e338903ea77245eb510b4 upstream. Michael Tokarev reported receiving a large packet could crash a machine with RTL8169 NIC. ( original thread at http://lkml.org/lkml/2009/6/8/192 ) Problem is this driver tells that NIC frames up to 16383 bytes can be received but provides skb to rx ring allocated with smaller sizes (1536 bytes in case standard 1500 bytes MTU is used) When a frame larger than what was allocated by driver is received, dma transfert can occurs past the end of buffer and corrupt kernel memory. Fix is to tell to NIC what is the maximum size a frame can be. This bug is very old, (before git introduction, linux-2.6.10), and should be backported to stable versions. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02char: mxser, fix ISA board lookupPeter Botha
commit 96050dfb25966612008dcea7d342e91fa01e993c upstream. There's a bug in the mxser kernel module that still appears in the 2.6.29.4 kernel. mxser_get_ISA_conf takes a ioaddress as its first argument, by passing the not of the ioaddr, you're effectively passing 0 which means it won't be able to talk to an ISA card. I have tested this, and removing the ! fixes the problem. Cc: "Peter Botha" <peterb@goldcircle.co.za> Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-028250: Fix oops from setserialAlan Cox
commit b8e7e40abeac49644fec4a4f52ffe74c7b05eca0 upstream. If you setserial a port which has never been initialised we change the type but don't update the I/O method pointers. The same problem is true if you change the io type of a port - but nobody ever does that so nobody noticed! Remember the old type and when attaching if the type has changed reload the port accessor pointers. We can't do it blindly as some 8250 drivers load custom accessors and we must not stomp those. Tested-by: Victor Seryodkin <vvscore@gmail.com> Closes-bug: #13367 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02parport: netmos 9845 & 9855 1P4S fixesPhilippe De Muyter
commit 50db9d8e4ca17974595e3848cb65f9371a304de4 upstream. netmos serial/parallel adapters come in different flavour differing only by the number of parallel and serial ports, which are encoded in the subdevice ID. Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S, and works only by side-effect for the first parallel port of a 2P2S, as this first parallel port is found by reading the second addr entry of (struct parport_pc_pci) cards[netmos_9855], which is not initialized, and hence has value 0, which happens to be the BAR of the first parallel port. netmos_9xx5_combo entry in (struct parport_pc_pci) cards[], which is used for a 9845 1P4S must also be fixed for the parallel port support when there are 4 serial ports because this entry currently gives 2 as BAR index for the parallel port. Actually, in this case, BAR 2 is the 3rd serial port while the parallel port is at BAR 4. I fixed 9845 1P4S and 9855 1P4S support, while preserving 9855 2P2S support, - by creating a netmos_9855_2p entry and using it for 9855 boards with 2 parallel ports : 9855 2P2S and 9855 2P0S boards, - and by allowing netmos_parallel_init to change not only the number of parallel ports (0 or 1), but making it also change the BAR index of the parallel port when the serial ports are before the parallel port. PS: the netmos_9855_2p entry in (struct pciserial_board) pci_parport_serial_boards[] is needed because netmos_parallel_init has no clean way to replace FL_BASE2 by FL_BASE4 in the description of the serial ports in function of the number of parallel ports on the card. Tested with 9845 1P4S, 9855 1P4S and 9855 2P2S boards. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Tested-by: Christian Pellegrin <chripell@fsfe.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15crypto: padlock - Revert aes-all alias to aesHerbert Xu
commit acd246b7494c629aa617da49716409566cf52149 upstream. Since the padlock-aes driver doesn't require a fallback (it's only padlock-sha that does), it should use the aes alias rather than aes-all so that ones that do need a fallback can use it. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15cdc-acm: Fix long standing abuse of tty->low_latencyAlan Cox
commit 7a9a65ced11ece416b730d6f21040a18e62d78a8 upstream. ACM sets the low latency flag but calls the flip buffer routines from IRQ context which isn't permitted (and as of 2.6.29 causes a warning hence this one was caught) Fortunatelt ACM doesn't need to set this flag in the first place as it only set it to work around problems in ancient (pre tty flip rewrite) kernels. Reported-by: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15ide-tape: remove back-to-back REQUEST_SENSE detectionTejun Heo
commit 36999a5af1b6c5379e59f0ddf434db08d03c19e4 upstream. Impact: fix an oops which always triggers ide_tape_issue_pc() assumed drive->pc isn't NULL on invocation when checking for back-to-back request sense issues but drive->pc can be NULL and even when it's not NULL, it's not safe to dereference it once the previous command is complete because pc could have been freed or was on stack. Kill back-to-back REQUEST_SENSE detection. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-153w-xxxx: scsi_dma_unmap fixadam radford
commit 7b14f58ad65f9d74e4273fb45360cfea824495aa upstream. This patch fixes the following regression that occurred during the scsi_dma_map()/unmap() changes when compiling with CONFIG_DMA_API_DEBUG=y : WARNING: at lib/dma-debug.c:496 check_unmap+0x142/0x542() Hardware name: 3w-xxxx 0000:02:02.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=36 bytes] Signed-off-by: Adam Radford <aradford@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15HID: fix dropped device-specific quirksZoltan Karcagi
commit f5208997087e6eb2096532b5a313eeb236535bdc upstream. Device-specific quirks are set up correctly in their respective vendor-specific driver, then get overwritten in usbhid_parse(). This is only issue for device-specific NOGET quirks being set by driver for a few devices out there. Signed-off-by: Zoltan Karcagi <zkr@freemail.hu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15Avoid ICE in get_random_int() with gcc-3.4.5Linus Torvalds
commit 26a9a418237c0b06528941bca693c49c8d97edbe upstream. Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: Martin Knoblauch <spamtrap@knobisoft.de> Cc: Matt Mackall <mpm@selenic.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15random: make get_random_int() more randomLinus Torvalds
commit 8a0a9bd4db63bc45e3017bedeafbd88d0eb84d02 upstream. It's a really simple patch that basically just open-codes the current "secure_ip_id()" call, but when open-coding it we now use a _static_ hashing area, so that it gets updated every time. And to make sure somebody can't just start from the same original seed of all-zeroes, and then do the "half_md4_transform()" over and over until they get the same sequence as the kernel has, each iteration also mixes in the same old "current->pid + jiffies" we used - so we should now have a regular strong pseudo-number generator, but we also have one that doesn't have a single seed. Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It has no real meaning. It could be anything. I just picked the previous seed, it's just that now we keep the state in between calls and that will feed into the next result, and that should make all the difference. I made that hash be a per-cpu data just to avoid cache-line ping-pong: having multiple CPU's write to the same data would be fine for randomness, and add yet another layer of chaos to it, but since get_random_int() is supposed to be a fast interface I did it that way instead. I considered using "__raw_get_cpu_var()" to avoid any preemption overhead while still getting the hash be _mostly_ ping-pong free, but in the end good taste won out. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jake Edge <jake@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15bnx2: Fix panic in bnx2_poll_work().Michael Chan
commit 581daf7e00c5e766f26aff80a61a860a17b0d75a upstream. Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue: http://bugzilla.kernel.org/show_bug.cgi?id=12698 This issue was reported by multiple i386 users. Without barrier(), the compiled code looks like the following where %eax contains the address of the tx_cons or rx_cons in the DMA status block. The status block contents can change between the cmpb and the movzwl instruction. The driver would crash if the value was not 0xff during the cmpb instruction, but changed to 0xff during the movzwl instruction. 6828: 80 38 ff cmpb $0xff,(%eax) 682b: 0f b7 10 movzwl (%eax),%edx With the added barrier(), the compiled code now looks correct: 683d: 0f b7 10 movzwl (%eax),%edx 6840: 0f b6 c2 movzbl %dl,%eax 6843: 3d ff 00 00 00 cmp $0xff,%eax Thanks to Pascal de Bruijn <pmjdebruijn@pcode.nl> for reporting the problem and Holger Noefer <hnoefer@pironet-ndh.com> for patiently testing test patches for us. [greg - took out version change] Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15iwlwifi: update key flags at time key is setReinette Chatre
commit 299f5462087f3bc2141e6bc83ba7e2b15d8a07d2 upstream. We need to be symmetrical in what is done when key is set and cleared. This is important wrt the key flags as they are used during key clearing and if they are not set when the key is set the key cannot be cleared completely. This addresses the many occurences of the WARN found in iwl_set_tkip_dynamic_key_info() and tracked in http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key() pair a few times in a row will cause that we run out of key space. This is because the index stored in the key flags is used by iwl_remove_dynamic_key() to decide if it should remove the key. Unfortunately the key flags, and hence the key index is currently only set at the time the key is written to the device (in iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info(). Fix this by setting flags in iwl_set_tkip_dynamic_key_info(). Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15igb: fix LRO warningJeff Kirsher
This fix is only needed for 2.6.29.y tree, since in 2.6.30 and later IGB has moved to using GRO instead of LRO. igb supports LRO, but was not setting any hooks to the ->set_flags ethtool_ops function. This would trigger warnings if the user tried to enable or disable LRO. Based on the patch provided by Stephen Hemminger <shemminger@vyatta.com> Reported-by: Sergey Kononenko <sergk@sergk.org.ua> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15e1000: add missing length check to e1000 receive routineNeil Horman
commit ea30e11970a96cfe5e32c03a29332554573b4a10 upstream. Patch to fix bad length checking in e1000. E1000 by default does two things: 1) Spans rx descriptors for packets that don't fit into 1 skb on recieve 2) Strips the crc from a frame by subtracting 4 bytes from the length prior to doing an skb_put Since the e1000 driver isn't written to support receiving packets that span multiple rx buffers, it checks the End of Packet bit of every frame, and discards it if its not set. This places us in a situation where, if we have a spanning packet, the first part is discarded, but the second part is not (since it is the end of packet, and it passes the EOP bit test). If the second part of the frame is small (4 bytes or less), we subtract 4 from it to remove its crc, underflow the length, and wind up in skb_over_panic, when we try to skb_put a huge number of bytes into the skb. This amounts to a remote DOS attack through careful selection of frame size in relation to interface MTU. The fix for this is already in the e1000e driver, as well as the e1000 sourceforge driver, but no one ever pushed it to e1000. This is lifted straight from e1000e, and prevents small frames from causing the underflow described above Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Tested-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15ide: fix OOPS during ide-cd error recoveryBartlomiej Zolnierkiewicz
commit e3b29f05124b07303088795396ff858811d2acb8 upstream. On Tuesday 19 May 2009 20:29:28 Martin Lottermoser wrote: > hdc: cdrom_decode_status: error=0x40 <3>{ LastFailedSense=0x04 } > ide: failed opcode was: unknown > hdc: DMA disabled > ------------[ cut here ]------------ > kernel BUG at drivers/ide/ide-io.c:872! It is possible for ide-cd to ignore ide_error()'s return value under some circumstances. Workaround it in ide_intr() and ide_timer_expiry() by checking if there is a device/port reset pending currently. Fixes bug #13345: http://bugzilla.kernel.org/show_bug.cgi?id=13345 Reported-by: Martin Lottermoser <Martin.Lottermoser@t-online.de> Reported-and-tested-by: Modestas Vainius <modestas@vainius.eu> Cc: Borislav Petkov <petkovbb@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15ide_pci_generic: add quirk for Netcell ATA RAIDBartlomiej Zolnierkiewicz
commit c339dfdd65b52bfd947ab29d1210314a2f6d622d upstream. We need to explicitly mark words 85-87 as valid ones since firmware doesn't do it. This should fix support for LBA48 and FLUSH CACHE [EXT] command which stopped working after we applied more strict checking of identify words in: commit 942dcd85bf8edf38cdc3745306ca250684d99a61 ("ide: idedisk_supports_lba48() -> ata_id_lba48_enabled()") and commit 4b58f17d7c45a8e5f4acda641bec388398b9c0fa ("ide: ide_id_has_flush_cache() -> ata_id_flush_enabled()") Reported-and-tested-by: "Trevor Hemsley" <trevor.hemsley@ntlworld.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15ide: fix 40-wire cable detection for TSST SH-S202* ATAPI devices (v2)Bartlomiej Zolnierkiewicz
commit 8369d5fa63260cc54464b4687aa6a0f78402d98e upstream. Since 2.6.26 we support UDMA66 on ATAPI devices requiring IVB quirk: commit 8588a2b732928b343233af9b1855705b8286bed4 ("ide: add SH-S202J to ivb_list[]") We also later added support for more such devices in: commit e97564f362a93f8c248246c19828895950341252 ("ide: More TSST drives with broken cable detection") and in: commit 3ced5c49bd2d1f2c7f769e3a54385883de63a652 ("ide: add TSSTcorp CDDVDW SH-S202H to ivb_list[]") It turns out that such devices lack cable detection altogether (which in turn results in incorrect detection of 40-wire cables by our current cable detection strategy) so always handle them by trusting host-side cable detection only. v2: Model detection fixup from Martin. Reported-and-tested-by: Martin Lottermoser <Martin.Lottermoser@t-online.de> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15cpuidle: fix AMD C1E suspend hangShaohua Li
commit 7d60e8ab0d5507229dfbdf456501cc378610fa01 upstream. When AMD C1E is enabled, local APIC timer will stop even in C1. To avoid suspend/resume hang, this patch removes C1 and replace it with a cpu_relax() in suspend/resume path. This hasn't any impact in runtime path. http://bugzilla.kernel.org/show_bug.cgi?id=13233 [ impact: avoid suspend/resume hang in AMD CPU with C1E enabled ] Tested-by: Dmitry Lyzhyn <thisistempbox@yahoo.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15cpuidle: make AMC C1E work in processor_idleShaohua Li
commit 87ad57bacb25c3f24c54f142ef445f68277705f0 upstream When AMD C1E is enabled, local APIC timer will stop even in C1. This patch uses broadcast ipi to replace local APIC timer in C1. http://bugzilla.kernel.org/show_bug.cgi?id=13233 [ impact: avoid boot hang in AMD CPU with C1E enabled ] Tested-by: Dmitry Lyzhyn <thisistempbox@yahoo.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15hwmon: (lm78) Add missing __devexit_p()Mike Frysinger
commit 39d8bbedb9571a89d638f5b05358f26ab503d7a6 upstream. The remove function uses __devexit, so the .remove assignment needs __devexit_p() to fix a build error with hotplug disabled. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15mtd_dataflash: unbreak erase supportPeter Korsgaard
commit dbf8c11f821b6ff83302c34f2403b4f7231f50ae upstream. Commit 5b7f3a50 (fix dataflash 64-bit divisions) unfortunately introduced a typo. Erase addr and len were swapped in the pageaddr calculation, causing the wrong sectors to get erased. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Acked-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15usb-serial: fix crash when sub-driver updates firmwareAlan Stern
commit 0a3c8549ea7e94d74a41096d42bc6cdf43d183bf upstream. This patch (as1244) fixes a crash in usb-serial that occurs when a sub-driver returns a positive value from its attach method, indicating that new firmware was loaded and the device will disconnect and reconnect. The usb-serial core then skips the step of registering the port devices; when the disconnect occurs, the attempt to unregister the ports fails dramatically. This problem shows up with Keyspan devices and it might affect others as well. When the attach method returns a positive value, the patch sets num_ports to 0. This tells usb_serial_disconnect() not to try unregistering any of the ports; instead they are cleaned up by destroy_serial(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15USB: isp1760: urb_dequeue doesn't always find the urbsWarren Free
commit 0afb20e00b5053170c85298fed842b32d20b4ea9 upstream. The option driver (and presumably others) allocates several URBs when it opens and tries to free them when it closes. The isp1760_urb_dequeue function gets called, but the packet being dequeued is not necessarily at the front of one of the 32 queues. If not, the isp1760_urb_done function doesn't get called for the URB and the process trying to free it hangs forever on a wait_queue. This patch does two things. If the URB being dequeued has others queued behind it, it re-queues them. And it searches the queues looking for the URB being dequeued rather than just looking at the one at the front of the queue. [bigeasy@linutronix] whitespace fixes, reformating Signed-off-by: Warren Free <wfree@ipmn.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15drivers/serial/mpc52xx_uart.c: fix array overindexing checkRoel Kluin
commit b898f4f869da5b9d41f297fff87aca4cd42d80b3 upstream. The check for an overindexing of mpc52xx_uart_{ports,nodes} has an off-by-one. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15drm/r128: fix r128 ioremaps to use ioremap_wc.Dave Airlie
commit 42beefc0093725ec0f8cea340cc54c36ccaceea0 upstream. This should allow r128 to start working again since PAT changes. taken from F-11 kernel. Signed-off-by: Dave Airlie <airlied@redhat.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15icom: fix rmmod crashBreno Leitao
commit 95caa0a9bdaf93607bd0cc8932f53112496f2f22 upstream. Actually the icom driver is crashing when is being removed because the driver is kfreeing the adapter structure before calling pci_release_regions(), which result in the following error: Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d33 Faulting instruction address: 0xc000000000246b80 Oops: Kernel access of bad area, sig: 11 [#1] .... [c000000012d436a0] [c0000000001002d0] .kfree+0x120/0x34c (unreliable) [c000000012d43730] [c000000000246d60] .pci_release_selected_regions+0x3c/0x68 [c000000012d437c0] [d000000002d54700] .icom_kref_release+0xf4/0x118 [icom] [c000000012d43850] [c000000000232e50] .kref_put+0x74/0x94 [c000000012d438d0] [d000000002d56c58] .icom_remove+0x40/0xa4 [icom] [c000000012d43960] [c000000000249e48] .pci_device_remove+0x50/0x90 [c000000012d439e0] [c0000000002d68d8] .__device_release_driver+0x94/0xd4 [c000000012d43a70] [c0000000002d7104] .driver_detach+0xf8/0x12c [c000000012d43b00] [c0000000002d549c] .bus_remove_driver+0xbc/0x11c [c000000012d43b90] [c0000000002d71dc] .driver_unregister+0x60/0x80 [c000000012d43c20] [c00000000024a07c] .pci_unregister_driver+0x44/0xe8 [c000000012d43cb0] [d000000002d56bf4] .icom_exit+0x1c/0x40 [icom] [c000000012d43d30] [c000000000095fa8] .SyS_delete_module+0x214/0x2a8 [c000000012d43e30] [c00000000000852c] syscall_exit+0x0/0x40 Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15TPM: get_event_name stack corruptionEric Paris
commit fbaa58696cef848de818768783ef185bd3f05158 upstream. get_event_name uses sprintf to fill a buffer declared on the stack. It fills the buffer 2 bytes at a time. What the code doesn't take into account is that sprintf(buf, "%02x", data) actually writes 3 bytes. 2 bytes for the data and then it nul terminates the string. Since we declare buf to be 40 characters long and then we write 40 bytes of data into buf sprintf is going to write 41 characters. The fix is to leave room in buf for the nul terminator. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15xen/blkfront: allow xenbus state transition to Closing->Closed when not ↵Ian Campbell
Connected commit 28afea5b2ffaa48f4f43d22ae8edcc384c05df80 upstream. This situation can occur when attempting to attach a block device whose backend is an empty physical CD-ROM driver. The backend in this case will go directly from the Initialising state to Closing->Closed. Previously this would result in a NULL pointer deref on info->gd (xenbus_dev_fatal does not return as a1a15ac5 seems to expect) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-09-22 02:46:18 +0000