commit 7fc878164dd8bc7812eb774e728f2cc1ffe905ed Author: Greg Kroah-Hartman Date: Sun Oct 13 16:08:56 2013 -0700 Linux 3.10.16 commit 84c8b3b9e17107a74f07dc5e48264034f1410b97 Author: Kent Overstreet Date: Thu Oct 10 17:31:15 2013 -0700 bcache: Fix a null ptr deref regression commit 2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306 upstream. Commit c0f04d88e46d ("bcache: Fix flushes in writeback mode") was fixing a reported data corruption bug, but it seems some last minute refactoring or rebasing introduced a null pointer deref. Signed-off-by: Kent Overstreet Reported-by: Gabriel de Perthuis Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit adf0931b2b3ce91cc4096939650f4c4a3f68fef5 Author: Bjørn Mork Date: Tue Sep 10 15:06:20 2013 +0200 net: qmi_wwan: add new Qualcomm devices commit 0470667caa8261beb8a9141102b04a5357dd45b5 upstream. Adding the device list from the Windows driver description files included with a new Qualcomm MDM9615 based device, "Alcatel-sbell ASB TL131 TDD LTE", from China Mobile. This device is tested and verified to work. The others are assumed to work based on using the same Windows driver. Many of these devices support multiple QMI/wwan ports, requiring multiple interface matching entries. All devices are composite, providing a mix of one or more serial, storage or Android Debug Brigde functions in addition to the wwan function. This device list included an update of one previously known device, which was incorrectly assumed to have a Gobi 2K layout. This is corrected. Reported-by: 王康 Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0e01faab5690ff1674f659abb5ef719be6ef549d Author: David Herrmann Date: Mon Sep 9 18:33:54 2013 +0200 HID: uhid: allocate static minor commit 19872d20c890073c5207d9e02bb8f14d451a11eb upstream. udev has this nice feature of creating "dead" /dev/ device-nodes if it finds a devnode: modalias. Once the node is accessed, the kernel automatically loads the module that provides the node. However, this requires udev to know the major:minor code to use for the node. This feature was introduced by: commit 578454ff7eab61d13a26b568f99a89a2c9edc881 Author: Kay Sievers Date: Thu May 20 18:07:20 2010 +0200 driver core: add devname module aliases to allow module on-demand auto-loading However, uhid uses dynamic minor numbers so this doesn't actually work. We need to load uhid to know which minor it's going to use. Hence, allocate a static minor (just like uinput does) and we're good to go. Reported-by: Tom Gundersen Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1685c9903b259801b4e1c6c0c325f364742f28f4 Author: Marcel Holtmann Date: Sun Sep 1 11:02:46 2013 -0700 HID: uhid: add devname module alias commit 60cbd53e4bf623fe978e6f23a6da642e730fde3a upstream. For simple device node creation, add the devname module alias. Signed-off-by: Marcel Holtmann Reviewed-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a873420aa42b4c96a9ea9900855856bfea8558d2 Author: Stefan Achatz Date: Fri Aug 30 14:10:07 2013 +0200 HID: roccat: add support for KonePureOptical v2 commit a4be0ed39f2b1ea990804ea54e39bc42d17ed5a5 upstream. KonePureOptical is a KonePure with different sensor. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 322d9a97c490b890975e0d61f2b034bc18ea1100 Author: Josef Bacik Date: Thu Aug 22 17:03:29 2013 -0400 Btrfs: remove ourselves from the cluster list under lock commit b8d0c69b9469ffd33df30fee3e990f2d4aa68a09 upstream. A user was reporting weird warnings from btrfs_put_delayed_ref() and I noticed that we were doing this list_del_init() on our head ref outside of delayed_refs->lock. This is a problem if we have people still on the list, we could end up modifying old pointers and such. Fix this by removing us from the list before we do our run_delayed_ref on our head ref. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 0ac5762ca876c8554cea6e8a05422d561b98947f Author: Josef Bacik Date: Mon Aug 12 10:56:14 2013 -0400 Btrfs: skip subvol entries when checking if we've created a dir already commit a05254143cd183b18002cbba7759a1e4629aa762 upstream. We have logic to see if we've already created a parent directory by check to see if an inode inside of that directory has a lower inode number than the one we are currently processing. The logic is that if there is a lower inode number then we would have had to made sure the directory was created at that previous point. The problem is that subvols inode numbers count from the lowest objectid in the root tree, which may be less than our current progress. So just skip if our dir item key is a root item. This fixes the original test and the xfstest version I made that added an extra subvol create. Thanks, Reported-by: Emil Karlson Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 34aa872c2cea9518bba66ab8d88bc0f90dbeb2ba Author: Josef Bacik Date: Tue Jul 30 16:30:30 2013 -0400 Btrfs: change how we queue blocks for backref checking commit b6c60c8018c4e9beb2f83fc82c09f9d033766571 upstream. Previously we only added blocks to the list to have their backrefs checked if the level of the block is right above the one we are searching for. This is because we want to make sure we don't add the entire path up to the root to the lists to make sure we process things one at a time. This assumes that if any blocks in the path to the root are going to be not checked (shared in other words) then they will be in the level right above the current block on up. This isn't quite right though since we can have blocks higher up the list that are shared because they are attached to a reloc root. But we won't add this block to be checked and then later on we will BUG_ON(!upper->checked). So instead keep track of wether or not we've queued a block to be checked in this current search, and if we haven't go ahead and queue it to be checked. This patch fixed the panic I was seeing where we BUG_ON(!upper->checked). Thanks, Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 98e00cd81b76f8b50b881bf3ac532fa1ab42931c Author: Martin Schwidefsky Date: Fri Sep 27 15:24:38 2013 +0200 s390: fix system call restart after inferior call commit dbbfe487e5f3fc00c9fe5207d63309859704d12f upstream. Git commit 616498813b11ffef "s390: system call path micro optimization" introduced a regression in regard to system call restarting and inferior function calls via the ptrace interface. The pointer to the system call table needs to be loaded in sysc_sigpending if do_signal returns with TIF_SYSCALl set after it restored a system call context. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit bc30c3576d85f7d02f5620cbe8d03f4064c6a73a Author: Chris Metcalf Date: Thu Sep 26 13:24:53 2013 -0400 tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT commit f862eefec0b68e099a9fa58d3761ffb10bad97e1 upstream. It turns out the kernel relies on barrier() to force a reload of the percpu offset value. Since we can't easily modify the definition of barrier() to include "tp" as an output register, we instead provide a definition of __my_cpu_offset as extended assembly that includes a fake stack read to hazard against barrier(), forcing gcc to know that it must reread "tp" and recompute anything based on "tp" after a barrier. This fixes observed hangs in the slub allocator when we are looping on a percpu cmpxchg_double. A similar fix for ARMv7 was made in June in change 509eb76ebf97. Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit 22c748d6172867030c228d4737fdef0e9713a125 Author: Takashi Iwai Date: Mon Sep 30 12:13:44 2013 +0200 ALSA: hda - Fix GPIO for Acer Aspire 3830TG commit 4a4370442c996be0fd08234a167c8a127c2488bb upstream. Acer Aspire 3830TG seems requiring GPIO bit 0 as the primary mute control. When a machine is booted after Windows 8, the GPIO pin is turned off and it results in the silent output. This patch adds the manual fixup of GPIO bit 0 for this model. Reported-by: Christopher Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f60945fd5684f5773efd2d87d383f528056d6285 Author: Ben Skeggs Date: Tue Sep 10 12:11:01 2013 +1000 drm/nouveau/bios/init: stub opcode 0xaa commit 5495e39fb3695182b9f2a72fe4169056cada37a1 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 1fe36ec4914c34f63ea93c87ce6997606098628d Author: Mark Tinguely Date: Mon Sep 23 12:18:58 2013 -0500 xfs: fix node forward in xfs_node_toosmall commit 997def25e4b9cee3b01609e18a52f926bca8bd2b upstream. Commit f5ea1100 cleans up the disk to host conversions for node directory entries, but because a variable is reused in xfs_node_toosmall() the next node is not correctly found. If the original node is small enough (<= 3/8 of the node size), this change may incorrectly cause a node collapse when it should not. That will cause an assert in xfstest generic/319: Assertion failed: first <= last && last < BBTOB(bp->b_length), file: /root/newest/xfs/fs/xfs/xfs_trans_buf.c, line: 569 Keep the original node header to get the correct forward node. (When a node is considered for a merge with a sibling, it overwrites the sibling pointers of the original incore nodehdr with the sibling's pointers. This leads to loop considering the original node as a merge candidate with itself in the second pass, and so it incorrectly determines a merge should occur.) [v3: added Dave Chinner's (slightly modified) suggestion to the commit header, cleaned up whitespace. -bpm] Signed-off-by: Mark Tinguely Reviewed-by: Ben Myers Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit 2af8997a301609e2664c3c619865c6e1e518257d Author: Lv Zheng Date: Fri Sep 13 13:13:23 2013 +0800 ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler() commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream. This patch fixes the issues indicated by the test results that ipmi_msg_handler() is invoked in atomic context. BUG: scheduling while atomic: kipmi0/18933/0x10000100 Modules linked in: ipmi_si acpi_ipmi ... CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G AW 3.10.0-rc7+ #2 Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010 ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8 ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4 0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8 Call Trace: [] dump_stack+0x19/0x1b [] __schedule_bug+0x46/0x54 [] __schedule+0x83/0x59c [] __cond_resched+0x22/0x2d [] _cond_resched+0x14/0x1d [] mutex_lock+0x11/0x32 [] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58 [] ipmi_msg_handler+0x23/0x166 [ipmi_si] [] deliver_response+0x55/0x5a [] handle_new_recv_msgs+0xb67/0xc65 [] ? read_tsc+0x9/0x19 [] ? _raw_spin_lock_irq+0xa/0xc [] ipmi_thread+0x5c/0x146 [ipmi_si] ... Also Tony Camuso says: We were getting occasional "Scheduling while atomic" call traces during boot on some systems. Problem was first seen on a Cisco C210 but we were able to reproduce it on a Cisco c220m3. Setting CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device. ================================= [ INFO: inconsistent lock state ] 2.6.32-415.el6.x86_64-debug-splck #1 --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes: (&ipmi_device->tx_msg_lock){+.?...}, at: [] ipmi_msg_handler+0x71/0x126 {SOFTIRQ-ON-W} state was registered at: [] __lock_acquire+0x63c/0x1570 [] lock_acquire+0xa4/0x120 [] __mutex_lock_common+0x4c/0x400 [] mutex_lock_nested+0x4a/0x60 [] acpi_ipmi_space_handler+0x11b/0x234 [] acpi_ev_address_space_dispatch+0x170/0x1be The fix implemented by this change has been tested by Tony: Tested the patch in a boot loop with lockdep debug enabled and never saw the problem in over 400 reboots. Reported-and-tested-by: Tony Camuso Signed-off-by: Lv Zheng Reviewed-by: Huang Ying Signed-off-by: Rafael J. Wysocki Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 414224fc002fc88c1f79934c12756f40510ff710 Author: Michael Grzeschik Date: Tue Sep 17 15:56:06 2013 +0200 dmaengine: imx-dma: fix slow path issue in prep_dma_cyclic commit edc530fe7ee5a562680615d2e7cd205879c751a7 upstream. When perparing cyclic_dma buffers by the sound layer, it will dump the following lockdep trace. The leading snd_pcm_action_single get called with read_lock_irq called. To fix this, we change the kcalloc call from GFP_KERNEL to GFP_ATOMIC. WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xcc/0x114() DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) Modules linked in: CPU: 0 PID: 832 Comm: aplay Not tainted 3.11.0-20130823+ #903 Backtrace: [] (dump_backtrace+0x0/0x10c) from [] (show_stack+0x18/0x1c) r6:c004c090 r5:00000009 r4:c2e0bd18 r3:00404000 [] (show_stack+0x0/0x1c) from [] (dump_stack+0x20/0x28) [] (dump_stack+0x0/0x28) from [] (warn_slowpath_common+0x54/0x70) [] (warn_slowpath_common+0x0/0x70) from [] (warn_slowpath_fmt+0x38/0x40) r8:00004000 r7:a3b90000 r6:000080d0 r5:60000093 r4:c2e0a000 r3:00000009 [] (warn_slowpath_fmt+0x0/0x40) from [] (lockdep_trace_alloc+0xcc/0x114) r3:c03955d8 r2:c03907db [] (lockdep_trace_alloc+0x0/0x114) from [] (__kmalloc+0x34/0x118) r6:000080d0 r5:c3800120 r4:000080d0 r3:c040a0f8 [] (__kmalloc+0x0/0x118) from [] (imxdma_prep_dma_cyclic+0x64/0x168) r7:a3b90000 r6:00000004 r5:c39d8420 r4:c3847150 [] (imxdma_prep_dma_cyclic+0x0/0x168) from [] (snd_dmaengine_pcm_trigger+0xa8/0x160) [] (snd_dmaengine_pcm_trigger+0x0/0x160) from [] (soc_pcm_trigger+0x90/0xb4) r8:c058c7b0 r7:c3b8140c r6:c39da560 r5:00000001 r4:c3b81000 [] (soc_pcm_trigger+0x0/0xb4) from [] (snd_pcm_do_start+0x2c/0x38) r7:00000000 r6:00000003 r5:c058c7b0 r4:c3b81000 [] (snd_pcm_do_start+0x0/0x38) from [] (snd_pcm_action_single+0x40/0x6c) [] (snd_pcm_action_single+0x0/0x6c) from [] (snd_pcm_action_lock_irq+0x7c/0x9c) r7:00000003 r6:c3b810f0 r5:c3b810f0 r4:c3b81000 [] (snd_pcm_action_lock_irq+0x0/0x9c) from [] (snd_pcm_common_ioctl1+0x7f8/0xfd0) r8:c3b7f888 r7:005407b8 r6:c2c991c0 r5:c3b81000 r4:c3b81000 r3:00004142 [] (snd_pcm_common_ioctl1+0x0/0xfd0) from [] (snd_pcm_playback_ioctl1+0x464/0x488) [] (snd_pcm_playback_ioctl1+0x0/0x488) from [] (snd_pcm_playback_ioctl+0x34/0x40) r8:c3b7f888 r7:00004142 r6:00000004 r5:c2c991c0 r4:005407b8 [] (snd_pcm_playback_ioctl+0x0/0x40) from [] (vfs_ioctl+0x30/0x44) [] (vfs_ioctl+0x0/0x44) from [] (do_vfs_ioctl+0x55c/0x5c0) [] (do_vfs_ioctl+0x0/0x5c0) from [] (SyS_ioctl+0x40/0x68) [] (SyS_ioctl+0x0/0x68) from [] (ret_fast_syscall+0x0/0x44) r8:c0009544 r7:00000036 r6:bedeaa58 r5:00000000 r4:000000c0 Signed-off-by: Michael Grzeschik Signed-off-by: Vinod Koul Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 8dac1d15489d284a4ffadaef25650272c4b44bfe Author: Michael Grzeschik Date: Tue Sep 17 15:56:08 2013 +0200 dmaengine: imx-dma: fix callback path in tasklet commit fcaaba6c7136fe47e5a13352f99a64b019b6d2c5 upstream. We need to free the ld_active list head before jumping into the callback routine. Otherwise the callback could run into issue_pending and change our ld_active list head we just going to free. This will run the channel list into an currupted and undefined state. Signed-off-by: Michael Grzeschik Signed-off-by: Vinod Koul Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 16c72f379e4fdc8b0438f729ecd261428fff4c21 Author: Michael Grzeschik Date: Tue Sep 17 15:56:07 2013 +0200 dmaengine: imx-dma: fix lockdep issue between irqhandler and tasklet commit 5a276fa6bdf82fd442046969603968c83626ce0b upstream. The tasklet and irqhandler are using spin_lock while other routines are using spin_lock_irqsave/restore. This leads to lockdep issues as described bellow. This patch is changing the code to use spinlock_irq_save/restore in both code pathes. As imxdma_xfer_desc always gets called with spin_lock_irqsave lock held, this patch also removes the spare call inside the routine to avoid double locking. [ 403.358162] ================================= [ 403.362549] [ INFO: inconsistent lock state ] [ 403.366945] 3.10.0-20130823+ #904 Not tainted [ 403.371331] --------------------------------- [ 403.375721] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 403.381769] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 403.386762] (&(&imxdma->lock)->rlock){?.-...}, at: [] imxdma_tasklet+0x20/0x134 [ 403.395201] {IN-HARDIRQ-W} state was registered at: [ 403.400108] [] mark_lock+0x2a0/0x6b4 [ 403.404798] [] __lock_acquire+0x650/0x1a64 [ 403.410004] [] lock_acquire+0x94/0xa8 [ 403.414773] [] _raw_spin_lock+0x54/0x8c [ 403.419720] [] dma_irq_handler+0x78/0x254 [ 403.424845] [] handle_irq_event_percpu+0x38/0x1b4 [ 403.430670] [] handle_irq_event+0x44/0x64 [ 403.435789] [] handle_level_irq+0xd8/0xf0 [ 403.440903] [] generic_handle_irq+0x28/0x38 [ 403.446194] [] handle_IRQ+0x68/0x8c [ 403.450789] [] avic_handle_irq+0x3c/0x48 [ 403.455811] [] __irq_svc+0x44/0x74 [ 403.460314] [] cpu_startup_entry+0x88/0xf4 [ 403.465525] [] rest_init+0xb8/0xe0 [ 403.470045] [] start_kernel+0x28c/0x2d4 [ 403.474986] [] 0xa0008040 [ 403.478709] irq event stamp: 50854 [ 403.482140] hardirqs last enabled at (50854): [] tasklet_action+0x38/0xdc [ 403.489954] hardirqs last disabled at (50853): [] tasklet_action+0x20/0xdc [ 403.497761] softirqs last enabled at (50850): [] _local_bh_enable+0x14/0x18 [ 403.505741] softirqs last disabled at (50851): [] irq_exit+0x88/0xdc [ 403.513026] [ 403.513026] other info that might help us debug this: [ 403.519593] Possible unsafe locking scenario: [ 403.519593] [ 403.525548] CPU0 [ 403.528020] ---- [ 403.530491] lock(&(&imxdma->lock)->rlock); [ 403.534828] [ 403.537474] lock(&(&imxdma->lock)->rlock); [ 403.541983] [ 403.541983] *** DEADLOCK *** [ 403.541983] [ 403.547951] no locks held by swapper/0. [ 403.551813] [ 403.551813] stack backtrace: [ 403.556222] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-20130823+ #904 [ 403.563039] Backtrace: [ 403.565581] [] (dump_backtrace+0x0/0x10c) from [] (show_stack+0x18/0x1c) [ 403.574054] r6:00000000 r5:c05c51d8 r4:c040bd58 r3:00200000 [ 403.579872] [] (show_stack+0x0/0x1c) from [] (dump_stack+0x20/0x28) [ 403.587955] [] (dump_stack+0x0/0x28) from [] (print_usage_bug.part.28+0x224/0x28c) [ 403.597340] [] (print_usage_bug.part.28+0x0/0x28c) from [] (mark_lock+0x440/0x6b4) [ 403.606682] r8:c004a41c r7:00000000 r6:c040bd58 r5:c040c040 r4:00000002 [ 403.613566] [] (mark_lock+0x0/0x6b4) from [] (__lock_acquire+0x6cc/0x1a64) [ 403.622244] [] (__lock_acquire+0x0/0x1a64) from [] (lock_acquire+0x94/0xa8) [ 403.631010] [] (lock_acquire+0x0/0xa8) from [] (_raw_spin_lock+0x54/0x8c) [ 403.639614] [] (_raw_spin_lock+0x0/0x8c) from [] (imxdma_tasklet+0x20/0x134) [ 403.648434] r6:c3847010 r5:c040e890 r4:c38470d4 [ 403.653194] [] (imxdma_tasklet+0x0/0x134) from [] (tasklet_action+0x8c/0xdc) [ 403.662013] r8:c0599160 r7:00000000 r6:00000000 r5:c040e890 r4:c3847114 r3:c019d75c [ 403.670042] [] (tasklet_action+0x0/0xdc) from [] (__do_softirq+0xe4/0x1f0) [ 403.678687] r7:00000101 r6:c0402000 r5:c059919c r4:00000001 [ 403.684498] [] (__do_softirq+0x0/0x1f0) from [] (irq_exit+0x88/0xdc) [ 403.692652] [] (irq_exit+0x0/0xdc) from [] (handle_IRQ+0x6c/0x8c) [ 403.700514] r4:00000030 r3:00000110 [ 403.704192] [] (handle_IRQ+0x0/0x8c) from [] (avic_handle_irq+0x3c/0x48) [ 403.712664] r5:c0403f28 r4:c0593ebc [ 403.716343] [] (avic_handle_irq+0x0/0x48) from [] (__irq_svc+0x44/0x74) [ 403.724733] Exception stack(0xc0403f28 to 0xc0403f70) [ 403.729841] 3f20: 00000001 00000004 00000000 20000013 c0402000 c04104a8 [ 403.738078] 3f40: 00000002 c0b69620 a0004000 41069264 a03fb5f4 c0403f7c c0403f40 c0403f70 [ 403.746301] 3f60: c004b92c c0009e74 20000013 ffffffff [ 403.751383] r6:ffffffff r5:20000013 r4:c0009e74 r3:c004b92c [ 403.757210] [] (arch_cpu_idle+0x0/0x4c) from [] (cpu_startup_entry+0x88/0xf4) [ 403.766161] [] (cpu_startup_entry+0x0/0xf4) from [] (rest_init+0xb8/0xe0) [ 403.774753] [] (rest_init+0x0/0xe0) from [] (start_kernel+0x28c/0x2d4) [ 403.783051] r6:c03fc484 r5:ffffffff r4:c040a0e0 [ 403.787797] [] (start_kernel+0x0/0x2d4) from [] (0xa0008040) Signed-off-by: Michael Grzeschik Signed-off-by: Vinod Koul Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 04283173f26643e0075fbdf95780f548576e30a5 Author: Rafał Miłecki Date: Thu Oct 10 07:56:07 2013 +0200 Revert "drm/radeon: add missing hdmi callbacks for rv6xx" This reverts commit b2a9484006875ecd7d94582e7bcb72a02682be92. Commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 (backported by b2a9484006875ecd7d94582e7bcb72a02682be92) was supposed to fix rv6xx_asic struct. In kernel 3.10 we didn't have that struct yet, so the original patch should never be backported to the 3.10. Accidentally it has applied and modified different struct (r520_asic) that shouldn't have any HDMI callbacks at all. Signed-off-by: Rafał Miłecki Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6dcdd5759f76c88ae86f9a98a232199520b6cc22 Author: Frederic Weisbecker Date: Tue Sep 24 00:50:25 2013 +0200 irq: Force hardirq exit's softirq processing on its own stack commit ded797547548a5b8e7b92383a41e4c0e6b0ecb7f upstream. The commit facd8b80c67a3cf64a467c4a2ac5fb31f2e6745b ("irq: Sanitize invoke_softirq") converted irq exit calls of do_softirq() to __do_softirq() on all architectures, assuming it was only used there for its irq disablement properties. But as a side effect, the softirqs processed in the end of the hardirq are always called on the inline current stack that is used by irq_exit() instead of the softirq stack provided by the archs that override do_softirq(). The result is mostly safe if the architecture runs irq_exit() on a separate irq stack because then softirqs are processed on that same stack that is near empty at this stage (assuming hardirq aren't nesting). Otherwise irq_exit() runs in the task stack and so does the softirq too. The interrupted call stack can be randomly deep already and the softirq can dig through it even further. To add insult to the injury, this softirq can be interrupted by a new hardirq, maximizing the chances for a stack overrun as reported in powerpc for example: do_IRQ: stack overflow: 1920 CPU: 0 PID: 1602 Comm: qemu-system-ppc Not tainted 3.10.4-300.1.fc19.ppc64p7 #1 Call Trace: [c0000000050a8740] .show_stack+0x130/0x200 (unreliable) [c0000000050a8810] .dump_stack+0x28/0x3c [c0000000050a8880] .do_IRQ+0x2b8/0x2c0 [c0000000050a8930] hardware_interrupt_common+0x154/0x180 --- Exception: 501 at .cp_start_xmit+0x3a4/0x820 [8139cp] LR = .cp_start_xmit+0x390/0x820 [8139cp] [c0000000050a8d40] .dev_hard_start_xmit+0x394/0x640 [c0000000050a8e00] .sch_direct_xmit+0x110/0x260 [c0000000050a8ea0] .dev_queue_xmit+0x260/0x630 [c0000000050a8f40] .br_dev_queue_push_xmit+0xc4/0x130 [bridge] [c0000000050a8fc0] .br_dev_xmit+0x198/0x270 [bridge] [c0000000050a9070] .dev_hard_start_xmit+0x394/0x640 [c0000000050a9130] .dev_queue_xmit+0x428/0x630 [c0000000050a91d0] .ip_finish_output+0x2a4/0x550 [c0000000050a9290] .ip_local_out+0x50/0x70 [c0000000050a9310] .ip_queue_xmit+0x148/0x420 [c0000000050a93b0] .tcp_transmit_skb+0x4e4/0xaf0 [c0000000050a94a0] .__tcp_ack_snd_check+0x7c/0xf0 [c0000000050a9520] .tcp_rcv_established+0x1e8/0x930 [c0000000050a95f0] .tcp_v4_do_rcv+0x21c/0x570 [c0000000050a96c0] .tcp_v4_rcv+0x734/0x930 [c0000000050a97a0] .ip_local_deliver_finish+0x184/0x360 [c0000000050a9840] .ip_rcv_finish+0x148/0x400 [c0000000050a98d0] .__netif_receive_skb_core+0x4f8/0xb00 [c0000000050a99d0] .netif_receive_skb+0x44/0x110 [c0000000050a9a70] .br_handle_frame_finish+0x2bc/0x3f0 [bridge] [c0000000050a9b20] .br_nf_pre_routing_finish+0x2ac/0x420 [bridge] [c0000000050a9bd0] .br_nf_pre_routing+0x4dc/0x7d0 [bridge] [c0000000050a9c70] .nf_iterate+0x114/0x130 [c0000000050a9d30] .nf_hook_slow+0xb4/0x1e0 [c0000000050a9e00] .br_handle_frame+0x290/0x330 [bridge] [c0000000050a9ea0] .__netif_receive_skb_core+0x34c/0xb00 [c0000000050a9fa0] .netif_receive_skb+0x44/0x110 [c0000000050aa040] .napi_gro_receive+0xe8/0x120 [c0000000050aa0c0] .cp_rx_poll+0x31c/0x590 [8139cp] [c0000000050aa1d0] .net_rx_action+0x1dc/0x310 [c0000000050aa2b0] .__do_softirq+0x158/0x330 [c0000000050aa3b0] .irq_exit+0xc8/0x110 [c0000000050aa430] .do_IRQ+0xdc/0x2c0 [c0000000050aa4e0] hardware_interrupt_common+0x154/0x180 --- Exception: 501 at .bad_range+0x1c/0x110 LR = .get_page_from_freelist+0x908/0xbb0 [c0000000050aa7d0] .list_del+0x18/0x50 (unreliable) [c0000000050aa850] .get_page_from_freelist+0x908/0xbb0 [c0000000050aa9e0] .__alloc_pages_nodemask+0x21c/0xae0 [c0000000050aaba0] .alloc_pages_vma+0xd0/0x210 [c0000000050aac60] .handle_pte_fault+0x814/0xb70 [c0000000050aad50] .__get_user_pages+0x1a4/0x640 [c0000000050aae60] .get_user_pages_fast+0xec/0x160 [c0000000050aaf10] .__gfn_to_pfn_memslot+0x3b0/0x430 [kvm] [c0000000050aafd0] .kvmppc_gfn_to_pfn+0x64/0x130 [kvm] [c0000000050ab070] .kvmppc_mmu_map_page+0x94/0x530 [kvm] [c0000000050ab190] .kvmppc_handle_pagefault+0x174/0x610 [kvm] [c0000000050ab270] .kvmppc_handle_exit_pr+0x464/0x9b0 [kvm] [c0000000050ab320] kvm_start_lightweight+0x1ec/0x1fc [kvm] [c0000000050ab4f0] .kvmppc_vcpu_run_pr+0x168/0x3b0 [kvm] [c0000000050ab9c0] .kvmppc_vcpu_run+0xc8/0xf0 [kvm] [c0000000050aba50] .kvm_arch_vcpu_ioctl_run+0x5c/0x1a0 [kvm] [c0000000050abae0] .kvm_vcpu_ioctl+0x478/0x730 [kvm] [c0000000050abc90] .do_vfs_ioctl+0x4ec/0x7c0 [c0000000050abd80] .SyS_ioctl+0xd4/0xf0 [c0000000050abe30] syscall_exit+0x0/0x98 Since this is a regression, this patch proposes a minimalistic and low-risk solution by blindly forcing the hardirq exit processing of softirqs on the softirq stack. This way we should reduce significantly the opportunities for task stack overflow dug by softirqs. Longer term solutions may involve extending the hardirq stack coverage to irq_exit(), etc... Reported-by: Benjamin Herrenschmidt Acked-by: Linus Torvalds Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan Cc: James E.J. Bottomley Cc: Helge Deller Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: David S. Miller Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit acbf720a11a80b0d284f6654bb2acc7404536037 Author: Eric W. Biederman Date: Sat Oct 5 13:15:30 2013 -0700 net: Update the sysctl permissions handler to test effective uid/gid commit 2433c8f094a008895e66f25bd1773cdb01c91d01 upstream. Modify the code to use current_euid(), and in_egroup_p, as in done in fs/proc/proc_sysctl.c:test_perm() Reviewed-by: Eric Sandeen Reported-by: Eric Sandeen Signed-off-by: "Eric W. Biederman" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a0348152bd365caadc105f11da03fc020bcc6226 Author: Nicholas Bellinger Date: Thu Oct 3 13:37:21 2013 -0700 iscsi-target: Only perform wait_for_tasks when performing shutdown commit e255a28598e8e63070322fc89bd34189dd660a89 upstream. This patch changes transport_generic_free_cmd() to only wait_for_tasks when shutdown=true is passed to iscsit_free_cmd(). With the advent of >= v3.10 iscsi-target code using se_cmd->cmd_kref, the extra wait_for_tasks with shutdown=false is unnecessary, and may end up causing an extra context switch when releasing WRITEs. Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 009dfd4415d898150824d352905fcb80ae1de16e Author: Rafael Aquini Date: Mon Sep 30 13:45:16 2013 -0700 mm: avoid reinserting isolated balloon pages into LRU lists commit 117aad1e9e4d97448d1df3f84b08bd65811e6d6a upstream. Isolated balloon pages can wrongly end up in LRU lists when migrate_pages() finishes its round without draining all the isolated page list. The same issue can happen when reclaim_clean_pages_from_list() tries to reclaim pages from an isolated page list, before migration, in the CMA path. Such balloon page leak opens a race window against LRU lists shrinkers that leads us to the following kernel panic: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] shrink_page_list+0x24e/0x897 PGD 3cda2067 PUD 3d713067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 340 Comm: kswapd0 Not tainted 3.12.0-rc1-22626-g4367597 #87 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: shrink_page_list+0x24e/0x897 RSP: 0000:ffff88003da499b8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88003e82bd60 RCX: 00000000000657d5 RDX: 0000000000000000 RSI: 000000000000031f RDI: ffff88003e82bd40 RBP: ffff88003da49ab0 R08: 0000000000000001 R09: 0000000081121a45 R10: ffffffff81121a45 R11: ffff88003c4a9a28 R12: ffff88003e82bd40 R13: ffff88003da0e800 R14: 0000000000000001 R15: ffff88003da49d58 FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000067d9000 CR3: 000000003ace5000 CR4: 00000000000407b0 Call Trace: shrink_inactive_list+0x240/0x3de shrink_lruvec+0x3e0/0x566 __shrink_zone+0x94/0x178 shrink_zone+0x3a/0x82 balance_pgdat+0x32a/0x4c2 kswapd+0x2f0/0x372 kthread+0xa2/0xaa ret_from_fork+0x7c/0xb0 Code: 80 7d 8f 01 48 83 95 68 ff ff ff 00 4c 89 e7 e8 5a 7b 00 00 48 85 c0 49 89 c5 75 08 80 7d 8f 00 74 3e eb 31 48 8b 80 18 01 00 00 <48> 8b 74 0d 48 8b 78 30 be 02 00 00 00 ff d2 eb RIP [] shrink_page_list+0x24e/0x897 RSP CR2: 0000000000000028 ---[ end trace 703d2451af6ffbfd ]--- Kernel panic - not syncing: Fatal exception This patch fixes the issue, by assuring the proper tests are made at putback_movable_pages() & reclaim_clean_pages_from_list() to avoid isolated balloon pages being wrongly reinserted in LRU lists. [akpm@linux-foundation.org: clarify awkward comment text] Signed-off-by: Rafael Aquini Reported-by: Luiz Capitulino Tested-by: Luiz Capitulino Cc: Mel Gorman Cc: Rik van Riel Cc: Hugh Dickins Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3e1972928dc7221bbf81c138667aa5d131623dce Author: Christian Lamparter Date: Tue Sep 24 21:56:46 2013 +0200 p54usb: add USB ID for Corega WLUSB2GTST USB adapter commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream. Added USB ID for Corega WLUSB2GTST USB adapter. Reported-by: Joerg Kalisch Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c00095f3c4dcafb0031cbab8abb43787efa7ee64 Author: Larry Finger Date: Wed Sep 18 21:21:35 2013 -0500 rtlwifi: Align private space in rtl_priv struct commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream. The private array at the end of the rtl_priv struct is not aligned. On ARM architecture, this causes an alignment trap and is fixed by aligning that array with __align(sizeof(void *)). That should properly align that space according to the requirements of all architectures. Reported-by: Jason Andrews Tested-by: Jason Andrews Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b07ce93054a72fe89b42096f7603afe3395a95ea Author: Jack Wang Date: Mon Sep 30 10:09:05 2013 +0200 ib_srpt: always set response for task management commit c807f64340932e19f0d2ac9b30c8381e1f60663a upstream. The SRP specification requires: "Response data shall be provided in any SRP_RSP response that is sent in response to an SRP_TSK_MGMT request (see 6.7). The information in the RSP_CODE field (see table 24) shall indicate the completion status of the task management function." So fix this to avoid the SRP initiator interprets task management functions that succeeded as failed. Signed-off-by: Jack Wang Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 5b97382398dda31ca38a8c62880a21af03cf6f7f Author: Nicholas Bellinger Date: Wed Sep 18 12:48:27 2013 -0700 ib_srpt: Destroy cm_id before destroying QP. commit 0b41d6ca616ddeb3b6c0a80e8770b6f53cd42806 upstream. This patch fixes a bug where ib_destroy_cm_id() was incorrectly being called after srpt_destroy_ch_ib() had destroyed the active QP. This would result in the following failed SRP_LOGIN_REQ messages: Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff1762bd, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c903009f8f41) Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff1758f9, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 2 (guid=0xfe80000000000000:0x2c903009f8f42) Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff175941, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 2 (guid=0xfe80000000000000:0x2c90300a3cfb2) Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1) mlx4_core 0000:84:00.0: command 0x19 failed: fw status = 0x9 rejected SRP_LOGIN_REQ because creating a new RDMA channel failed. Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1) mlx4_core 0000:84:00.0: command 0x19 failed: fw status = 0x9 rejected SRP_LOGIN_REQ because creating a new RDMA channel failed. Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1) Reported-by: Navin Ahuja Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 8598a32d43af4abe6f3a464af8be7fc020080cf3 Author: David Vrabel Date: Tue Oct 1 19:00:49 2013 +0100 xen/hvc: allow xenboot console to be used again commit a9fbf4d591da6cd1d3eaab826c7c15f77fc8f6a3 upstream. Commit d0380e6c3c0f6edb986d8798a23acfaf33d5df23 (early_printk: consolidate random copies of identical code) added in 3.10 introduced a check for con->index == -1 in early_console_register(). Initialize index to -1 for the xenboot console so earlyprintk=xen works again. Signed-off-by: David Vrabel Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 1b069646f53350d9c1188cef6d6bdd09a1df8b44 Author: Michal Malý Date: Sat Sep 28 19:50:27 2013 +0200 USB: serial: option: Ignore card reader interface on Huawei E1750 commit eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream. Hi, my Huawei 3G modem has an embedded Smart Card reader which causes trouble when the modem is being detected (a bunch of " (ttyUSBx): open blocked by driver for more than 7 seconds!" in messages.log). This trivial patch corrects the problem for me. The modem identifies itself as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the description on the body says "Model E173u-1" Signed-off-by: Michal Malý Cc: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit e54fcd5bcf04a1623e0cd5bf1eff5948d5666990 Author: Bing Zhao Date: Fri Sep 20 19:56:45 2013 -0700 mwifiex: fix PCIe hs_cfg cancel cmd timeout commit b7be1522def9a9988b67afd0be999c50a96394b5 upstream. For pcie8897, the hs_cfg cancel command (0xe5) times out when host comes out of suspend. This is caused by an incompleted host sleep handshake between driver and firmware. Like SDIO interface, PCIe also needs to go through firmware power save events to complete the handshake for host sleep configuration. Only USB interface doesn't require power save events for hs_cfg. Signed-off-by: Bing Zhao Signed-off-by: Amitkumar Karwar Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 88fb132a74d2352bcabff8e6b1443210e9b99e9d Author: Amitkumar Karwar Date: Tue Sep 24 19:31:24 2013 -0700 mwifiex: fix hang issue for USB chipsets commit bd1c6142edce787b8ac1be15635f845aa9905333 upstream. Bug 60815 - Interface hangs in mwifiex_usb https://bugzilla.kernel.org/show_bug.cgi?id=60815 We have 4 bytes of interface header for packets delivered to SDIO and PCIe, but not for USB interface. In Tx AMSDU case, currently 4 bytes of garbage data is unnecessarily appended for USB packets. This sometimes leads to a firmware hang, because it may not interpret the data packet correctly. Problem is fixed by removing this redundant headroom for USB. Tested-by: Dmitry Khromov Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c7a448c3372a03c2a0848ed2c5c0ee76518a77b6 Author: Bing Zhao Date: Tue Sep 24 19:31:25 2013 -0700 mwifiex: fix NULL pointer dereference in usb suspend handler commit 346ece0b7ba2730b4d633b9e371fe55488803102 upstream. Bug 60815 - Interface hangs in mwifiex_usb https://bugzilla.kernel.org/show_bug.cgi?id=60815 [ 2.883807] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 2.883813] IP: [] pfifo_fast_enqueue+0x90/0x90 [ 2.883834] CPU: 1 PID: 3220 Comm: kworker/u8:90 Not tainted 3.11.1-monotone-l0 #6 [ 2.883834] Hardware name: Microsoft Corporation Surface with Windows 8 Pro/Surface with Windows 8 Pro, BIOS 1.03.0450 03/29/2013 On Surface Pro, suspend to ram gives a NULL pointer dereference in pfifo_fast_enqueue(). The stack trace reveals that the offending call is clearing carrier in mwifiex_usb suspend handler. Since commit 1499d9f "mwifiex: don't drop carrier flag over suspend" has removed the carrier flag handling over suspend/resume in SDIO and PCIe drivers, I'm removing it in USB driver too. This also fixes the bug for Surface Pro. Tested-by: Dmitry Khromov Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 28f7ae257183e8064119db486190d2229caae369 Author: Trond Myklebust Date: Thu Sep 26 14:08:36 2013 -0400 NFSv4.1: nfs4_fl_prepare_ds - fix bugs when the connect attempt fails commit 52b26a3e1bb3e065c32b3febdac1e1f117d88e15 upstream. - Fix an Oops when nfs4_ds_connect() returns an error. - Always check the device status after waiting for a connect to complete. Reported-by: Andy Adamson Reported-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 96baebd41aab7e82b6d6083d8f31c482dd5a576e Author: Ian Abbott Date: Wed Oct 2 14:57:51 2013 +0100 staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice commit 677a31565692d596ef42ea589b53ba289abf4713 upstream. The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that currently writes (optionally) and reads back up to 5 "ports" consisting of 8 channels each. It reads up to 32 1-bit channels but can only read and write a whole port at once - it needs to handle up to 5 ports as the first channel it reads might not be aligned on a port boundary. It breaks out of the loop early if the next port it handles is beyond the final port on the card. It also breaks out early on the 5th port in the loop if the first channel was aligned. Unfortunately, it doesn't check that the current port it is dealing with belongs to the comedi subdevice the `insn_bits` handler is acting on. That's a bug. Redo the `for` loop to terminate after the final port belonging to the subdevice, changing the loop variable in the process to simplify things a bit. The `for` loop could now try and handle more than 5 ports if the subdevice has more than 40 channels, but the test `if (bitshift >= 32)` ensures it will break out early after 4 or 5 ports (depending on whether the first channel is aligned on a port boundary). (`bitshift` will be between -7 and 7 inclusive on the first iteration, increasing by 8 for each subsequent operation.) Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit a1cccf25241ba0f2f373f6c94bf8ff9a747ae305 Author: Darrick J. Wong Date: Mon Sep 30 13:45:09 2013 -0700 mm/bounce.c: fix a regression where MS_SNAP_STABLE (stable pages snapshotting) was ignored commit 83b2944fd2532b92db099cb3ada12df32a05b368 upstream. The "force" parameter in __blk_queue_bounce was being ignored, which means that stable page snapshots are not always happening (on ext3). This of course leads to DIF disks reporting checksum errors, so fix this regression. The regression was introduced in commit 6bc454d15004 ("bounce: Refactor __blk_queue_bounce to not use bi_io_vec") Reported-by: Mel Gorman Signed-off-by: Darrick J. Wong Cc: Kent Overstreet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4dc59be5037f059421e302890165d5ccf6a386ac Author: David Miller Date: Wed Oct 2 14:25:09 2013 -0400 mm: Fix generic hugetlb pte check return type. [ Upstream commit 26794942461f438a6bc725ec7294b08a6bd782c4 ] The include/asm-generic/hugetlb.h stubs that just vector huge_pte_*() calls to the pte_*() implementations won't work in certain situations. x86 and sparc, for example, return "unsigned long" from the bit checks, and just go "return pte_val(pte) & PTE_BIT_FOO;" But since huge_pte_*() returns 'int', if any high bits on 64-bit are relevant, they get chopped off. The net effect is that we can loop forever trying to COW a huge page, because the huge_pte_write() check signals false all the time. Reported-by: Gurudas Pai Tested-by: Gurudas Pai Signed-off-by: David S. Miller Acked-by: David Rientjes Signed-off-by: Greg Kroah-Hartman commit 04e7d3c0bcd0905d6977b926fd378280c0645e09 Author: Kirill Tkhai Date: Fri Jul 26 01:17:15 2013 +0400 sparc32: Fix exit flag passed from traced sys_sigreturn [ Upstream commit 7a3b0f89e3fea680f93932691ca41a68eee7ab5e ] Pass 1 in %o1 to indicate that syscall_trace accounts exit. Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4026b686478d8a3de4a10fd870a17ed53a7a2fc6 Author: Kirill Tkhai Date: Fri Jul 26 17:21:12 2013 +0400 sparc64: Fix not SRA'ed %o5 in 32-bit traced syscall [ Upstream commit ab2abda6377723e0d5fbbfe5f5aa16a5523344d1 ] (From v1 to v2: changed comment) On the way linux_sparc_syscall32->linux_syscall_trace32->goto 2f, register %o5 doesn't clear its second 32-bit. Fix that. Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ad779b05b451bf64ca159290339fd770539b298d Author: David S. Miller Date: Thu Aug 22 16:38:46 2013 -0700 sparc64: Fix off by one in trampoline TLB mapping installation loop. [ Upstream commit 63d499662aeec1864ec36d042aca8184ea6a938e ] Reported-by: Kirill Tkhai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5c19adb25bc8d618619c24c4500bbbbc06bdba0b Author: Kees Cook Date: Tue Oct 1 22:13:34 2013 -0700 sparc: fix ldom_reboot buffer overflow harder [ Upstream commit 20928bd3f08afb036c096d9559d581926b895918 ] The length argument to strlcpy was still wrong. It could overflow the end of full_boot_str by 5 bytes. Instead of strcat and strlcpy, just use snprint. Reported-by: Brad Spengler Signed-off-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 34b6bdb2a889231e450774b5227a80c2f5051bc0 Author: David S. Miller Date: Fri Sep 27 13:46:04 2013 -0700 sparc64: Fix buggy strlcpy() conversion in ldom_reboot(). [ Upstream commit 2bd161a605f1f84a5fc8a4fe8410113a94f79355 ] Commit 117a0c5fc9c2d06045bd217385b2b39ea426b5a6 ("sparc: kernel: using strlcpy() instead of strcpy()") added a bug to ldom_reboot in arch/sparc/kernel/ds.c - strcpy(full_boot_str + strlen("boot "), boot_command); + strlcpy(full_boot_str + strlen("boot "), boot_command, + sizeof(full_boot_str + strlen("boot "))); That last sizeof() expression evaluates to sizeof(size_t) which is not what was intended. Also even the corrected: sizeof(full_boot_str) + strlen("boot ") is not right as the destination buffer length is just plain "sizeof(full_boot_str)" and that's what the final argument should be. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 32f0ba8e21166ec3ac11d692852d6d3e768942a4 Author: Kirill Tkhai Date: Mon Aug 12 16:02:24 2013 +0400 sparc64: Remove RWSEM export leftovers [ Upstream commit 61d9b9355b0d427bd1e732bd54628ff9103e496f ] The functions __down_read __down_read_trylock __down_write __down_write_trylock __up_read __up_write __downgrade_write are implemented inline, so remove corresponding EXPORT_SYMBOLs (They lead to compile errors on RT kernel). Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 84c041cc9b2eb6305732e32f283d9fac2b0e8b6a Author: Kirill Tkhai Date: Fri Aug 2 19:23:18 2013 +0400 sparc64: Fix ITLB handler of null page [ Upstream commit 1c2696cdaad84580545a2e9c0879ff597880b1a9 ] 1)Use kvmap_itlb_longpath instead of kvmap_dtlb_longpath. 2)Handle page #0 only, don't handle page #1: bleu -> blu (KERNBASE is 0x400000, so #1 does not exist too. But everything is possible in the future. Fix to not to have problems later.) 3)Remove unused kvmap_itlb_nonlinear. Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74e8a9efa9f08394444ef6ea7a4349c35dd3e811 Author: David S. Miller Date: Thu Aug 1 18:08:34 2013 -0700 esp_scsi: Fix tag state corruption when autosensing. [ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ] Meelis Roos reports a crash in esp_free_lun_tag() in the presense of a disk which has died. The issue is that when we issue an autosense command, we do so by hijacking the original command that caused the check-condition. When we do so we clear out the ent->tag[] array when we issue it via find_and_prep_issuable_command(). This is so that the autosense command is forced to be issued non-tagged. That is problematic, because it is the value of ent->tag[] which determines whether we issued the original scsi command as tagged vs. non-tagged (see esp_alloc_lun_tag()). And that, in turn, is what trips up the sanity checks in esp_free_lun_tag(). That function needs the original ->tag[] values in order to free up the tag slot properly. Fix this by remembering the original command's tag values, and having esp_alloc_lun_tag() and esp_free_lun_tag() use them. Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d8974c7fe717ee8fb0706e35cc92e0bcdf660ec5 Author: Vyacheslav Dubeyko Date: Mon Sep 30 13:45:12 2013 -0700 nilfs2: fix issue with race condition of competition between segments for dirty blocks commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream. Many NILFS2 users were reported about strange file system corruption (for example): NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768 NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540) But such error messages are consequence of file system's issue that takes place more earlier. Fortunately, Jerome Poulin and Anton Eliasson were reported about another issue not so recently. These reports describe the issue with segctor thread's crash: BUG: unable to handle kernel paging request at 0000000000004c83 IP: nilfs_end_page_io+0x12/0xd0 [nilfs2] Call Trace: nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2] nilfs_segctor_construct+0x17b/0x290 [nilfs2] nilfs_segctor_thread+0x122/0x3b0 [nilfs2] kthread+0xc0/0xd0 ret_from_fork+0x7c/0xb0 These two issues have one reason. This reason can raise third issue too. Third issue results in hanging of segctor thread with eating of 100% CPU. REPRODUCING PATH: One of the possible way or the issue reproducing was described by Jermoe me Poulin : 1. init S to get to single user mode. 2. sysrq+E to make sure only my shell is running 3. start network-manager to get my wifi connection up 4. login as root and launch "screen" 5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies. 6. lscp | xz -9e > lscp.txt.xz 7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs 8. start a screen to dump /proc/kmsg to text file since rsyslog is killed 9. start a screen and launch strace -f -o find-cat.log -t find /mnt/nilfs -type f -exec cat {} > /dev/null \; 10. start a screen and launch strace -f -o apt-get.log -t apt-get update 11. launch the last command again as it did not crash the first time 12. apt-get crashes 13. ps aux > ps-aux-crashed.log 13. sysrq+W 14. sysrq+E wait for everything to terminate 15. sysrq+SUSB Simplified way of the issue reproducing is starting kernel compilation task and "apt-get update" in parallel. REPRODUCIBILITY: The issue is reproduced not stable [60% - 80%]. It is very important to have proper environment for the issue reproducing. The critical conditions for successful reproducing: (1) It should have big modified file by mmap() way. (2) This file should have the count of dirty blocks are greater that several segments in size (for example, two or three) from time to time during processing. (3) It should be intensive background activity of files modification in another thread. INVESTIGATION: First of all, it is possible to see that the reason of crash is not valid page address: NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82 NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783 Moreover, value of b_page (0x1a82) is 6786. This value looks like segment number. And b_blocknr with b_size values look like block numbers. So, buffer_head's pointer points on not proper address value. Detailed investigation of the issue is discovered such picture: [-----------------------------SEGMENT 6783-------------------------------] NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783 [-----------------------------SEGMENT 6784-------------------------------] NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8 NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784 NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50 NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0 [----------] ditto NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15 [-----------------------------SEGMENT 6785-------------------------------] NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88 NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785 NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8 NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0 [----------] ditto NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12 NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783 NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784 NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785 NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82 BUG: unable to handle kernel paging request at 0000000000001a82 IP: [] nilfs_end_page_io+0x12/0xd0 [nilfs2] Usually, for every segment we collect dirty files in list. Then, dirty blocks are gathered for every dirty file, prepared for write and submitted by means of nilfs_segbuf_submit_bh() call. Finally, it takes place complete write phase after calling nilfs_end_bio_write() on the block layer. Buffers/pages are marked as not dirty on final phase and processed files removed from the list of dirty files. It is possible to see that we had three prepare_write and submit_bio phases before segbuf_wait and complete_write phase. Moreover, segments compete between each other for dirty blocks because on every iteration of segments processing dirty buffer_heads are added in several lists of payload_buffers: [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50 [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8 The next pointer is the same but prev pointer has changed. It means that buffer_head has next pointer from one list but prev pointer from another. Such modification can be made several times. And, finally, it can be resulted in various issues: (1) segctor hanging, (2) segctor crashing, (3) file system metadata corruption. FIX: This patch adds: (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write() for every proccessed dirty block; (2) checking of BH_Async_Write flag in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_dirty_node_buffers(); (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(), nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page(). Reported-by: Jerome Poulin Reported-by: Anton Eliasson Cc: Paul Fertser Cc: ARAI Shun-ichi Cc: Piotr Szymaniak Cc: Juan Barry Manuel Canham Cc: Zahid Chowdhury Cc: Elmer Zhang Cc: Kenneth Langga Signed-off-by: Vyacheslav Dubeyko Acked-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 230352711ef9d819bff5ccc18d407bfd5f51ef81 Author: Johan Hedberg Date: Fri Sep 13 08:58:18 2013 +0300 Bluetooth: Fix rfkill functionality during the HCI setup stage commit bf5430360ebe4b2d0c51d91f782e649107b502eb upstream. We need to let the setup stage complete cleanly even when the HCI device is rfkilled. Otherwise the HCI device will stay in an undefined state and never get notified to user space through mgmt (even when it gets unblocked through rfkill). This patch makes sure that hci_dev_open() can be called in the HCI_SETUP stage, that blocking the device doesn't abort the setup stage, and that the device gets proper powered down as soon as the setup stage completes in case it was blocked meanwhile. The bug that this patch fixed can be very easily reproduced using e.g. the rfkill command line too. By running "rfkill block all" before inserting a Bluetooth dongle the resulting HCI device goes into a state where it is never announced over mgmt, not even when "rfkill unblock all" is run. Signed-off-by: Johan Hedberg Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit ddc650c1b220e15a831ebc1624504a590ee0e8d9 Author: Johan Hedberg Date: Fri Sep 13 08:58:17 2013 +0300 Bluetooth: Introduce a new HCI_RFKILLED flag commit 5e130367d43ff22836bbae380d197d600fe8ddbb upstream. This makes it more convenient to check for rfkill (no need to check for dev->rfkill before calling rfkill_blocked()) and also avoids potential races if the RFKILL state needs to be checked from within the rfkill callback. Signed-off-by: Johan Hedberg Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit a7905fb906f2d43fbbdf2bd45c860ad0ee6c9465 Author: Raphael Kubo da Costa Date: Mon Sep 2 14:57:51 2013 +0300 Bluetooth: Add support for BCM20702A0 [0b05, 17cb] commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream. Yet another vendor specific ID for this chipset; this one for the ASUS USB-BT400 Bluetooth 4.0 adapter. T: Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17cb Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=000272C64400 C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Raphael Kubo da Costa Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 877ed5f4e67d3142df09048e037c62f3a3ae6ca9 Author: Peng Chen Date: Fri Aug 30 17:41:40 2013 +0800 Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012. commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream. usb device info: T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e005 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms Signed-off-by: Peng Chen Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit ad04e6cbe9e091059096748285655caf16da97d0 Author: Andre Guedes Date: Wed Jul 31 16:25:29 2013 -0300 Bluetooth: Fix encryption key size for peripheral role commit 89cbb4da0abee2f39d75f67f9fd57f7410c8b65c upstream. This patch fixes the connection encryption key size information when the host is playing the peripheral role. We should set conn->enc_key_ size in hci_le_ltk_request_evt, otherwise it is left uninitialized. Signed-off-by: Andre Guedes Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit a508ba2c07af1c6b1255e334fadfeddda2887f93 Author: Andre Guedes Date: Wed Jul 31 16:25:28 2013 -0300 Bluetooth: Fix security level for peripheral role commit f8776218e8546397be64ad2bc0ebf4748522d6e3 upstream. While playing the peripheral role, the host gets a LE Long Term Key Request Event from the controller when a connection is established with a bonded device. The host then informs the LTK which should be used for the connection. Once the link is encrypted, the host gets an Encryption Change Event. Therefore we should set conn->pending_sec_level instead of conn-> sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is properly updated in hci_encrypt_change_evt. Moreover, since we have a LTK associated to the device, we have at least BT_SECURITY_MEDIUM security level. Signed-off-by: Andre Guedes Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 37afef393d94a49bea7ee44d255b05a922d7b791 Author: Arend van Spriel Date: Wed Sep 25 12:11:01 2013 +0200 brcmfmac: obtain platform data upon module initialization commit db4efbbeb457b6f9f4d8c4b090d1170d12f026e1 upstream. The driver uses platform_driver_probe() to obtain platform data if any. However, that function is placed in the .init section so it must be called upon driver module initialization. The problem was reported by Fenguang Wu resulting in a kernel oops because the .init section was already freed. [ 48.966342] Switched to clocksource tsc [ 48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 48.970851] BUG: unable to handle kernel paging request at ffffffff82196446 [ 48.970957] IP: [] classes_init+0x26/0x26 [ 48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163 [ 48.970957] Oops: 0011 [#1] [ 48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23 [ 48.970957] Workqueue: events brcmf_driver_init [ 48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000 [ 48.970957] RIP: 0010:[] [] classes_init+0x26/0x26 [ 48.970957] RSP: 0000:ffff8800001d5d40 EFLAGS: 00000286 [ 48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000 [ 48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0 [ 48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002 [ 48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0 [ 48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300 [ 48.970957] FS: 0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000 [ 48.970957] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0 [ 48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 [ 48.970957] Stack: [ 48.970957] ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9 [ 48.970957] ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8 [ 48.970957] 0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000 [ 48.970957] Call Trace: [ 48.970957] [] ? brcmf_sdio_init+0x18/0x70 [ 48.970957] [] brcmf_driver_init+0x9/0x10 [ 48.970957] [] process_one_work+0x1d5/0x480 [ 48.970957] [] ? process_one_work+0x178/0x480 [ 48.970957] [] worker_thread+0x118/0x3a0 [ 48.970957] [] ? process_one_work+0x480/0x480 [ 48.970957] [] kthread+0xe7/0xf0 [ 48.970957] [] ? finish_task_switch.constprop.57+0x37/0xd0 [ 48.970957] [] ? __kthread_parkme+0x80/0x80 [ 48.970957] [] ret_from_fork+0x7a/0xb0 [ 48.970957] [] ? __kthread_parkme+0x80/0x80 [ 48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 48.970957] RIP [] classes_init+0x26/0x26 [ 48.970957] RSP [ 48.970957] CR2: ffffffff82196446 [ 48.970957] ---[ end trace 62980817cd525f14 ]--- Reported-by: Fengguang Wu Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Tested-by: Fengguang Wu Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 9abd30b435085cf2d897a77d657a4b6b8a56fd2c Author: Maxim Patlasov Date: Fri Sep 13 19:20:16 2013 +0400 fuse: fix fallocate vs. ftruncate race commit 0ab08f576b9e6a6b689fc6b4e632079b978e619b upstream. A former patch introducing FUSE_I_SIZE_UNSTABLE flag provided detailed description of races between ftruncate and anyone who can extend i_size: > 1. As in the previous scenario fuse_dentry_revalidate() discovered that i_size > changed (due to our own fuse_do_setattr()) and is going to call > truncate_pagecache() for some 'new_size' it believes valid right now. But by > the time that particular truncate_pagecache() is called ... > 2. fuse_do_setattr() returns (either having called truncate_pagecache() or > not -- it doesn't matter). > 3. The file is extended either by write(2) or ftruncate(2) or fallocate(2). > 4. mmap-ed write makes a page in the extended region dirty. This patch adds necessary bits to fuse_file_fallocate() to protect from that race. Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit eb12ca30f11b89eab811b23562e976c1c954c7f3 Author: Maxim Patlasov Date: Fri Sep 13 19:19:54 2013 +0400 fuse: wait for writeback in fuse_file_fallocate() commit bde52788bdb755b9e4b75db6c434f30e32a0ca0b upstream. The patch fixes a race between mmap-ed write and fallocate(PUNCH_HOLE): 1) An user makes a page dirty via mmap-ed write. 2) The user performs fallocate(2) with mode == PUNCH_HOLE|KEEP_SIZE and covering the page. 3) Before truncate_pagecache_range call from fuse_file_fallocate, the page goes to write-back. The page is fully processed by fuse_writepage (including end_page_writeback on the page), but fuse_flush_writepages did nothing because fi->writectr < 0. 4) truncate_pagecache_range is called and fuse_file_fallocate is finishing by calling fuse_release_nowrite. The latter triggers processing queued write-back request which will write stale data to the hole soon. Changed in v2 (thanks to Brian for suggestion): - Do not truncate page cache until FUSE_FALLOCATE succeeded. Otherwise, we can end up in returning -ENOTSUPP while user data is already punched from page cache. Use filemap_write_and_wait_range() instead. Changed in v3 (thanks to Miklos for suggestion): - fuse_wait_on_writeback() is prone to livelocks; use fuse_set_nowrite() instead. So far as we need a dirty-page barrier only, fuse_sync_writes() should be enough. - rebased to for-linus branch of fuse.git Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 17cb5c2fef8f1b1b2f3a4ac10f0801c9ad258cb6 Author: Paul E. McKenney Date: Tue Oct 1 17:11:35 2013 +1000 powerpc: Restore registers on error exit from csum_partial_copy_generic() commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream. The csum_partial_copy_generic() function saves the PowerPC non-volatile r14, r15, and r16 registers for the main checksum-and-copy loop. Unfortunately, it fails to restore them upon error exit from this loop, which results in silent corruption of these registers in the presumably rare event of an access exception within that loop. This commit therefore restores these register on error exit from the loop. Signed-off-by: Paul E. McKenney Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 4d358e9e19f001d2d7b33c2c8daa7b83b85ae1fc Author: Madhavan Srinivasan Date: Wed Oct 2 00:34:10 2013 +0530 powerpc/sysfs: Disable writing to PURR in guest mode commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream. arch/powerpc/kernel/sysfs.c exports PURR with write permission. This may be valid for kernel in phyp mode. But writing to the file in guest mode causes crash due to a priviledge violation Signed-off-by: Madhavan Srinivasan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 65ddee385ba4ba923eeb64182963815dc24f7bc1 Author: Paul E. McKenney Date: Tue Oct 1 16:54:05 2013 +1000 powerpc: Fix parameter clobber in csum_partial_copy_generic() commit d9813c3681a36774b254c0cdc9cce53c9e22c756 upstream. The csum_partial_copy_generic() uses register r7 to adjust the remaining bytes to process. Unfortunately, r7 also holds a parameter, namely the address of the flag to set in case of access exceptions while reading the source buffer. Lacking a quantum implementation of PowerPC, this commit instead uses register r9 to do the adjusting, leaving r7's pointer uncorrupted. Signed-off-by: Paul E. McKenney Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 470d4d6fe7349299ed565948e539260c4d0d041c Author: Prarit Bhargava Date: Mon Sep 23 09:33:36 2013 -0400 powerpc/vio: Fix modalias_show return values commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 upstream. modalias_show() should return an empty string on error, not -ENODEV. This causes the following false and annoying error: > find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null cat: /sys/devices/vio/4000/modalias: No such device cat: /sys/devices/vio/4001/modalias: No such device cat: /sys/devices/vio/4002/modalias: No such device cat: /sys/devices/vio/4004/modalias: No such device cat: /sys/devices/vio/modalias: No such device Signed-off-by: Prarit Bhargava Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 72daf965bb8fe1447069db3ea511047f20eca947 Author: Michael Neuling Date: Thu Sep 26 13:29:09 2013 +1000 powerpc/tm: Switch out userspace PPR and DSCR sooner commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983 upstream. When we do a treclaim or trecheckpoint we end up running with userspace PPR and DSCR values. Currently we don't do anything special to avoid running with user values which could cause a severe performance degradation. This patch moves the PPR and DSCR save and restore around treclaim and trecheckpoint so that we run with user values for a much shorter period. More care is taken with the PPR as it's impact is greater than the DSCR. This is similar to user exceptions, where we run HTM_MEDIUM early to ensure that we don't run with a userspace PPR values in the kernel. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 09bee3bc290da5f7f39b62f65f1a3deeaa3834ac Author: Michael Ellerman Date: Wed Oct 2 18:04:06 2013 +1000 powerpc/perf: Fix handling of FAB events commit a53b27b3abeef406de92a2bb0ceb6fb4c3fb8fc4 upstream. Commit 4df4899 "Add power8 EBB support" included a bug in the handling of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields. These values are pulled out of the event code using EVENT_THR_CTL_SHIFT, however we were then or'ing that value directly into MMCR1. This meant we were failing to set the FAB fields correctly, and also potentially corrupting the value for PMC4SEL. Leading to no counts for the FAB events and incorrect counts for PMC4. The fix is simply to shift left the FAB value correctly before or'ing it with MMCR1. Reported-by: Sooraj Ravindran Nair Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit e98d86aaa251cbd7c9745a3743ec4fa0c7c54c25 Author: Nishanth Aravamudan Date: Tue Oct 1 14:04:53 2013 -0700 powerpc/iommu: Use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table() commit 1cf389df090194a0976dc867b7fffe99d9d490cb upstream. Under heavy (DLPAR?) stress, we tripped this panic() in arch/powerpc/kernel/iommu.c::iommu_init_table(): page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz)); if (!page) panic("iommu_init_table: Can't allocate %ld bytes\n", sz); Before the panic() we got a page allocation failure for an order-2 allocation. There appears to be memory free, but perhaps not in the ATOMIC context. I looked through all the call-sites of iommu_init_table() and didn't see any obvious reason to need an ATOMIC allocation. Most call-sites in fact have an explicit GFP_KERNEL allocation shortly before the call to iommu_init_table(), indicating we are not in an atomic context. There is some indirection for some paths, but I didn't see any locks indicating that GFP_KERNEL is inappropriate. With this change under the same conditions, we have not been able to reproduce the panic. Signed-off-by: Nishanth Aravamudan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 7a7e86e4ef76e20e0e945c8216bbb0afa695d8ab Author: Dan Carpenter Date: Fri Sep 13 10:53:36 2013 +0300 ASoC: ab8500-codec: info leak in anc_status_control_put() commit d63733aed90b432e5cc489ddfa28e342f91b4652 upstream. If the user passes an invalid value it leads to an info leak when we print the error message or it could oops. This is called with user supplied data from snd_ctl_elem_write(). Signed-off-by: Dan Carpenter Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7fe5daa3a267dc44677e471c3de88b8653aae541 Author: Dan Carpenter Date: Fri Sep 13 10:52:49 2013 +0300 ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st() commit d967967e8d1116fb38bad25e58714b5dddd03cca upstream. This is called from snd_ctl_elem_write() with user supplied data so we need to add some bounds checking. Signed-off-by: Dan Carpenter Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9cea6e1ab0be55708d4aacf62dd69f99c700b9ab Author: Dan Carpenter Date: Fri Sep 13 10:52:14 2013 +0300 ASoC: max98095: a couple array underflows commit f8d7b13e14357ed19d2ca2799539600418dc3939 upstream. The ->put() function are called from snd_ctl_elem_write() with user supplied data. The limit checks here could underflow leading to a crash. Signed-off-by: Dan Carpenter Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 517ff99417cf9a27a6c4f34f99977505d9928785 Author: Javier Martinez Canillas Date: Wed Sep 25 02:36:54 2013 +0200 gpio/omap: auto-setup a GPIO when used as an IRQ commit fac7fa162a19100298d5d91359960037dc5bfca9 upstream. The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another driver won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. This fixes smsc911x ethernet support for tobi and igep OMAP3 boards and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line. Acked-by: Stephen Warren Tested-by: George Cherian Tested-by: Aaro Koskinen Tested-by: Lars Poeschel Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Acked-by: Santosh Shilimkar Acked-by: Tony Lindgren Signed-off-by: Javier Martinez Canillas Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 9dbd65f3bc7a1d75d474528360cfcb2f8816f5b7 Author: Javier Martinez Canillas Date: Wed Sep 25 02:36:52 2013 +0200 gpio/omap: maintain GPIO and IRQ usage separately commit fa365e4d729065b5e85165df3dc9699ed47489cc upstream. The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Acked-by: Stephen Warren Tested-by: George Cherian Tested-by: Aaro Koskinen Tested-by: Lars Poeschel Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Acked-by: Santosh Shilimkar Acked-by: Tony Lindgren Signed-off-by: Javier Martinez Canillas Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit cc748eed10e7e91c4fbc3a4503537f5748342b16 Author: Dan Aloni Date: Mon Sep 30 13:45:02 2013 -0700 fs/binfmt_elf.c: prevent a coredump with a large vm_map_count from Oopsing commit 72023656961b8c81a168a7a6762d589339d0d7ec upstream. A high setting of max_map_count, and a process core-dumping with a large enough vm_map_count could result in an NT_FILE note not being written, and the kernel crashing immediately later because it has assumed otherwise. Reproduction of the oops-causing bug described here: https://lkml.org/lkml/2013/8/30/50 Rge ussue originated in commit 2aa362c49c31 ("coredump: extend core dump note section to contain file names of mapped file") from Oct 4, 2012. This patch make that section optional in that case. fill_files_note() should signify the error, and also let the info struct in elf_core_dump() be zero-initialized so that we can check for the optionally written note. [akpm@linux-foundation.org: avoid abusing E2BIG, remove a couple of not-really-needed local variables] [akpm@linux-foundation.org: fix sparse warning] Signed-off-by: Dan Aloni Cc: Al Viro Cc: Denys Vlasenko Reported-by: Martin MOKREJS Tested-by: Martin MOKREJS Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fd728b3e6bd0153c78425052da773c95f3fcf332 Author: Gabor Juhos Date: Wed Sep 25 15:32:35 2013 +0200 avr32: fix clockevents kernel warning commit 1b0135b5e20c56b2edae29e92b91c0b12c983432 upstream. Since commit 01426478df3a8791ff5c8b6b82d409e699cfaf38 (avr32: Use generic idle loop) the kernel throws the following warning on avr32: WARNING: at 900322e4 [verbose debug info unavailable] Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-rc2 #117 task: 901c3ecc ti: 901c0000 task.ti: 901c0000 PC is at cpu_idle_poll_ctrl+0x1c/0x38 LR is at comparator_mode+0x3e/0x40 pc : [<900322e4>] lr : [<90014882>] Not tainted sp : 901c1f74 r12: 00000000 r11: 901c74a0 r10: 901d2510 r9 : 00000001 r8 : 901db4de r7 : 901c74a0 r6 : 00000001 r5 : 00410020 r4 : 901db574 r3 : 00410024 r2 : 90206fe0 r1 : 00000000 r0 : 007f0000 Flags: qvnzc Mode bits: hjmde....G CPU Mode: Supervisor Call trace: [<90039ede>] clockevents_set_mode+0x16/0x2e [<90039f00>] clockevents_shutdown+0xa/0x1e [<9003a078>] clockevents_exchange_device+0x58/0x70 [<9003a78c>] tick_check_new_device+0x38/0x54 [<9003a1a2>] clockevents_register_device+0x32/0x90 [<900035c4>] time_init+0xa8/0x108 [<90000520>] start_kernel+0x128/0x23c When the 'avr32_comparator' clockevent device is registered, the clockevent core sets the mode of that clockevent device to CLOCK_EVT_MODE_SHUTDOWN. Due to this, the 'comparator_mode' function calls the 'cpu_idle_poll_ctrl' to disables idle poll. This results in the aforementioned warning because the polling is not enabled yet. Change the code to only disable idle poll if it is enabled by the same function to avoid the warning. Signed-off-by: Gabor Juhos Acked-by: Hans-Christian Egtvedt Signed-off-by: Greg Kroah-Hartman commit 506cdb8909a1a739c7585c680c6bd4b3d1247564 Author: Nicolas Dichtel Date: Tue Oct 1 18:05:00 2013 +0200 ip6tnl: allow to use rtnl ops on fb tunnel [ Upstream commit bb8140947a247b9aa15652cc24dc555ebb0b64b0 ] rtnl ops where introduced by c075b13098b3 ("ip6tnl: advertise tunnel param via rtnl"), but I forget to assign rtnl ops to fb tunnels. Now that it is done, we must remove the explicit call to unregister_netdevice_queue(), because the fallback tunnel is added to the queue in ip6_tnl_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this is valid since commit 0bd8762824e7 ("ip6tnl: add x-netns support")). Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 20300db1bd1b9f45477c7af15b358deb87742bd1 Author: Nicolas Dichtel Date: Tue Oct 1 18:04:59 2013 +0200 sit: allow to use rtnl ops on fb tunnel [ Upstream commit 205983c43700ac3a81e7625273a3fa83cd2759b5 ] rtnl ops where introduced by ba3e3f50a0e5 ("sit: advertise tunnel param via rtnl"), but I forget to assign rtnl ops to fb tunnels. Now that it is done, we must remove the explicit call to unregister_netdevice_queue(), because the fallback tunnel is added to the queue in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this is valid since commit 5e6700b3bf98 ("sit: add support of x-netns")). Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 23d6f8dd1cc9ca2a3aaed9c6bb24f80b39e071df Author: Steffen Klassert Date: Tue Oct 1 11:33:59 2013 +0200 ip_tunnel: Fix a memory corruption in ip_tunnel_xmit [ Upstream commit 3e08f4a72f689c6296d336c2aab4bddd60c93ae2 ] We might extend the used aera of a skb beyond the total headroom when we install the ipip header. Fix this by calling skb_cow_head() unconditionally. Bug was introduced with commit c544193214 ("GRE: Refactor GRE tunneling code.") Cc: Pravin Shelar Signed-off-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c7bd0696131d1cc596afea05d06c6fee5b7a51ca Author: Ricardo Ribalda Date: Tue Oct 1 08:17:10 2013 +0200 ll_temac: Reset dma descriptors indexes on ndo_open [ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ] The dma descriptors indexes are only initialized on the probe function. If a packet is on the buffer when temac_stop is called, the dma descriptors indexes can be left on a incorrect state where no other package can be sent. So an interface could be left in an usable state after ifdow/ifup. This patch makes sure that the descriptors indexes are in a proper status when the device is open. Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ef04c1db0aef35f8d006d18c79cacd11925078ec Author: Salam Noureddine Date: Sun Sep 29 13:41:34 2013 -0700 ipv6 mcast: use in6_dev_put in timer handlers instead of __in6_dev_put [ Upstream commit 9260d3e1013701aa814d10c8fc6a9f92bd17d643 ] It is possible for the timer handlers to run after the call to ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the inet6_dev being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by: Salam Noureddine Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fbf96d75f4a320c66e03a21b2a46d0985b6d096b Author: Salam Noureddine Date: Sun Sep 29 13:39:42 2013 -0700 ipv4 igmp: use in_dev_put in timer handlers instead of __in_dev_put [ Upstream commit e2401654dd0f5f3fb7a8d80dad9554d73d7ca394 ] It is possible for the timer handlers to run after the call to ip_mc_down so use in_dev_put instead of __in_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the in_device being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by: Salam Noureddine Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 102ce961c8d54d613eb49d6bc71ecec674505815 Author: Hannes Frederic Sowa Date: Sun Sep 29 05:40:50 2013 +0200 ipv6: gre: correct calculation of max_headroom [ Upstream commit 3da812d860755925da890e8c713f2d2e2d7b1bae ] gre_hlen already accounts for sizeof(struct ipv6_hdr) + gre header, so initialize max_headroom to zero. Otherwise the if (encap_limit >= 0) { max_headroom += 8; mtu -= 8; } increments an uninitialized variable before max_headroom was reset. Found with coverity: 728539 Cc: Dmitry Kozlov Signed-off-by: Hannes Frederic Sowa Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c9b391f6d166118c5543e9d1708e67977dbdbe1f Author: Neil Horman Date: Fri Sep 27 12:22:15 2013 -0400 bonding: Fix broken promiscuity reference counting issue [ Upstream commit 5a0068deb611109c5ba77358be533f763f395ee4 ] Recently grabbed this report: https://bugzilla.redhat.com/show_bug.cgi?id=1005567 Of an issue in which the bonding driver, with an attached vlan encountered the following errors when bond0 was taken down and back up: dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of device might be broken. The error occurs because, during __bond_release_one, if we release our last slave, we take on a random mac address and issue a NETDEV_CHANGEADDR notification. With an attached vlan, the vlan may see that the vlan and bond mac address were in sync, but no longer are. This triggers a call to dev_uc_add and dev_set_rx_mode, which enables IFF_PROMISC on the bond device. Then, when we complete __bond_release_one, we use the current state of the bond flags to determine if we should decrement the promiscuity of the releasing slave. But since the bond changed promiscuity state during the release operation, we incorrectly decrement the slave promisc count when it wasn't in promiscuous mode to begin with, causing the above error Fix is pretty simple, just cache the bonding flags at the start of the function and use those when determining the need to set promiscuity. This is also needed for the ALLMULTI flag Reported-by: Mark Wu CC: Jay Vosburgh CC: Andy Gospodarek CC: Mark Wu CC: "David S. Miller" Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f17c9815499705904d67157cb274a260d944e5f2 Author: Peter Korsgaard Date: Mon Sep 30 23:28:20 2013 +0200 dm9601: fix IFF_ALLMULTI handling [ Upstream commit bf0ea6380724beb64f27a722dfc4b0edabff816e ] Pass-all-multicast is controlled by bit 3 in RX control, not bit 2 (pass undersized frames). Reported-by: Joseph Chang Signed-off-by: Peter Korsgaard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bdf831a681dd237fcde669e07e5202daddfa0c65 Author: Eric Dumazet Date: Tue Sep 24 06:19:57 2013 -0700 net: net_secret should not depend on TCP [ Upstream commit 9a3bab6b05383f1e4c3716b3615500c51285959e ] A host might need net_secret[] and never open a single socket. Problem added in commit aebda156a570782 ("net: defer net_secret[] initialization") Based on prior patch from Hannes Frederic Sowa. Reported-by: Hannes Frederic Sowa Signed-off-by: Eric Dumazet Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ea2edb3b6cbe72d2f943e205c463f6cb8bafe56 Author: Catalin(ux) M. BOIE Date: Mon Sep 23 23:04:19 2013 +0300 IPv6 NAT: Do not drop DNATed 6to4/6rd packets [ Upstream commit 7df37ff33dc122f7bd0614d707939fe84322d264 ] When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing commit 218774dc ("ipv6: add anti-spoofing checks for 6to4 and 6rd") will drop them because the IPv6 address embedded does not match the IPv4 destination. This patch will allow them to pass by testing if we have an address that matches on 6to4/6rd interface. I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR. Also, log the dropped packets (with rate limit). Signed-off-by: Catalin(ux) M. BOIE Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7036a444e8a9eb1e41f4e157c8f19b8efbc2cb7 Author: Roger Luethi Date: Sat Sep 21 14:24:11 2013 +0200 via-rhine: fix VLAN priority field (PCP, IEEE 802.1p) [ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ] Outgoing packets sent by via-rhine have their VLAN PCP field off by one (when hardware acceleration is enabled). The TX descriptor expects only VID and PCP (without a CFI/DEI bit). Peter Boström noticed and reported the bug. Signed-off-by: Roger Luethi Cc: Peter Boström Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f5a30bc1d6b338ecba5b948798a48bc5b59ef30f Author: Hannes Frederic Sowa Date: Sat Sep 21 06:27:00 2013 +0200 ipv6: udp packets following an UFO enqueued packet need also be handled by UFO [ Upstream commit 2811ebac2521ceac84f2bdae402455baa6a7fb47 ] In the following scenario the socket is corked: If the first UDP packet is larger then the mtu we try to append it to the write queue via ip6_ufo_append_data. A following packet, which is smaller than the mtu would be appended to the already queued up gso-skb via plain ip6_append_data. This causes random memory corruptions. In ip6_ufo_append_data we also have to be careful to not queue up the same skb multiple times. So setup the gso frame only when no first skb is available. This also fixes a shortcoming where we add the current packet's length to cork->length but return early because of a packet > mtu with dontfrag set (instead of sutracting it again). Found with trinity. Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Reported-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 68a9e707892caf0fda14656963fd99c6a1c10e46 Author: Ansis Atteka Date: Wed Sep 18 15:29:53 2013 -0700 ip: generate unique IP identificator if local fragmentation is allowed [ Upstream commit 703133de331a7a7df47f31fb9de51dc6f68a9de8 ] If local fragmentation is allowed, then ip_select_ident() and ip_select_ident_more() need to generate unique IDs to ensure correct defragmentation on the peer. For example, if IPsec (tunnel mode) has to encrypt large skbs that have local_df bit set, then all IP fragments that belonged to different ESP datagrams would have used the same identificator. If one of these IP fragments would get lost or reordered, then peer could possibly stitch together wrong IP fragments that did not belong to the same datagram. This would lead to a packet loss or data corruption. Signed-off-by: Ansis Atteka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cd176b578d356844f68176a1e0b6346c1cc9e33d Author: Ansis Atteka Date: Wed Sep 18 15:29:52 2013 -0700 ip: use ip_hdr() in __ip_make_skb() to retrieve IP header [ Upstream commit 749154aa56b57652a282cbde57a57abc278d1205 ] skb->data already points to IP header, but for the sake of consistency we can also use ip_hdr() to retrieve it. Signed-off-by: Ansis Atteka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f25e4f35defd609b3e6ad2ae5e871bdbcc0af333 Author: Duan Jiong Date: Wed Sep 18 20:03:27 2013 +0800 net:dccp: do not report ICMP redirects to user space [ Upstream commit bd784a140712fd06674f2240eecfc4ccae421129 ] DCCP shouldn't be setting sk_err on redirects as it isn't an error condition. it should be doing exactly what tcp is doing and leaving the error handler without touching the socket. Signed-off-by: Duan Jiong Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e4e7ba12fab4eba6eb6fe2863a6e0e91cd77c7cc Author: Daniel Borkmann Date: Mon Sep 16 12:36:02 2013 +0200 net: sctp: rfc4443: do not report ICMP redirects to user space [ Upstream commit 3f96a532113131d5a65ac9e00fc83cfa31b0295f ] Adapt the same behaviour for SCTP as present in TCP for ICMP redirect messages. For IPv6, RFC4443, section 2.4. says: ... (e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following: ... (e.2) An ICMPv6 redirect message [IPv6-DISC]. ... Therefore, do not report an error to user space, just invoke dst's redirect callback and leave, same for IPv4 as done in TCP as well. The implication w/o having this patch could be that the reception of such packets would generate a poll notification and in worst case it could even tear down the whole connection. Therefore, stop updating sk_err on redirects. Reported-by: Duan Jiong Reported-by: Hannes Frederic Sowa Suggested-by: Vlad Yasevich Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fa42a01cb0b985d0d7321956dfdfee2e3e179899 Author: Ding Zhi Date: Mon Sep 16 11:31:15 2013 +0200 ip6_tunnels: raddr and laddr are inverted in nl msg [ Upstream commit 0d2ede929f61783aebfb9228e4d32a0546ee4d23 ] IFLA_IPTUN_LOCAL and IFLA_IPTUN_REMOTE were inverted. Introduced by c075b13098b3 (ip6tnl: advertise tunnel param via rtnl). Signed-off-by: Ding Zhi Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 960b8e5018a552f62cfbc0dfe94be7b6ba178f13 Author: Hong Zhiguo Date: Sat Sep 14 22:42:28 2013 +0800 bridge: fix NULL pointer deref of br_port_get_rcu [ Upstream commit 716ec052d2280d511e10e90ad54a86f5b5d4dcc2 ] The NULL deref happens when br_handle_frame is called between these 2 lines of del_nbp: dev->priv_flags &= ~IFF_BRIDGE_PORT; /* --> br_handle_frame is called at this time */ netdev_rx_handler_unregister(dev); In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced without check but br_port_get_rcu(dev) returns NULL if: !(dev->priv_flags & IFF_BRIDGE_PORT) Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary here since we're in rcu_read_lock and we have synchronize_net() in netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT and by the previous patch, make sure br_port_get_rcu is called in bridging code. Signed-off-by: Hong Zhiguo Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 97ddc3e1f9d6637c81aaa470fde5669ffb854d14 Author: Hong Zhiguo Date: Sat Sep 14 22:42:27 2013 +0800 bridge: use br_port_get_rtnl within rtnl lock [ Upstream commit 1fb1754a8c70d69ab480763c423e0a74369c4a67 ] current br_port_get_rcu is problematic in bridging path (NULL deref). Change these calls in netlink path first. Signed-off-by: Hong Zhiguo Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dc45b846e96d5a656ddd926334b6496e6916b446 Author: Herbert Xu Date: Thu Sep 12 17:12:05 2013 +1000 bridge: Clamp forward_delay when enabling STP [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ] At some point limits were added to forward_delay. However, the limits are only enforced when STP is enabled. This created a scenario where you could have a value outside the allowed range while STP is disabled, which then stuck around even after STP is enabled. This patch fixes this by clamping the value when we enable STP. I had to move the locking around a bit to ensure that there is no window where someone could insert a value outside the range while we're in the middle of enabling STP. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 10a559a0df3eaa0c3cfbf780f88caf7f85c47106 Author: Chris Healy Date: Wed Sep 11 21:37:47 2013 -0700 resubmit bridge: fix message_age_timer calculation [ Upstream commit 9a0620133ccce9dd35c00a96405c8d80938c2cc0 ] This changes the message_age_timer calculation to use the BPDU's max age as opposed to the local bridge's max age. This is in accordance with section 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification. With the current implementation, when running with very large bridge diameters, convergance will not always occur even if a root bridge is configured to have a longer max age. Tested successfully on bridge diameters of ~200. Signed-off-by: Chris Healy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0ff773f59ff375c42af2238457bda98ed4ddcd25 Author: David Vrabel Date: Wed Sep 11 14:52:48 2013 +0100 xen-netback: count number required slots for an skb more carefully [ Upstream commit 6e43fc04a6bc357d260583b8440882f28069207f ] When a VM is providing an iSCSI target and the LUN is used by the backend domain, the generated skbs for direct I/O writes to the disk have large, multi-page skb->data but no frags. With some lengths and starting offsets, xen_netbk_count_skb_slots() would be one short because the simple calculation of DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the decisions made by start_new_rx_buffer() which does not guarantee responses are fully packed. For example, a skb with length < 2 pages but which spans 3 pages would be counted as requiring 2 slots but would actually use 3 slots. skb->data: | 1111|222222222222|3333 | Fully packed, this would need 2 slots: |111122222222|22223333 | But because the 2nd page wholy fits into a slot it is not split across slots and goes into a slot of its own: |1111 |222222222222|3333 | Miscounting the number of slots means netback may push more responses than the number of available requests. This will cause the frontend to get very confused and report "Too many frags/slots". The frontend never recovers and will eventually BUG. Fix this by counting the number of required slots more carefully. In xen_netbk_count_skb_slots(), more closely follow the algorithm used by xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which is the dry-run equivalent of netbk_gop_frag_copy(). Signed-off-by: David Vrabel Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 872b11be53a4594c39262433c4176176fcb12bd2 Author: Daniel Borkmann Date: Wed Sep 11 16:58:36 2013 +0200 net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit [ Upstream commit 95ee62083cb6453e056562d91f597552021e6ae7 ] Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport does not seem to have the desired effect: SCTP + IPv4: 22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116) 192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72 22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340) 192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1): SCTP + IPv6: 22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364) fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp 1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10] Moreover, Alan says: This problem was seen with both Racoon and Racoon2. Other people have seen this with OpenSwan. When IPsec is configured to encrypt all upper layer protocols the SCTP connection does not initialize. After using Wireshark to follow packets, this is because the SCTP packet leaves Box A unencrypted and Box B believes all upper layer protocols are to be encrypted so it drops this packet, causing the SCTP connection to fail to initialize. When IPsec is configured to encrypt just SCTP, the SCTP packets are observed unencrypted. In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext" string on the other end, results in cleartext on the wire where SCTP eventually does not report any errors, thus in the latter case that Alan reports, the non-paranoid user might think he's communicating over an encrypted transport on SCTP although he's not (tcpdump ... -X): ... 0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000 ]p.......}.l.... 0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000 ....plaintext... Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the receiver side. Initial follow-up analysis from Alan's bug report was done by Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this. SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit(). This has the implication that it probably never really got updated along with changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers. SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since a call to inet6_csk_xmit() would solve this problem, but result in unecessary route lookups, let us just use the cached flowi6 instead that we got through sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(), we do the route lookup / flow caching in sctp_transport_route(), hold it in tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst() instead to get the correct source routed dst entry, which we assign to the skb. Also source address routing example from 625034113 ("sctp: fix sctp to work with ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095 it is actually 'recommended' to not use that anyway due to traffic amplification [1]. So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if we overwrite the flow destination here, the lower IPv6 layer will be unable to put the correct destination address into IP header, as routing header is added in ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside, result of this patch is that we do not have any XfrmInTmplMismatch increase plus on the wire with this patch it now looks like: SCTP + IPv6: 08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba: AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72 08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a: AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296 This fixes Kernel Bugzilla 24412. This security issue seems to be present since 2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have its fun with that. lksctp-tools IPv6 regression test suite passes as well with this patch. [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf Reported-by: Alan Chester Reported-by: Alexey Dobriyan Signed-off-by: Daniel Borkmann Cc: Steffen Klassert Cc: Hannes Frederic Sowa Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a81a02460bdf054ca0c60c5aed29941f7134092d Author: Jason Wang Date: Wed Sep 11 18:09:48 2013 +0800 tuntap: correctly handle error in tun_set_iff() [ Upstream commit 662ca437e714caaab855b12415d6ffd815985bc0 ] Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue support) only call free_netdev() on error in tun_set_iff(). This causes several issues: - memory of tun security were leaked - use after free since the flow gc timer was not deleted and the tfile were not detached This patch solves the above issues. Reported-by: Wannes Rombouts Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e66bdd7106911886aebf118e1c1aebb5a26d0752 Author: Nikolay Aleksandrov Date: Thu Sep 19 15:02:35 2013 +0200 netpoll: fix NULL pointer dereference in netpoll_cleanup [ Upstream commit d0fe8c888b1fd1a2f84b9962cabcb98a70988aec ] I've been hitting a NULL ptr deref while using netconsole because the np->dev check and the pointer manipulation in netpoll_cleanup are done without rtnl and the following sequence happens when having a netconsole over a vlan and we remove the vlan while disabling the netconsole: CPU 1 CPU2 removes vlan and calls the notifier enters store_enabled(), calls netdev_cleanup which checks np->dev and then waits for rtnl executes the netconsole netdev release notifier making np->dev == NULL and releases rtnl continues to dereference a member of np->dev which at this point is == NULL Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0885f6b8bb0403a56546d302e749c1defe47339d Author: Sonic Zhang Date: Wed Sep 11 11:31:53 2013 +0800 netpoll: Should handle ETH_P_ARP other than ETH_P_IP in netpoll_neigh_reply [ Upstream commit b0dd663b60944a3ce86430fa35549fb37968bda0 ] The received ARP request type in the Ethernet packet head is ETH_P_ARP other than ETH_P_IP. [ Bug introduced by commit b7394d2429c198b1da3d46ac39192e891029ec0f ("netpoll: prepare for ipv6") ] Signed-off-by: Sonic Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9fdd73559c439ba7216bce159a78e44328c3a573 Author: Francois Romieu Date: Sun Sep 8 01:15:35 2013 +0200 r8169: enforce RX_MULTI_EN for the 8168f. [ Upstream commit 3ced8c955e74d319f3e3997f7169c79d524dfd06 ] Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig hack for the 8168evl.") regarding AMD IOMMU errors. RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the same. Tested-by: David R Tested-by: Frédéric Leroy Cc: Hayes Wang Signed-off-by: Francois Romieu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5f584fec559756fd82796c2f7db58b10a3e479b1 Author: Vimalkumar Date: Tue Sep 10 17:36:37 2013 -0700 net_sched: htb: fix a typo in htb_change_class() [ Upstream commit f3ad857e3da1abaea780dc892b592cd86c541c52 ] Fix a typo added in commit 56b765b79 ("htb: improved accuracy at high rates") cbuffer should not be a copy of buffer. Signed-off-by: Vimalkumar Signed-off-by: Eric Dumazet Cc: Jesper Dangaard Brouer Cc: Jiri Pirko Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 98913d0758e27087bbd47db734ff96521b180389 Author: Eric Dumazet Date: Thu Sep 26 08:44:06 2013 -0700 net: flow_dissector: fix thoff for IPPROTO_AH [ Upstream commit b86783587b3d1d552326d955acee37eac48800f1 ] In commit 8ed781668dd49 ("flow_keys: include thoff into flow_keys for later usage"), we missed that existing code was using nhoff as a temporary variable that could not always contain transport header offset. This is not a problem for TCP/UDP because port offset (@poff) is 0 for these protocols. Signed-off-by: Eric Dumazet Cc: Daniel Borkmann Cc: Nikolay Aleksandrov Acked-by: Nikolay Aleksandrov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b991056a43fef79b2327b084f4296fba698b941b Author: Eric Dumazet Date: Sat Sep 7 12:02:57 2013 -0700 net: fix multiqueue selection [ Upstream commit 50d1784ee4683f073c0362ee360bfae7a3333d6c ] commit 416186fbf8c5b4e4465 ("net: Split core bits of netdev_pick_tx into __netdev_pick_tx") added a bug that disables caching of queue index in the socket. This is the source of packet reorders for TCP flows, and again this is happening more often when using FQ pacing. Old code was doing if (queue_index != old_index) sk_tx_queue_set(sk, queue_index); Alexander renamed the variables but forgot to change sk_tx_queue_set() 2nd parameter. if (queue_index != new_index) sk_tx_queue_set(sk, queue_index); This means we store -1 over and over in sk->sk_tx_queue_mapping Signed-off-by: Eric Dumazet Cc: Alexander Duyck Acked-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8ee62e8c9495a6d0f8d227bbe0f02e1b288bac30 Author: Daniel Borkmann Date: Sat Sep 7 20:51:21 2013 +0200 net: sctp: fix smatch warning in sctp_send_asconf_del_ip [ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ] This was originally reported in [1] and posted by Neil Horman [2], he said: Fix up a missed null pointer check in the asconf code. If we don't find a local address, but we pass in an address length of more than 1, we may dereference a NULL laddr pointer. Currently this can't happen, as the only users of the function pass in the value 1 as the addrcnt parameter, but its not hot path, and it doesn't hurt to check for NULL should that ever be the case. The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1 while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR so that we do *not* find a single address in the association's bind address list that is not in the packed array of addresses. If this happens when we have an established association with ASCONF-capable peers, then we could get a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1 and call later sctp_make_asconf_update_ip() with NULL laddr. BUT: this actually won't happen as sctp_bindx_rem() will catch such a case and return with an error earlier. As this is incredably unintuitive and error prone, add a check to catch at least future bugs here. As Neil says, its not hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the single-homed host"). [1] http://www.spinics.net/lists/linux-sctp/msg02132.html [2] http://www.spinics.net/lists/linux-sctp/msg02133.html Reported-by: Dan Carpenter Signed-off-by: Neil Horman Signed-off-by: Daniel Borkmann Cc: Michio Honda Acked-By: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8b1ada497191ab2be429c74817a8de63f9aa2bf6 Author: Daniel Borkmann Date: Sat Sep 7 16:44:59 2013 +0200 net: sctp: fix bug in sctp_poll for SOCK_SELECT_ERR_QUEUE [ Upstream commit a0fb05d1aef0f5df936f80b726d1b3bfd4275f95 ] If we do not add braces around ... mask |= POLLERR | sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0; ... then this condition always evaluates to true as POLLERR is defined as 8 and binary or'd with whatever result comes out of sock_flag(). Hence instead of (X | Y) ? A : B, transform it into X | (Y ? A : B). Unfortunatelty, commit 8facd5fb73 ("net: fix smatch warnings inside datagram_poll") forgot about SCTP. :-( Introduced by 7d4c04fc170 ("net: add option to enable error queue packets waking select"). Signed-off-by: Daniel Borkmann Cc: Jacob Keller Acked-by: Neil Horman Acked-by: Vlad Yasevich Acked-by: Jacob Keller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45d268c6b87c0c80fda9960a8b850ee0e82b71dc Author: Daniel Borkmann Date: Sat Sep 7 15:13:20 2013 +0200 net: fib: fib6_add: fix potential NULL pointer dereference [ Upstream commit ae7b4e1f213aa659aedf9c6ecad0bf5f0476e1e2 ] When the kernel is compiled with CONFIG_IPV6_SUBTREES, and we return with an error in fn = fib6_add_1(), then error codes are encoded into the return pointer e.g. ERR_PTR(-ENOENT). In such an error case, we write the error code into err and jump to out, hence enter the if(err) condition. Now, if CONFIG_IPV6_SUBTREES is enabled, we check for: if (pn != fn && pn->leaf == rt) ... if (pn != fn && !pn->leaf && !(pn->fn_flags & RTN_RTINFO)) ... Since pn is NULL and fn is f.e. ERR_PTR(-ENOENT), then pn != fn evaluates to true and causes a NULL-pointer dereference on further checks on pn. Fix it, by setting both NULL in error case, so that pn != fn already evaluates to false and no further dereference takes place. This was first correctly implemented in 4a287eba2 ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag"), but the bug got later on introduced by 188c517a0 ("ipv6: return errno pointers consistently for fib6_add_1()"). Signed-off-by: Daniel Borkmann Cc: Lin Ming Cc: Matti Vaittinen Cc: Hannes Frederic Sowa Acked-by: Hannes Frederic Sowa Acked-by: Matti Vaittinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 711b8c96842e7e93b01caad6403488498d5cecfa Author: Jiri Pirko Date: Fri Sep 6 16:02:25 2013 +0200 ipv6/exthdrs: accept tlv which includes only padding [ Upstream commit 8112b1fe071be01a28a774ed55909e6f4b29712d ] In rfc4942 and rfc2460 I cannot find anything which would implicate to drop packets which have only padding in tlv. Current behaviour breaks TAHI Test v6LC.1.2.6. Problem was intruduced in: 9b905fe6843 "ipv6/exthdrs: strict Pad1 and PadN check" Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a4ae4c6176a7c878018adf470a47c1fae9090978 Author: Dave Jones Date: Thu Sep 5 13:43:34 2013 -0400 tcp: Add missing braces to do_tcp_setsockopt [ Upstream commit e2e5c4c07caf810d7849658dca42f598b3938e21 ] Signed-off-by: Dave Jones Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a505becfe50ff2e1ba34e197f51eb18eb8e9dfbd Author: Dave Jones Date: Thu Sep 5 00:11:19 2013 -0400 caif: Add missing braces to multiline if in cfctrl_linkup_request [ Upstream commit 0c1db731bfcf3a9fd6c58132134f8b0f423552f0 ] The indentation here implies this was meant to be a multi-line if. Introduced several years back in commit c85c2951d4da1236e32f1858db418221e624aba5 ("caif: Handle dev_queue_xmit errors.") Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 88e2194c2aa9f29f80b2835295e298147c06f6e2 Author: Jiri Kosina Date: Mon Jul 22 17:11:44 2013 +0200 HID: fix unused rsize usage commit bc197eedef1ae082ec662c64c3f4aa302821fb7a upstream. 27ce4050 ("HID: fix data access in implement()") by mistake removed a setting of buffer size in hidp. Fix that by putting it back. Reported-by: kbuild test robot Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b2b6cadad699d44a8a5b2a60f3d960e00d6fb3b7 Author: Jiri Kosina Date: Wed Jul 10 19:56:27 2013 +0200 HID: fix data access in implement() commit 27ce405039bfe6d3f4143415c638f56a3df77dca upstream. implement() is setting bytes in LE data stream. In case the data is not aligned to 64bits, it reads past the allocated buffer. It doesn't really change any value there (it's properly bitmasked), but in case that this read past the boundary hits a page boundary, pagefault happens when accessing 64bits of 'x' in implement(), and kernel oopses. This happens much more often when numbered reports are in use, as the initial 8bit skip in the buffer makes the whole process work on values which are not aligned to 64bits. This problem dates back to attempts in 2005 and 2006 to make implement() and extract() as generic as possible, and even back then the problem was realized by Adam Kroperlin, but falsely assumed to be impossible to cause any harm: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html I have made several attempts at fixing it "on the spot" directly in implement(), but the results were horrible; the special casing for processing last 64bit chunk and switching to different math makes it unreadable mess. I therefore took a path to allocate a few bytes more which will never make it into final report, but are there as a cushion for all the 64bit math operations happening in implement() and extract(). All callers of hid_output_report() are converted at the same time to allocate the buffer by newly introduced hid_alloc_report_buf() helper. Bruno noticed that the whole raw_size test can be dropped as well, as hid_alloc_report_buf() makes sure that the buffer is always of a proper size. Reviewed-by: Benjamin Tissoires Acked-by: Gustavo Padovan Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 698508f44ad8d2f4289f8fae4488576f2902703a Author: Dan Carpenter Date: Tue Sep 24 15:27:45 2013 -0700 cciss: fix info leak in cciss_ioctl32_passthru() commit 58f09e00ae095e46ef9edfcf3a5fd9ccdfad065e upstream. The arg64 struct has a hole after ->buf_size which isn't cleared. Or if any of the calls to copy_from_user() fail then that would cause an information leak as well. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter Acked-by: Mike Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d862d211b03663ae22149cff65ad71f836fe6f7b Author: Dan Carpenter Date: Tue Sep 24 15:27:44 2013 -0700 cpqarray: fix info leak in ida_locked_ioctl() commit 627aad1c01da6f881e7f98d71fd928ca0c316b1a upstream. The pciinfo struct has a two byte hole after ->dev_fn so stack information could be leaked to the user. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter Acked-by: Mike Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9e65b308202a4e6536c5b453d6b37fd0467dd5d2 Author: Daniel Drake Date: Fri Jun 14 15:24:24 2013 -0400 mwifiex: fix memory corruption when unsetting multicast list commit 6390d88529835a8ad3563fe01a5da89fa52d6db2 upstream. When trying to unset a previously-set multicast list (i.e. the new list has 0 entries), mwifiex_set_multicast_list() was calling down to mwifiex_request_set_multicast_list() while leaving mcast_list.num_multicast_addr as an uninitialized value. We were arriving at mwifiex_cmd_mac_multicast_adr() which would then proceed to do an often huge memcpy of mcast_list.num_multicast_addr*ETH_ALEN bytes, causing memory corruption and hard to debug crashes. Fix this by setting mcast_list.num_multicast_addr to 0 when no multicast list is provided. Similarly, fix up the logic in mwifiex_request_set_multicast_list() to unset the multicast list that was previously sent to the hardware in such cases. Signed-off-by: Daniel Drake Acked-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman