kernel/linux.git/drivers, branch v3.4.90

dm thin: fix dangling bio in process_deferred_bios error path

2014-05-13T12:11:32+00:00

commit fe76cd88e654124d1431bb662a0fc6e99ca811a5 upstream. If unable to ensure_next_mapping() we must add the current bio, which was removed from the @bios list via bio_list_pop, back to the deferred_bios list before all the remaining @bios. Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman

Skip intel_crt_init for Dell XPS 8700

2014-05-13T12:11:32+00:00

commit 10b6ee4a87811a110cb01eaca01eb04da6801baf upstream. The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port. The call intel_crt_init freeze the machine, so skip such call. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559 Signed-off-by: Giacomo Comes Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

mtd: sm_ftl: heap corruption in sm_create_sysfs_attributes()

2014-05-13T12:11:32+00:00

commit b4c233057771581698a13694ab6f33b48ce837dc upstream. We always put a NUL terminator one space past the end of the "vendor" buffer. Walter Harms also pointed out that this should just use kstrndup(). Fixes: 7d17c02a01a1 ('mtd: Add new SmartMedia/xD FTL') Signed-off-by: Dan Carpenter Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: nuc900_nand: NULL dereference in nuc900_nand_enable()

2014-05-13T12:11:31+00:00

commit c69dbbf3335a21aae74376d7e5db50a486d52439 upstream. Instead of writing to "nand->reg + REG_FMICSR" we write to "REG_FMICSR" which is NULL and not a valid register. Fixes: 8bff82cbc308 ('mtd: add nand support for w90p910 (v2)') Signed-off-by: Dan Carpenter Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

tgafb: fix data copying

2014-05-13T12:11:31+00:00

commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream. The functions for data copying copyarea_foreward_8bpp and copyarea_backward_8bpp are buggy, they produce screen corruption. This patch fixes the functions and moves the logic to one function "copyarea_8bpp". For simplicity, the function only handles copying that is aligned on 8 pixes. If we copy an unaligned area, generic function cfb_copyarea is used. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

gpio: mxs: Allow for recursive enable_irq_wake() call

2014-05-13T12:11:31+00:00

commit a585f87c863e4e1d496459d382b802bf5ebe3717 upstream. The scenario here is that someone calls enable_irq_wake() from somewhere in the code. This will result in the lockdep producing a backtrace as can be seen below. In my case, this problem is triggered when using the wl1271 (TI WlCore) driver found in drivers/net/wireless/ti/ . The problem cause is rather obvious from the backtrace, but let's outline the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(), which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq() calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not marked as recursive, lockdep will spew the stuff below. We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to fix the spew. ============================================= [ INFO: possible recursive locking detected ] 3.10.33-00012-gf06b763-dirty #61 Not tainted --------------------------------------------- kworker/0:1/18 is trying to acquire lock: (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88 but task is already holding lock: (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/0:1/18: #0: (events){.+.+.+}, at: [] process_one_work+0x134/0x4a4 #1: ((&fw_work->work)){+.+.+.}, at: [] process_one_work+0x134/0x4a4 #2: (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88 stack backtrace: CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61 Workqueue: events request_firmware_work_func [] (unwind_backtrace+0x0/0xf0) from [] (show_stack+0x10/0x14) [] (show_stack+0x10/0x14) from [] (__lock_acquire+0x140c/0x1a64) [] (__lock_acquire+0x140c/0x1a64) from [] (lock_acquire+0x9c/0x104) [] (lock_acquire+0x9c/0x104) from [] (_raw_spin_lock_irqsave+0x44/0x58) [] (_raw_spin_lock_irqsave+0x44/0x58) from [] (__irq_get_desc_lock+0x48/0x88) [] (__irq_get_desc_lock+0x48/0x88) from [] (irq_set_irq_wake+0x20/0xf4) [] (irq_set_irq_wake+0x20/0xf4) from [] (mxs_gpio_set_wake_irq+0x1c/0x24) [] (mxs_gpio_set_wake_irq+0x1c/0x24) from [] (set_irq_wake_real+0x30/0x44) [] (set_irq_wake_real+0x30/0x44) from [] (irq_set_irq_wake+0x8c/0xf4) [] (irq_set_irq_wake+0x8c/0xf4) from [] (wlcore_nvs_cb+0x10c/0x97c) [] (wlcore_nvs_cb+0x10c/0x97c) from [] (request_firmware_work_func+0x38/0x58) [] (request_firmware_work_func+0x38/0x58) from [] (process_one_work+0x1c0/0x4a4) [] (process_one_work+0x1c0/0x4a4) from [] (worker_thread+0x138/0x394) [] (worker_thread+0x138/0x394) from [] (kthread+0xa4/0xb0) [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x34) wlcore: loaded Signed-off-by: Marek Vasut Acked-by: Shawn Guo Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192se: Fix too long disable of IRQs

2014-05-13T12:11:31+00:00

commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192se. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192cu: Fix too long disable of IRQs

2014-05-13T12:11:31+00:00

commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192cu. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

libata/ahci: accommodate tag ordered controllers

2014-05-13T12:11:31+00:00

commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream. The AHCI spec allows implementations to issue commands in tag order rather than FIFO order: 5.3.2.12 P:SelectCmd HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1) or HBA selects the command to issue that has had the PxCI bit set to '1' longer than any other command pending to be issued. The result is that commands posted sequentially (time-wise) may play out of sequence when issued by hardware. This behavior has likely been hidden by drives that arrange for commands to complete in issue order. However, it appears recent drives (two from different vendors that we have found so far) inflict out-of-order completions as a matter of course. So, we need to take care to maintain ordered submission, otherwise we risk triggering a drive to fall out of sequential-io automation and back to random-io processing, which incurs large latency and degrades throughput. This issue was found in simple benchmarks where QD=2 seq-write performance was 30-50% *greater* than QD=32 seq-write performance. Tagging for -stable and making the change globally since it has a low risk-to-reward ratio. Also, word is that recent versions of an unnamed OS also does it this way now. So, drives in the field are already experienced with this tag ordering scheme. Cc: Dave Jiang Cc: Ed Ciechanowski Reviewed-by: Matthew Wilcox Signed-off-by: Dan Williams Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR

2014-05-13T12:11:31+00:00

commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream. Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b functions isn't safe. On my machine it causes delayed (!) CPU exception: Disabling lock debugging due to kernel taint mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f mce: [Hardware Error]: TSC 164083803dc mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Processor context corrupt Kernel panic - not syncing: Fatal machine check on current CPU Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) Signed-off-by: Rafał Miłecki Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman