commit f69d603ce6ec3c6aa9033e1e54102a74e58882bb Author: Greg Kroah-Hartman Date: Tue Oct 27 09:53:59 2015 +0900 Linux 4.2.5 commit 6e79c0abb15dab30baca017575280c6526ee4e15 Author: Steve Wise Date: Mon Sep 28 16:46:06 2015 -0500 svcrdma: handle rdma read with a non-zero initial page offset commit c91aed9896946721bb30705ea2904edb3725dd61 upstream. The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr() functions were not taking into account the initial page_offset when determining the rdma read length. This resulted in a read who's starting address and length exceeded the base/bounds of the frmr. The server gets an async error from the rdma device and kills the connection, and the client then reconnects and resends. This repeats indefinitely, and the application hangs. Most work loads don't tickle this bug apparently, but one test hit it every time: building the linux kernel on a 16 core node with 'make -j 16 O=/mnt/0' where /mnt/0 is a ramdisk mounted via NFSRDMA. This bug seems to only be tripped with devices having small fastreg page list depths. I didn't see it with mlx4, for instance. Fixes: 0bf4828983df ('svcrdma: refactor marshalling logic') Signed-off-by: Steve Wise Tested-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit dba4e9c12c31050ffe6438b60157de48cc7f3c62 Author: Steve Capper Date: Thu Oct 1 13:06:07 2015 +0100 arm64: Fix THP protection change logic commit 1a541b4e3cd6f5795022514114854b3e1345f24e upstream. 6910fa1 ("arm64: enable PTE type bit in the mask for pte_modify") fixes a problem whereby a large block of PROT_NONE mapped memory is incorrectly mapped as block descriptors when mprotect is called. Unfortunately, a subtle bug was introduced by this fix to the THP logic. If one mmaps a large block of memory, then faults it such that it is collapsed into THPs; resulting calls to mprotect on this area of memory will lead to incorrect table descriptors being written instead of block descriptors. This is because pmd_modify calls pte_modify which is now allowed to modify the type of the page table entry. This patch reverts commit 6910fa16dbe142f6a0fd0fd7c249f9883ff7fc8a, and fixes the problem it was trying to address by adjusting PAGE_NONE to represent a table entry. Thus no change in pte type is required when moving from PROT_NONE to a different protection. Fixes: 6910fa16dbe1 ("arm64: enable PTE type bit in the mask for pte_modify") Cc: # 4.0+ Cc: Feng Kan Reported-by: Ganapatrao Kulkarni Tested-by: Ganapatrao Kulkarni Reviewed-by: Catalin Marinas [SteveC: backported 1a541b4e3cd6f5795022514114854b3e1345f24e to 4.1 and 4.2 stable. Just one minor fix to second part to allow patch to apply cleanly, no logic changed.] Signed-off-by: Steve Capper Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit ff78a95c11ec3dc9c0bfec8aa37d2c9953b77c25 Author: Uwe Kleine-König Date: Wed Sep 23 16:35:09 2015 +0200 pinctrl: imx25: ensure that a pin with id i is at position i in the info array commit 9911a2d5e9d14e39692b751929a92cb5a1d9d0e0 upstream. The code in pinctrl-imx.c only works correctly if in the imx_pinctrl_soc_info passed to imx_pinctrl_probe we have: info->pins[i].number = i conf_reg(info->pins[i]) = 4 * i (which conf_reg(pin) being the offset of the pin's configuration register). When the imx25 specific part was introduced in b4a87c9b966f ("pinctrl: pinctrl-imx: add imx25 pinctrl driver") we had: info->pins[i].number = i + 1 conf_reg(info->pins[i]) = 4 * i . Commit 34027ca2bbc6 ("pinctrl: imx25: fix numbering for pins") tried to fix that but made the situation: info->pins[i-1].number = i conf_reg(info->pins[i-1]) = 4 * i which is hardly better but fixed the error seen back then. So insert another reserved entry in the array to finally yield: info->pins[i].number = i conf_reg(info->pins[i]) = 4 * i Fixes: 34027ca2bbc6 ("pinctrl: imx25: fix numbering for pins") Signed-off-by: Uwe Kleine-König Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 31a07f6dc6f16fafab8bebd673e653299bd03c93 Author: Thomas Gleixner Date: Fri Oct 16 15:50:22 2015 +0200 timekeeping: Increment clock_was_set_seq in timekeeping_init() commit 56fd16cabac9cd8f15e2902898a9d0cc96e2fa70 upstream. timekeeping_init() can set the wall time offset, so we need to increment the clock_was_set_seq counter. That way hrtimers will pick up the early offset immediately. Otherwise on a machine which does not set wall time later in the boot process the hrtimer offset is stale at 0 and wall time timers are going to expire with a delay of 45 years. Fixes: 868a3e915f7f "hrtimer: Make offset update smarter" Reported-and-tested-by: Heiko Carstens Signed-off-by: Thomas Gleixner Cc: Stefan Liebler Cc: Peter Zijlstra Cc: John Stultz Signed-off-by: Greg Kroah-Hartman commit 0c6eb5c35590b5105e4307c896f1c14e6e1e4915 Author: Ilya Dryomov Date: Mon Aug 31 15:21:39 2015 +0300 rbd: fix double free on rbd_dev->header_name commit 3ebe138ac642a195c7f2efdb918f464734421fd6 upstream. If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name is freed twice: once in rbd_dev_probe_parent() and then in its caller rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to handle parent images). rbd_dev_probe_parent() is responsible for probing the parent, so it shouldn't muck with clone's fields. Signed-off-by: Ilya Dryomov Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 15c6fd0e468f82b59799ab5e066dcf3e52cc7a36 Author: Mike Snitzer Date: Tue Oct 13 12:04:28 2015 -0400 dm thin: fix missing pool reference count decrement in pool_ctr error path commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd upstream. Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed") Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 62fb74e9f7e25279e72a82571cbac9c7baf37958 Author: Michel Dänzer Date: Thu Oct 8 17:48:04 2015 +0900 drm/amdgpu: Keep the pflip interrupts always enabled v7 commit f6c7aba47bcc0b1cc2085c8d8af80f8c02f28269 upstream. This fixes flickering issues caused by prematurely firing pflip interrupts. v2 (chk): add commit message, fix DCE V10/V11 and DM as well v3: Re-enable pflip interrupt wherever we re-enable a CRTC v4: Enable pflip interrupt in DAL as well v5: drop DAL changes for upstream v6: (agd): only enable interrupts on crtcs that exist v7: (agd): integrate suggestions from Michel Signed-off-by: Michel Dänzer Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b2e33f9e0ef4847f3d7c265f8adb478e7a74cb4c Author: Alex Deucher Date: Tue Oct 6 09:38:45 2015 -0400 drm/amdgpu: check before checking pci bridge registers commit e79d5c0870eedce94e5f5a2ffab30511e48fa144 upstream. Make sure we are not the root device before attempting to read the pcie bridge registers to check the pcie gen speeed. Fixes a crash when the device is passed through to a VM. Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 421216eb5efd68d1c6bd3e4c969f71079bd9d0af Author: Alex Deucher Date: Mon Oct 5 10:15:14 2015 -0400 drm/amdgpu: fix num_crtc on CZ commit 26d0c21db1fd1679fcf07863741c13ba5ce37a65 upstream. Hw only has 3 crtcs. copy paste typo. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 834223b58e16b974a194ddcd8a045441984f98fc Author: Alex Deucher Date: Wed Sep 30 17:05:40 2015 -0400 drm/amdgpu: add pm sysfs files late commit fa022a9b65d2886486a022fd66b20c823cd76ad9 upstream. They were added relatively early in the driver init process which meant that in some cases the driver was not finished initializing before external tools tried to use them which could result in a crash depending on the timing. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3f974429673759353a89f2008df46b720fe55978 Author: Alex Deucher Date: Wed Sep 30 16:45:52 2015 -0400 drm/radeon: add pm sysfs files late commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 upstream. They were added relatively early in the driver init process which meant that in some cases the driver was not finished initializing before external tools tried to use them which could result in a crash depending on the timing. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 344aea6d9a64e2503967408c3e240fa9f6dd9345 Author: Dave Airlie Date: Thu Oct 15 09:04:21 2015 +1000 drm/radeon: attach tile property to mst connector commit bc8c131ccdd62d4ed4f33c6b50f92907e7c32dee upstream. This allows tiled monitors to work with radeon once mst is enabled. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 48d5d0bdc5e1fddb1cd73cc85cc6fa2c9badcd93 Author: Dave Airlie Date: Wed Oct 14 18:51:17 2015 +1000 drm/dp/mst: make mst i2c transfer code more robust. commit ae491542cbbbcca0ec8938c37d4079a985e58440 upstream. This zeroes the msg so no random stack data ends up getting sent, it also limits the function to not accepting > 4 i2c msgs. Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6c9bb518a1ceebc6d266ac9055d6ba75be34ce1c Author: Ben Skeggs Date: Fri Oct 2 14:03:19 2015 +1000 drm/nouveau/fbcon: take runpm reference when userspace has an open fd commit f231976c2e8964ceaa9250e57d27c35ff03825c2 upstream. We need to do this in order to prevent accesses to the device while it's powered down. Userspace may have an mmap of the fb, and there's no good way (that I know of) to prevent it from touching the device otherwise. This fixes some nasty races between runpm and plymouth on some systems, which result in the GPU getting very upset and hanging the boot. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 724a70b0b396438a7555254eb651747dfd7af193 Author: Gerd Hoffmann Date: Mon Oct 5 12:20:26 2015 +0200 drm/qxl: fix framebuffer dirty rectangle tracking. commit 60906529bec506a4bde93f04eb5e7a9dd9c42a3b upstream. Commit "c0fe07a drm/qxl: rewrite framebuffer support" has a bug in the dirty rectangle tracking: Instead of ignoring an empty dirty rectangle when adding a new dirty region the dirty region gets extended to the upper left corner. Fix it. Signed-off-by: Gerd Hoffmann Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 03900dd5e4e08e3617d82c8b62bf5ed48d2508cd Author: Paolo Bonzini Date: Wed Oct 14 15:25:52 2015 +0200 KVM: x86: fix RSM into 64-bit protected mode commit b10d92a54dac25a6152f1aa1ffc95c12908035ce upstream. In order to get into 64-bit protected mode, you need to enable paging while EFER.LMA=1. For this to work, CS.L must be 0. Currently, we load the segments before CR0 and CR4, which means that if RSM returns into 64-bit protected mode CS.L is already 1 and everything breaks. Luckily, CS.L=0 is always the case when executing RSM, because it is forbidden to execute RSM from 64-bit protected mode. Hence it is enough to load CR0 and CR4 first, and only then the segments. Fixes: 660a5d517aaab9187f93854425c4c63f4a09195c Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0c2d5845347acbb2c140bd3e75baa8cd4a368949 Author: Paolo Bonzini Date: Tue Oct 13 10:19:35 2015 +0200 KVM: x86: fix SMI to halted VCPU commit 73917739334c6509833b0403b81d4a04a8784bdf upstream. An SMI to a halted VCPU must wake it up, hence a VCPU with a pending SMI must be considered runnable. Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ea83b307d539fe48c25cbfc8e1705673de21edc6 Author: Paolo Bonzini Date: Tue Oct 13 10:18:53 2015 +0200 KVM: x86: clean up kvm_arch_vcpu_runnable commit 5d9bc648b94dd719022343b8675e6c4381f0c45f upstream. Split the huge conditional in two functions. Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 Reviewed-by: Radim Krčmář Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a7c571f2e3ff9243ba41c242486f53dbca37d864 Author: Shaohua Li Date: Wed Sep 30 09:05:30 2015 -0700 workqueue: make sure delayed work run in local cpu commit 874bbfe600a660cba9c776b3957b1ce393151b76 upstream. My system keeps crashing with below message. vmstat_update() schedules a delayed work in current cpu and expects the work runs in the cpu. schedule_delayed_work() is expected to make delayed work run in local cpu. The problem is timer can be migrated with NO_HZ. __queue_work() queues work in timer handler, which could run in a different cpu other than where the delayed work is scheduled. The end result is the delayed work runs in different cpu. The patch makes __queue_delayed_work records local cpu earlier. Where the timer runs doesn't change where the work runs with the change. [ 28.010131] ------------[ cut here ]------------ [ 28.010609] kernel BUG at ../mm/vmstat.c:1392! [ 28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 28.011860] Modules linked in: [ 28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G W4.3.0-rc3+ #634 [ 28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014 [ 28.014160] Workqueue: events vmstat_update [ 28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000 [ 28.015445] RIP: 0010:[] []vmstat_update+0x31/0x80 [ 28.016282] RSP: 0018:ffff8800ba42fd80 EFLAGS: 00010297 [ 28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000 [ 28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d [ 28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000 [ 28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640 [ 28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000 [ 28.020071] FS: 0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000 [ 28.020071] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0 [ 28.020071] Stack: [ 28.020071] ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88 [ 28.020071] ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8 [ 28.020071] ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340 [ 28.020071] Call Trace: [ 28.020071] [] process_one_work+0x1c8/0x540 [ 28.020071] [] ? process_one_work+0x14b/0x540 [ 28.020071] [] worker_thread+0x114/0x460 [ 28.020071] [] ? process_one_work+0x540/0x540 [ 28.020071] [] kthread+0xf8/0x110 [ 28.020071] [] ?kthread_create_on_node+0x200/0x200 [ 28.020071] [] ret_from_fork+0x3f/0x70 [ 28.020071] [] ?kthread_create_on_node+0x200/0x200 Signed-off-by: Shaohua Li Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 3ff012faca18d004c99f32f3154c893d67f2297f Author: Wolfram Sang Date: Fri Oct 9 10:39:24 2015 +0100 i2c: designware-platdrv: enable RuntimePM before registering to the core commit 36d48fb5766aee9717e429f772046696b215282d upstream. The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Acked-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 1d9efb23ca8a7f178412e28b20bcd68b5b2a1f60 Author: Mika Westerberg Date: Thu Sep 24 12:06:54 2015 +0300 i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348 commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 upstream. ACPI SSCN/FMCN methods were originally added because then the platform can provide the most accurate HCNT/LCNT values to the driver. However, this seems not to be true for Dell Inspiron 7348 where using these causes the touchpad to fail in boot: i2c_hid i2c-DLL0675:00: failed to retrieve report from device. i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0675:00: failed to retrieve report from device. i2c_designware INT3433:00: controller timed out The values received from ACPI are (in fast mode): HCNT: 72 LCNT: 160 this translates to following timings (input clock is 100MHz on Broadwell): tHIGH: 720 ns (spec min 600 ns) tLOW: 1600 ns (spec min 1300 ns) Bus period: 2920 ns (assuming 300 ns tf and tr) Bus speed: 342.5 kHz Both tHIGH and tLOW are within the I2C specification. The calculated values when ACPI parameters are not used are (in fast mode): HCNT: 87 LCNT: 159 which translates to: tHIGH: 870 ns (spec min 600 ns) tLOW: 1590 ns (spec min 1300 ns) Bus period 3060 ns (assuming 300 ns tf and tr) Bus speed 326.8 kHz These values are also within the I2C specification. Since both ACPI and calculated values meet the I2C specification timing requirements it is hard to say why the touchpad does not function properly with the ACPI values except that the bus speed is higher in this case (but still well below the max 400kHz). Solve this by adding DMI quirk to the driver that disables using ACPI parameters on this particulare machine. Reported-by: Pavel Roskin Signed-off-by: Mika Westerberg Tested-by: Pavel Roskin Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 502c43bb6b442f75e0d829f9460dc3ba8e3da979 Author: Wolfram Sang Date: Sat Oct 10 08:24:23 2015 +0100 i2c: s3c2410: enable RuntimePM before registering to the core commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 upstream. The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Signed-off-by: Wolfram Sang Tested-by: Krzysztof Kozlowski Acked-by: Kukjin Kim Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 053e22a0992533653234367c6c79d0d781f3319e Author: Wolfram Sang Date: Fri Oct 9 10:39:25 2015 +0100 i2c: rcar: enable RuntimePM before registering to the core commit 4f7effddf4549d57114289f273710f077c4c330a upstream. The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Reported-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 9d8a3e537a511986208db3a887e34408934a7239 Author: Javier Martinez Canillas Date: Mon Sep 21 14:26:54 2015 +0200 mfd: max77843: Fix max77843_chg_init() return on error commit 1b52e50f2a402a266f1ba2281f0a57e87637a047 upstream. If i2c_new_dummy() fails in max77843_chg_init(), an PTR_ERR(NULL) is returned which is 0. So the function was wrongly returning a success value instead of an error code. Fixes: c7f585fe46d8 ("mfd: max77843: Add max77843 MFD driver core driver") Signed-off-by: Javier Martinez Canillas Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 0d6b6d7625050575f3fdc973cc0258ec04c9f401 Author: Christoph Hellwig Date: Fri Oct 9 15:03:26 2015 +0200 nfsd/blocklayout: accept any minlength commit 8c3ad9cb7343dc5f61b8cf3cdbe1016c5e7c2c8b upstream. Recent Linux clients have started to send GETLAYOUT requests with minlength less than blocksize. Servers aren't really allowed to impose this kind of restriction on layouts; see RFC 5661 section 18.43.3 for details. This has been observed to cause indefinite hangs on fsx runs on some clients. Signed-off-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f245eaa43ccd64e51a8e40a93d8a2e3b28a13b33 Author: Linus Walleij Date: Mon Aug 3 09:26:52 2015 +0200 ARM: ux500: simplify secondary CPU boot commit c00def71efd919e8ae835a25f4f4c80a4b2d36d3 upstream. This removes a lot of ancient cruft from the Ux500 SMP boot. Instead of the pen grab/release, just point the ROM to secondary_boot() and start the second CPU there, then send the IPI. Use our own SMP enable method. This enables us to remove the last static mapping and get both CPUs booting properly. Tested this and it just works. Signed-off-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit c8913ff16f29cef7a4b74b5be6d74ae52d10ff8c Author: Will Deacon Date: Thu Oct 8 11:11:17 2015 +0100 arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419 commit b6dd8e0719c0d2d01429639a11b7bc2677de240c upstream. Commit df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") sets CFLAGS_MODULE to ensure that the large memory model is used by the compiler when building kernel modules. However, CFLAGS_MODULE is an environment variable and intended to be overridden on the command line, which appears to be the case with the Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead. Cc: Ard Biesheuvel Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") Reported-by: Dann Frazier Tested-by: Dann Frazier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit e5b73597da65ef419bc46f904d15a415af55776b Author: Chris Mason Date: Tue Oct 13 14:06:48 2015 -0400 btrfs: fix use after free iterating extrefs commit dc6c5fb3b514221f2e9d21ee626a9d95d3418dff upstream. The code for btrfs inode-resolve has never worked properly for files with enough hard links to trigger extrefs. It was trying to get the leaf out of a path after freeing the path: btrfs_release_path(path); leaf = path->nodes[0]; item_size = btrfs_item_size_nr(leaf, slot); The fix here is to use the extent buffer we cloned just a little higher up to avoid deadlocks caused by using the leaf in the path. Signed-off-by: Chris Mason cc: Mark Fasheh Reviewed-by: Filipe Manana Reviewed-by: Mark Fasheh Signed-off-by: Greg Kroah-Hartman commit bf595083549df3aae42f71812f2a66b5a2066053 Author: David Sterba Date: Mon Oct 12 16:55:54 2015 +0200 btrfs: check unsupported filters in balance arguments commit 8eb934591f8bf584969454a658f629cd06e59f3a upstream. We don't verify that all the balance filter arguments supplemented by the flags are actually known to the kernel. Thus we let it silently pass and do nothing. At the moment this means only the 'limit' filter, but we're going to add a few more soon so it's better to have that fixed. Also in older stable kernels so that it works with newer userspace tools. Signed-off-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 0953cead4005519a9b690a387d41c3d201a6e287 Author: Shaohua Li Date: Thu Oct 15 15:28:29 2015 -0700 memcg: convert threshold to bytes commit 424cdc14138088ada1b0e407a2195b2783c6e5ef upstream. page_counter_memparse() returns pages for the threshold, while mem_cgroup_usage() returns bytes for memory usage. Convert the threshold to bytes. Fixes: 3e32cb2e0a12b6915 ("memcg: rename cgroup_event to mem_cgroup_event"). Signed-off-by: Shaohua Li Cc: Johannes Weiner Acked-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 07d25699afc37a6985321dcf7ba1ad38425f6731 Author: Russell King Date: Fri Oct 9 20:43:33 2015 +0100 crypto: ahash - ensure statesize is non-zero commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a upstream. Unlike shash algorithms, ahash drivers must implement export and import as their descriptors may contain hardware state and cannot be exported as is. Unfortunately some ahash drivers did not provide them and end up causing crashes with algif_hash. This patch adds a check to prevent these drivers from registering ahash algorithms until they are fixed. Signed-off-by: Russell King Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 74ca3884072bb2a3980331b7996b110320bcd68c Author: Ben Hutchings Date: Tue Oct 6 12:31:33 2015 +0100 crypto: camellia_aesni_avx - Fix CPU feature checks commit 92b279070dd6c94265db32748bbeb5b583588de9 upstream. We need to explicitly check the AVX and AES CPU features, as we can't infer them from the related XSAVE feature flags. For example, the Core i3 2310M passes the XSAVE feature test but does not implement AES-NI. Reported-and-tested-by: Stéphane Glondu References: https://bugs.debian.org/800934 Fixes: ce4f5f9b65ae ("x86/fpu, crypto x86/camellia_aesni_avx: Simplify...") Signed-off-by: Ben Hutchings Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4a371439ba97d44de98e8d0623f0181bbe464bcc Author: Dave Kleikamp Date: Mon Oct 5 10:08:51 2015 -0500 crypto: sparc - initialize blkcipher.ivsize commit a66d7f724a96d6fd279bfbd2ee488def6b081bea upstream. Some of the crypto algorithms write to the initialization vector, but no space has been allocated for it. This clobbers adjacent memory. Signed-off-by: Dave Kleikamp Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fd35f3ea99c5be493c381e7955dbff2f4353cb15 Author: Daniel Vetter Date: Tue Sep 29 09:56:53 2015 +0200 drm: Fix locking for sysfs dpms file commit 621bd0f6982badd6483acb191eb7b6226a578328 upstream. With atomic drivers we need to make sure that (at least in general) property reads hold the right locks. But the legacy dpms property is special and can be read locklessly. Since userspace loves to just randomly look at that all the time (like with "status") do that. To make it clear that we play tricks use the READ_ONCE compiler barrier (and also for paranoia). Note that there's not really anything bad going on since even with the new atomic paths we eventually end up not chasing any pointers (and hence possibly freed memory and other fun stuff). The locking WARNING has been added in commit 88a48e297b3a3bac6022c03babfb038f1a886cea Author: Rob Clark Date: Thu Dec 18 16:01:50 2014 -0500 drm: add atomic properties but since drivers are converting not everyone will have seen this from the start. Jens reported this and submitted a patch to just grab the mode_config.connection_mutex, but we can do a bit better. v2: Remove unused variables I failed to git add for real. Reference: http://mid.gmane.org/20150928194822.GA3930@kernel.dk Reported-by: Jens Axboe Tested-by: Jens Axboe Cc: Rob Clark Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 326ce2c1bc95805e724aced6a557e1adfce2b8f2 Author: Arad, Ronen Date: Thu Oct 15 01:55:17 2015 -0700 netlink: Trim skb to alloc size to avoid MSG_TRUNC [ Upstream commit db65a3aaf29ecce2e34271d52e8d2336b97bd9fe ] netlink_dump() allocates skb based on the calculated min_dump_alloc or a per socket max_recvmsg_len. min_alloc_size is maximum space required for any single netdev attributes as calculated by rtnl_calcit(). max_recvmsg_len tracks the user provided buffer to netlink_recvmsg. It is capped at 16KiB. The intention is to avoid small allocations and to minimize the number of calls required to obtain dump information for all net devices. netlink_dump packs as many small messages as could fit within an skb that was sized for the largest single netdev information. The actual space available within an skb is larger than what is requested. It could be much larger and up to near 2x with align to next power of 2 approach. Allowing netlink_dump to use all the space available within the allocated skb increases the buffer size a user has to provide to avoid truncaion (i.e. MSG_TRUNG flag set). It was observed that with many VLANs configured on at least one netdev, a larger buffer of near 64KiB was necessary to avoid "Message truncated" error in "ip link" or "bridge [-c[ompressvlans]] vlan show" when min_alloc_size was only little over 32KiB. This patch trims skb to allocated size in order to allow the user to avoid truncation with more reasonable buffer size. Signed-off-by: Ronen Arad Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 31fb431dd2347b9e5b94927d39ad49853b559b71 Author: Jon Paul Maloy Date: Wed Oct 14 09:23:18 2015 -0400 tipc: move fragment importance field to new header position [ Upstream commit dde4b5ae65de659b9ec64bafdde0430459fcb495 ] In commit e3eea1eb47a ("tipc: clean up handling of message priorities") we introduced a field in the packet header for keeping track of the priority of fragments, since this value is not present in the specified protocol header. Since the value so far only is used at the transmitting end of the link, we have not yet officially defined it as part of the protocol. Unfortunately, the field we use for keeping this value, bits 13-15 in in word 5, has turned out to be a poor choice; it is already used by the broadcast protocol for carrying the 'network id' field of the sending node. Since packet fragments also need to be transported across the broadcast protocol, the risk of conflict is obvious, and we see this happen when we use network identities larger than 2^13-1. This has escaped our testing because we have so far only been using small network id values. We now move this field to bits 0-2 in word 9, a field that is guaranteed to be unused by all involved protocols. Fixes: e3eea1eb47a ("tipc: clean up handling of message priorities") Signed-off-by: Jon Maloy Acked-by: Ying Xue Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 47f3f4f50d6f1f172e9d5911e8ff73c1ea3e2eb4 Author: Joe Perches Date: Wed Oct 14 01:09:40 2015 -0700 ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings [ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ] It seems that kernel memory can leak into userspace by a kmalloc, ethtool_get_strings, then copy_to_user sequence. Avoid this by using kcalloc to zero fill the copied buffer. Signed-off-by: Joe Perches Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 58d772c203ee57c45620730198bc2d9ded7a1464 Author: Eric W. Biederman Date: Mon Oct 12 11:02:08 2015 -0500 ipv6: Don't call with rt6_uncached_list_flush_dev [ Upstream commit e332bc67cf5e5e5b71a1aec9750d0791aac65183 ] As originally written rt6_uncached_list_flush_dev makes no sense when called with dev == NULL as it attempts to flush all uncached routes regardless of network namespace when dev == NULL. Which is simply incorrect behavior. Furthermore at the point rt6_ifdown is called with dev == NULL no more network devices exist in the network namespace so even if the code in rt6_uncached_list_flush_dev were to attempt something sensible it would be meaningless. Therefore remove support in rt6_uncached_list_flush_dev for handling network devices where dev == NULL, and only call rt6_uncached_list_flush_dev when rt6_ifdown is called with a network device. Fixes: 8d0b94afdca8 ("ipv6: Keep track of DST_NOCACHE routes in case of iface down/unregister") Signed-off-by: "Eric W. Biederman" Reviewed-by: Martin KaFai Lau Tested-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7ead98c6d585f756740c4a545c91517c0ef7984f Author: Alexei Starovoitov Date: Tue Oct 6 20:46:07 2015 -0700 bpf: clear sender_cpu before xmit [ Upstream commit 6bf0577374cfb6c2301dbf4934a4f23ad3d72763 ] Similar to commit c29390c6dfee ("xps: must clear sender_cpu before forwarding") the skb->sender_cpu needs to be cleared before xmit. Fixes: 3896d655f4d4 ("bpf: introduce bpf_clone_redirect() helper") Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d724fd630be439f033ff4af8e2dcc7406f1f0f20 Author: WANG Cong Date: Tue Oct 6 17:23:47 2015 -0700 act_mirred: clear sender cpu before sending to tx [ Upstream commit d40496a56430eac0d330378816954619899fe303 ] Similar to commit c29390c6dfee ("xps: must clear sender_cpu before forwarding") the skb->sender_cpu needs to be cleared when moving from Rx Tx, otherwise kernel could crash. Fixes: 2bd82484bb4c ("xps: fix xps for stacked devices") Cc: Eric Dumazet Cc: Jamal Hadi Salim Signed-off-by: Cong Wang Signed-off-by: Cong Wang Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit df3bd6a1ccd7e0c204c7c50dff26677629ceb3ef Author: Konstantin Khlebnikov Date: Fri Oct 2 13:18:22 2015 +0300 ovs: do not allocate memory from offline numa node [ Upstream commit 598c12d0ba6de9060f04999746eb1e015774044b ] When openvswitch tries allocate memory from offline numa node 0: stats = kmem_cache_alloc_node(flow_stats_cache, GFP_KERNEL | __GFP_ZERO, 0) It catches VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid)) [ replaced with VM_WARN_ON(!node_online(nid)) recently ] in linux/gfp.h This patch disables numa affinity in this case. Signed-off-by: Konstantin Khlebnikov Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7893724d1066f09f474639ba2cfe2a7160fd9e28 Author: Daniel Borkmann Date: Fri Oct 2 12:06:03 2015 +0200 bpf: fix panic in SO_GET_FILTER with native ebpf programs [ Upstream commit 93d08b6966cf730ea669d4d98f43627597077153 ] When sockets have a native eBPF program attached through setsockopt(sk, SOL_SOCKET, SO_ATTACH_BPF, ...), and then try to dump these over getsockopt(sk, SOL_SOCKET, SO_GET_FILTER, ...), the following panic appears: [49904.178642] BUG: unable to handle kernel NULL pointer dereference at (null) [49904.178762] IP: [] sk_get_filter+0x39/0x90 [49904.182000] PGD 86fc9067 PUD 531a1067 PMD 0 [49904.185196] Oops: 0000 [#1] SMP [...] [49904.224677] Call Trace: [49904.226090] [] sock_getsockopt+0x319/0x740 [49904.227535] [] ? sock_has_perm+0x63/0x70 [49904.228953] [] ? release_sock+0x108/0x150 [49904.230380] [] ? selinux_socket_getsockopt+0x23/0x30 [49904.231788] [] SyS_getsockopt+0xa6/0xc0 [49904.233267] [] entry_SYSCALL_64_fastpath+0x12/0x71 The underlying issue is the very same as in commit b382c0865600 ("sock, diag: fix panic in sock_diag_put_filterinfo"), that is, native eBPF programs don't store an original program since this is only needed in cBPF ones. However, sk_get_filter() wasn't updated to test for this at the time when eBPF could be attached. Just throw an error to the user to indicate that eBPF cannot be dumped over this interface. That way, it can also be known that a program _is_ attached (as opposed to just return 0), and a different (future) method needs to be consulted for a dump. Fixes: 89aa075832b0 ("net: sock: allow eBPF programs to be attached to sockets") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fe3077a4aa47a30572c27ef6b69b9e512aa2a068 Author: Eric Dumazet Date: Thu Oct 1 05:39:26 2015 -0700 inet: fix race in reqsk_queue_unlink() [ Upstream commit 2306c704ce280c97a60d1f45333b822b40281dea ] reqsk_timer_handler() tests if icsk_accept_queue.listen_opt is NULL at its beginning. By the time it calls inet_csk_reqsk_queue_drop() and reqsk_queue_unlink(), listener might have been closed and inet_csk_listen_stop() had called reqsk_queue_yank_acceptq() which sets icsk_accept_queue.listen_opt to NULL We therefore need to correctly check listen_opt being NULL after holding syn_wait_lock for proper synchronization. Fixes: fa76ce7328b2 ("inet: get rid of central tcp/dccp listener timer") Fixes: b357a364c57c ("inet: fix possible panic in reqsk_queue_unlink()") Signed-off-by: Eric Dumazet Cc: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eea189e9a30977feeea7fc1a1355557fef3d91f2 Author: Guillaume Nault Date: Wed Sep 30 11:45:33 2015 +0200 ppp: don't override sk->sk_state in pppoe_flush_dev() [ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ] Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"), pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the following oops: [ 570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0 [ 570.142931] IP: [] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0 [ 570.144601] Oops: 0000 [#1] SMP [ 570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio [ 570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1 [ 570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000 [ 570.144601] RIP: 0010:[] [] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] RSP: 0018:ffff880036b63e08 EFLAGS: 00010202 [ 570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206 [ 570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20 [ 570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000 [ 570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780 [ 570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0 [ 570.144601] FS: 00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000 [ 570.144601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0 [ 570.144601] Stack: [ 570.144601] ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0 [ 570.144601] ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008 [ 570.144601] ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5 [ 570.144601] Call Trace: [ 570.144601] [] sock_release+0x1a/0x75 [ 570.144601] [] sock_close+0xd/0x11 [ 570.144601] [] __fput+0xff/0x1a5 [ 570.144601] [] ____fput+0x9/0xb [ 570.144601] [] task_work_run+0x66/0x90 [ 570.144601] [] prepare_exit_to_usermode+0x8c/0xa7 [ 570.144601] [] syscall_return_slowpath+0x16d/0x19b [ 570.144601] [] int_ret_from_sys_call+0x25/0x9f [ 570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00 [ 570.144601] RIP [] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] RSP [ 570.144601] CR2: 00000000000004e0 [ 570.200518] ---[ end trace 46956baf17349563 ]--- pppoe_flush_dev() has no reason to override sk->sk_state with PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to PPPOX_DEAD, which is the correct state given that sk is unbound and po->pppoe_dev is NULL. Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Tested-by: Oleksii Berezhniak Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f56dd94c0e03df9ad8ddb1c7c97bbf6287cd6ea Author: Eric Dumazet Date: Tue Sep 29 18:52:25 2015 -0700 net: add pfmemalloc check in sk_add_backlog() [ Upstream commit c7c49b8fde26b74277188bdc6c9dca38db6fa35b ] Greg reported crashes hitting the following check in __sk_backlog_rcv() BUG_ON(!sock_flag(sk, SOCK_MEMALLOC)); The pfmemalloc bit is currently checked in sk_filter(). This works correctly for TCP, because sk_filter() is ran in tcp_v[46]_rcv() before hitting the prequeue or backlog checks. For UDP or other protocols, this does not work, because the sk_filter() is ran from sock_queue_rcv_skb(), which might be called _after_ backlog queuing if socket is owned by user by the time packet is processed by softirq handler. Fixes: b4b9e35585089 ("netvm: set PF_MEMALLOC as appropriate during SKB processing") Signed-off-by: Eric Dumazet Reported-by: Greg Thelen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c4e11ec108c09333ae16565515bd2e2349369d2a Author: Eric Dumazet Date: Sat Sep 19 09:48:04 2015 -0700 inet: fix races in reqsk_queue_hash_req() [ Upstream commit 29c6852602e259d2c1882f320b29d5c3fec0de04 ] Before allowing lockless LISTEN processing, we need to make sure to arm the SYN_RECV timer before the req socket is visible in hash tables. Also, req->rsk_hash should be written before we set rsk_refcnt to a non zero value. Fixes: fa76ce7328b2 ("inet: get rid of central tcp/dccp listener timer") Signed-off-by: Eric Dumazet Cc: Ying Cai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af72f6066339f25f781e24a85f56bbab806a7554 Author: Vivien Didelot Date: Tue Sep 29 14:17:54 2015 -0400 net: dsa: fix preparation of a port STP update [ Upstream commit 57a47532c4312159935c98b7f1cf0e62296b9171 ] Because of the default 0 value of ret in dsa_slave_port_attr_set, a driver may return -EOPNOTSUPP from the commit phase of a STP state, which triggers a WARN() from switchdev. This happened on a 6185 switch which does not support hardware bridging. Fixes: 3563606258cf ("switchdev: convert STP update to switchdev attr set") Reported-by: Andrew Lunn Signed-off-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dbce2220803222ccdaca8a22a4df9688738dbbc6 Author: Pravin B Shelar Date: Mon Sep 28 17:24:25 2015 -0700 skbuff: Fix skb checksum partial check. [ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ] Earlier patch 6ae459bda tried to detect void ckecksum partial skb by comparing pull length to checksum offset. But it does not work for all cases since checksum-offset depends on updates to skb->data. Following patch fixes it by validating checksum start offset after skb-data pointer is updated. Negative value of checksum offset start means there is no need to checksum. Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull") Reported-by: Andrew Vagin Signed-off-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d20c97ca3264c3c5b70eb25cd126ee77e4cae851 Author: Pravin B Shelar Date: Tue Sep 22 12:57:53 2015 -0700 skbuff: Fix skb checksum flag on skb pull [ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ] VXLAN device can receive skb with checksum partial. But the checksum offset could be in outer header which is pulled on receive. This results in negative checksum offset for the skb. Such skb can cause the assert failure in skb_checksum_help(). Following patch fixes the bug by setting checksum-none while pulling outer header. Following is the kernel panic msg from old kernel hitting the bug. ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1906! RIP: 0010:[] skb_checksum_help+0x144/0x150 Call Trace: [] queue_userspace_packet+0x408/0x470 [openvswitch] [] ovs_dp_upcall+0x5d/0x60 [openvswitch] [] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch] [] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch] [] ovs_vport_receive+0x2a/0x30 [openvswitch] [] vxlan_rcv+0x53/0x60 [openvswitch] [] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch] [] udp_queue_rcv_skb+0x2dc/0x3b0 [] __udp4_lib_rcv+0x1cf/0x6c0 [] udp_rcv+0x1a/0x20 [] ip_local_deliver_finish+0xdd/0x280 [] ip_local_deliver+0x88/0x90 [] ip_rcv_finish+0x10d/0x370 [] ip_rcv+0x235/0x300 [] __netif_receive_skb+0x55d/0x620 [] netif_receive_skb+0x80/0x90 [] virtnet_poll+0x555/0x6f0 [] net_rx_action+0x134/0x290 [] __do_softirq+0xa8/0x210 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0x8e/0xb0 [] do_IRQ+0x63/0xe0 [] common_interrupt+0x6e/0x6e Reported-by: Anupam Chanda Signed-off-by: Pravin B Shelar Acked-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f907c4cf456a3d2bf5f93a76765fd738d5a14ba2 Author: Andrey Vagin Date: Fri Oct 2 00:05:36 2015 +0300 net/unix: fix logic about sk_peek_offset [ Upstream commit e9193d60d363e4dff75ff6d43a48f22be26d59c7 ] Now send with MSG_PEEK can return data from multiple SKBs. Unfortunately we take into account the peek offset for each skb, that is wrong. We need to apply the peek offset only once. In addition, the peek offset should be used only if MSG_PEEK is set. Cc: "David S. Miller" (maintainer:NETWORKING Cc: Eric Dumazet (commit_signer:1/14=7%) Cc: Aaron Conole Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag") Signed-off-by: Andrey Vagin Tested-by: Aaron Conole Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 49ac87601450c4ab4685a93be3d8f12c8bc8fe5f Author: Aaron Conole Date: Sat Sep 26 18:50:43 2015 -0400 af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag [ Upstream commit 9f389e35674f5b086edd70ed524ca0f287259725 ] AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag is set. This is referenced in kernel bugzilla #12323 @ https://bugzilla.kernel.org/show_bug.cgi?id=12323 As described both in the BZ and lkml thread @ http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an AF_UNIX socket only reads a single skb, where the desired effect is to return as much skb data has been queued, until hitting the recv buffer size (whichever comes first). The modified MSG_PEEK path will now move to the next skb in the tree and jump to the again: label, rather than following the natural loop structure. This requires duplicating some of the loop head actions. This was tested using the python socketpair python code attached to the bugzilla issue. Signed-off-by: Aaron Conole Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6e06f341278845c14bde3438d5cef50354692ac Author: Aaron Conole Date: Sat Sep 26 18:50:42 2015 -0400 af_unix: Convert the unix_sk macro to an inline function for type safety [ Upstream commit 4613012db1d911f80897f9446a49de817b2c4c47 ] As suggested by Eric Dumazet this change replaces the #define with a static inline function to enjoy complaints by the compiler when misusing the API. Signed-off-by: Aaron Conole Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e23ef3bd21ee4aedf7ee257e5bca7d2f128713ca Author: Alexander Couzens Date: Mon Sep 28 11:32:42 2015 +0200 l2tp: protect tunnel->del_work by ref_count [ Upstream commit 06a15f51cf3618e32a73871ee6a547ef7fd902b5 ] There is a small chance that tunnel_free() is called before tunnel->del_work scheduled resulting in a zero pointer dereference. Signed-off-by: Alexander Couzens Acked-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d034161050e87180a3f97e53ced881dc30d20cca Author: Ivan Mikhaylov Date: Fri Sep 25 11:52:27 2015 +0400 net/ibm/emac: bump version numbers for correct work with ethtool [ Upstream commit 661dfc65f7981481ba2e31aaa702371e82336e56 ] The size of the MAC register dump used to be the size specified by the reg property in the device tree. Userland has no good way of finding out that size, and it was not specified consistently for each MAC type, so ethtool would end up printing junk at the end of the register dump if the device tree didn't match the size it assumed. Using the new version numbers indicates unambiguously that the size of the MAC register dump is dependent only on the MAC type. Fixes: 5369c71f7ca2 ("net/ibm/emac: fix size of emac dump memory areas") Signed-off-by: Ivan Mikhaylov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman