commit e9e1b43e9f912ee8aad24534584a6257d2b43aba Author: Sasha Levin Date: Fri Sep 2 22:46:35 2016 -0400 Linux 3.18.41 Signed-off-by: Sasha Levin commit 8a1a4c7aa10452bba98a52434cf165ee45d0f362 Author: Simon Horman Date: Fri Dec 11 11:30:12 2015 +0900 PCI: Limit config space size for Netronome NFP4000 [ Upstream commit c2e771b02792d222cbcd9617fe71482a64f52647 ] Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP4000's PF's config space size to 0x600 bytes as is already done for the NFP6000. The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 1935e8370a462eb381b4ca2497ab8c8ac5c938c0 Author: Simon Horman Date: Fri Dec 11 11:30:11 2015 +0900 PCI: Add Netronome NFP4000 PF device ID [ Upstream commit 69874ec233871a62e1bc8c89e643993af93a8630 ] Add the device ID for the PF of the NFP4000. The device ID for the VF, 0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF. Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit bfb058ebd7a51fdb1d3701489496900f098992df Author: Jason S. McMullan Date: Wed Sep 30 15:35:07 2015 +0900 PCI: Limit config space size for Netronome NFP6000 family [ Upstream commit 9f33a2ae59f24452c1076749deb615bccd435ca9 ] The NFP6000 has an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP6000's config space size to 0x600 bytes. Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 7a5b93be58500dc7e7e2de5ea0d2c9f245f69c8b Author: Jason S. McMullan Date: Wed Sep 30 15:35:06 2015 +0900 PCI: Add Netronome vendor and device IDs [ Upstream commit a755e169031dac9ebaed03302c4921687c271d62 ] Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV devices. Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit ab2b9d85ce2d2a9b8eb6dff5c1b6c747b2ef3ddf Author: Jason S. McMullan Date: Wed Sep 30 15:35:05 2015 +0900 PCI: Support PCIe devices with short cfg_size [ Upstream commit c20aecf6963d1273d8f6d61c042b4845441ca592 ] If a device quirk modifies the pci_dev->cfg_size to be less than PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256), the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE. Allow sysfs access to config space up to cfg_size, even if the device doesn't support the entire 4096-byte PCIe config space. Note that pci_read_config() and pci_write_config() limit access to dev->cfg_size even though pcie_config_attr contains 4096 (the maximum size). Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman [bhelgaas: more changelog edits] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 47e617f9e58aa4a472c53a9ccfd6491e69bdb394 Author: Hubert Feurstein Date: Wed Jan 7 14:48:17 2015 +0100 net: fec: fix NULL pointer dereference in fec_enet_timeout_work [ Upstream commit 0c8185944a125621a1766615585238a3563ccac3 ] This patch initialises the fep->netdev pointer. This pointer was not initialised at all, but is used in fec_enet_timeout_work and in some error paths. Signed-off-by: Hubert Feurstein Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5de0c13e48a041dfc91b63a12a5b1ff37d3ed592 Author: Vegard Nossum Date: Thu Aug 25 15:17:11 2016 -0700 fs/seq_file: fix out-of-bounds read [ Upstream commit 088bf2ff5d12e2e32ee52a4024fec26e582f44d3 ] seq_read() is a nasty piece of work, not to mention buggy. It has (I think) an old bug which allows unprivileged userspace to read beyond the end of m->buf. I was getting these: BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr ffff880116889880 Read of size 2713 by task trinity-c2/1329 CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: kasan_object_err+0x1c/0x80 kasan_report_error+0x2cb/0x7e0 kasan_report+0x4e/0x80 check_memory_region+0x13e/0x1a0 kasan_check_read+0x11/0x20 seq_read+0xcd2/0x1480 proc_reg_read+0x10b/0x260 do_loop_readv_writev.part.5+0x140/0x2c0 do_readv_writev+0x589/0x860 vfs_readv+0x7b/0xd0 do_readv+0xd8/0x2c0 SyS_readv+0xb/0x10 do_syscall_64+0x1b3/0x4b0 entry_SYSCALL64_slow_path+0x25/0x25 Object at ffff880116889100, in cache kmalloc-4096 size: 4096 Allocated: PID = 1329 save_stack_trace+0x26/0x80 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x1aa/0x4a0 seq_buf_alloc+0x35/0x40 seq_read+0x7d8/0x1480 proc_reg_read+0x10b/0x260 do_loop_readv_writev.part.5+0x140/0x2c0 do_readv_writev+0x589/0x860 vfs_readv+0x7b/0xd0 do_readv+0xd8/0x2c0 SyS_readv+0xb/0x10 do_syscall_64+0x1b3/0x4b0 return_from_SYSCALL_64+0x0/0x6a Freed: PID = 0 (stack is not available) Memory state around the buggy address: ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint This seems to be the same thing that Dave Jones was seeing here: https://lkml.org/lkml/2016/8/12/334 There are multiple issues here: 1) If we enter the function with a non-empty buffer, there is an attempt to flush it. But it was not clearing m->from after doing so, which means that if we try to do this flush twice in a row without any call to traverse() in between, we are going to be reading from the wrong place -- the splat above, fixed by this patch. 2) If there's a short write to userspace because of page faults, the buffer may already contain multiple lines (i.e. pos has advanced by more than 1), but we don't save the progress that was made so the next call will output what we've already returned previously. Since that is a much less serious issue (and I have a headache after staring at seq_read() for the past 8 hours), I'll leave that for now. Link: http://lkml.kernel.org/r/1471447270-32093-1-git-send-email-vegard.nossum@oracle.com Signed-off-by: Vegard Nossum Reported-by: Dave Jones Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c8ca488fa42069e07e2fce5789dcbddc4fb2f143 Author: Chen-Yu Tsai Date: Thu Aug 25 14:26:59 2016 +0800 clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function [ Upstream commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e ] The bootloader (U-boot) sometimes uses this timer for various delays. It uses it as a ongoing counter, and does comparisons on the current counter value. The timer counter is never stopped. In some cases when the user interacts with the bootloader, or lets it idle for some time before loading Linux, the timer may expire, and an interrupt will be pending. This results in an unexpected interrupt when the timer interrupt is enabled by the kernel, at which point the event_handler isn't set yet. This results in a NULL pointer dereference exception, panic, and no way to reboot. Clear any pending interrupts after we stop the timer in the probe function to avoid this. Cc: stable@vger.kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Daniel Lezcano Acked-by: Maxime Ripard Signed-off-by: Sasha Levin commit 82d1894c12e5b0f56254af46dd0b8bfec7930cfc Author: Mike Snitzer Date: Wed Aug 24 21:12:58 2016 -0400 dm flakey: fix reads to be issued if drop_writes configured [ Upstream commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc ] v4.8-rc3 commit 99f3c90d0d ("dm flakey: error READ bios during the down_interval") overlooked the 'drop_writes' feature, which is meant to allow reads to be issued rather than errored, during the down_interval. Fixes: 99f3c90d0d ("dm flakey: error READ bios during the down_interval") Reported-by: Qu Wenruo Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4306acd039b521db087a11b0701db816e231a0da Author: Jan Beulich Date: Mon Aug 15 09:02:38 2016 -0600 xenbus: don't look up transaction IDs for ordinary writes [ Upstream commit 9a035a40f7f3f6708b79224b86c5777a3334f7ea ] This should really only be done for XS_TRANSACTION_END messages, or else at least some of the xenstore-* tools don't work anymore. Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition") Reported-by: Richard Schütz Cc: Signed-off-by: Jan Beulich Tested-by: Richard Schütz Signed-off-by: David Vrabel Signed-off-by: Sasha Levin commit 189f6d32277fbc6901c5d09ec5b9df1fef3657b0 Author: John Stultz Date: Tue Aug 23 16:08:22 2016 -0700 timekeeping: Cap array access in timekeeping_debug [ Upstream commit a4f8f6667f099036c88f231dcad4cf233652c824 ] It was reported that hibernation could fail on the 2nd attempt, where the system hangs at hibernate() -> syscore_resume() -> i8237A_resume() -> claim_dma_lock(), because the lock has already been taken. However there is actually no other process would like to grab this lock on that problematic platform. Further investigation showed that the problem is triggered by setting /sys/power/pm_trace to 1 before the 1st hibernation. Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend, and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller than 1970) to the release date of that motherboard during POST stage, thus after resumed, it may seem that the system had a significant long sleep time which is a completely meaningless value. Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the sleep time happened to be set to 1, fls() returns 32 and we add 1 to sleep_time_bin[32], which causes an out of bounds array access and therefor memory being overwritten. As depicted by System.map: 0xffffffff81c9d080 b sleep_time_bin 0xffffffff81c9d100 B dma_spin_lock the dma_spin_lock.val is set to 1, which caused this problem. This patch adds a sanity check in tk_debug_account_sleep_time() to ensure we don't index past the sleep_time_bin array. [jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the issue slightly differently, but borrowed his excelent explanation of the issue here.] Fixes: 5c83545f24ab "power: Add option to log time spent in suspend" Reported-by: Janek Kozicki Reported-by: Chen Yu Signed-off-by: John Stultz Cc: linux-pm@vger.kernel.org Cc: Peter Zijlstra Cc: Xunlei Pang Cc: "Rafael J. Wysocki" Cc: stable Cc: Zhang Rui Link: http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 53cd25db577885493f93b997aaf46dda0da494c5 Author: Vincent Stehlé Date: Fri Aug 12 15:26:30 2016 +0200 ubifs: Fix assertion in layout_in_gaps() [ Upstream commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a ] An assertion in layout_in_gaps() verifies that the gap_lebs pointer is below the maximum bound. When computing this maximum bound the idx_lebs count is multiplied by sizeof(int), while C pointers arithmetic does take into account the size of the pointed elements implicitly already. Remove the multiplication to fix the assertion. Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system") Cc: Signed-off-by: Vincent Stehlé Cc: Artem Bityutskiy Signed-off-by: Artem Bityutskiy Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit e09bf1516765b02960afa72f3dc9ec2625ea1f95 Author: Masahiro Yamada Date: Mon Aug 22 13:25:56 2016 -0700 Input: tegra-kbc - fix inverted reset logic [ Upstream commit fae16989be77b09bab86c79233e4b511ea769cea ] Commit fe6b0dfaba68 ("Input: tegra-kbc - use reset framework") accidentally converted _deassert to _assert, so there is no code to wake up this hardware. Fixes: fe6b0dfaba68 ("Input: tegra-kbc - use reset framework") Signed-off-by: Masahiro Yamada Acked-by: Thierry Reding Acked-by: Laxman Dewangan Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit fc604c2aab294ce1ed4d3fbe934bc145e311e4a2 Author: Daniel Vetter Date: Sat Aug 20 12:22:11 2016 +0200 drm: Reject page_flip for !DRIVER_MODESET [ Upstream commit 6f00975c619064a18c23fd3aced325ae165a73b9 ] Somehow this one slipped through, which means drivers without modeset support can be oopsed (since those also don't call drm_mode_config_init, which means the crtc lookup will chase an uninitalized idr). Reported-by: Alexander Potapenko Cc: Alexander Potapenko Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit a0d020d209d4307c113bc2bcfc3302ce29b66eaf Author: Helge Deller Date: Sat Aug 20 11:51:38 2016 +0200 parisc: Fix order of EREFUSED define in errno.h [ Upstream commit 3eb53b20d7bd1374598cfb1feaa081fcac0e76cd ] When building gccgo in userspace, errno.h gets parsed and the go include file sysinfo.go is generated. Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED is defined later on in errno.h, this leads to go complaining that EREFUSED isn't defined yet. Fix this trivial problem by moving the define of EREFUSED down after ECONNREFUSED in errno.h (and clean up the indenting while touching this line). Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 3838b8be3f653ef129d2845dcd4045d9c3f3181a Author: Vineet Gupta Date: Fri Aug 19 13:59:02 2016 -0700 ARC: export __udivdi3 for modules [ Upstream commit c57653dc94d0db7bf63067433ceaa97bdcd0a312 ] Some module using div_u64() was failing to link because the libgcc 64-bit divide assist routine was not being exported for modules Reported-by: avinashp@quantenna.com Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit d60e7f47d10ad378783fe651c7aea564307fb9ca Author: Vineet Gupta Date: Wed Aug 10 14:10:57 2016 -0700 ARC: Support syscall ABI v4 [ Upstream commit 840c054fd0efb048df6fceb0c46385ec5b66dfe6 ] The syscall ABI includes the gcc functional calling ABI since a syscall implies userland caller and kernel callee. The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in even-odd register pairs, (potentially punching reg holes when passing such values as args). This was partly driven by the fact that the double-word LDD/STD instructions in ARCv2 expect the register alignment and thus gcc forcing this avoids extra MOV at the cost of a few unused register (which we have plenty anyways). This however was rejected as part of upstreaming gcc port to HS. So the new ABI v4 doesn't enforce the even-odd reg restriction. Do note that for ARCompact ISA builds v3 and v4 are practically the same in terms of gcc code generation. In terms of change management, we infer the new ABI if gcc 6.x onwards is used for building the kernel. This also needs a stable backport to enable older kernels to work with new tools/user-space Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit c37166585ffc236027bbd16891817ab43e414e70 Author: Liav Rehana Date: Tue Aug 16 10:55:35 2016 +0300 ARC: use correct offset in pt_regs for saving/restoring user mode r25 [ Upstream commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 ] User mode callee regs are explicitly collected before signal delivery or breakpoint trap. r25 is special for kernel as it serves as task pointer, so user mode value is clobbered very early. It is saved in pt_regs where generally only scratch (aka caller saved) regs are saved. The code to access the corresponding pt_regs location had a subtle bug as it was using load/store with scaling of offset, whereas the offset was already byte wise correct. So fix this by replacing LD.AS with a standard LD Cc: Signed-off-by: Liav Rehana Reviewed-by: Alexey Brodkin [vgupta: rewrote title and commit log] Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 6c262bd14fa7f4ef0e36ae65dedbba178ce9ef85 Author: Vineet Gupta Date: Tue Oct 7 14:12:13 2014 +0530 ARCv2: STAR 9000808988: signals involving Delay Slot [ Upstream commit 0d7b8855a05c099a5c65a8d49a1e604198021f56 ] Reported by Anton as LTP:munmap01 failing with Illegal Instruction Exception. --------------------->8-------------------------------------- mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x200d2000 munmap(0x200d2000, 24576) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x200d2000} --- potentially unexpected fatal signal 4. Path: /munmap01 CPU: 0 PID: 61 Comm: munmap01 Not tainted 3.13.0-g5d5c46d9a556 #8 task: 9f1a8000 ti: 9f154000 task.ti: 9f154000 [ECR ]: 0x00020100 => Illegal Insn [EFA ]: 0x0001354c [BLINK ]: 0x200515d4 [ERET ]: 0x1354c @off 0x1354c in [/munmap01] VMA: 0x00010000 to 0x00018000 [STAT32]: 0x800802c0 ... --------------------->8-------------------------------------- The issue was 1. munmap01 accessed unmapped memory (on purpose) with signal handler installed for SIGSEGV 2. The faulting instruction happened to be in Delay Slot 00011864
: 11908: bl.d 13284 1190c: stb r16,[r2] 3. kernel sets up the reg file for signal handler and correctly clears the DE bit in pt_regs->status32 placeholder 4. However RESTORE_CALLEE_SAVED_USER macro is not adjusted for ARCv2, and it over-writes the above with orig/stale value of status32 5. After RTIE, userspace signal handler executes a non branch instruction with DE bit set, triggering Illegal Instruction Exception. Reported-by: Anton Kolesov Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 61f53d4a977b40f6c0673c4ee6587fc825ec9e44 Author: Dmitry Torokhov Date: Tue Aug 16 17:38:54 2016 -0700 Input: i8042 - set up shared ps2_cmd_mutex for AUX ports [ Upstream commit 47af45d684b5f3ae000ad448db02ce4f13f73273 ] The commit 4097461897df ("Input: i8042 - break load dependency ...") correctly set up ps2_cmd_mutex pointer for the KBD port but forgot to do the same for AUX port(s), which results in communication on KBD and AUX ports to clash with each other. Fixes: 4097461897df ("Input: i8042 - break load dependency ...") Reported-by: Bruno Wolff III Tested-by: Bruno Wolff III Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 0a47a53081df72950f8614c6b9e8e830e80a3ac1 Author: Christian König Date: Wed Aug 17 09:46:42 2016 +0200 drm/radeon: fix radeon_move_blit on 32bit systems [ Upstream commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 ] This bug seems to be present for a very long time. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 183e633e33201530453c84b5affd01df8c46171b Author: Linus Walleij Date: Tue Aug 16 09:58:25 2016 +0200 gpio: Fix OF build problem on UM [ Upstream commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 ] The UserMode (UM) Linux build was failing in gpiolib-of as it requires ioremap()/iounmap() to exist, which is absent from UM. The non-existence of IO memory is negatively defined as CONFIG_NO_IOMEM which means we need to depend on HAS_IOMEM. Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven Reported-by: kbuild test robot Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3dd120f43407cb270b40cfe931430517a604c914 Author: Kent Overstreet Date: Wed Aug 17 18:21:24 2016 -0700 bcache: RESERVE_PRIO is too small by one when prio_buckets() is a power of two. [ Upstream commit acc9cf8c66c66b2cbbdb4a375537edee72be64df ] This patch fixes a cachedev registration-time allocation deadlock. This can deadlock on boot if your initrd auto-registeres bcache devices: Allocator thread: [ 720.727614] INFO: task bcache_allocato:3833 blocked for more than 120 seconds. [ 720.732361] [] schedule+0x37/0x90 [ 720.732963] [] bch_bucket_alloc+0x188/0x360 [bcache] [ 720.733538] [] ? prepare_to_wait_event+0xf0/0xf0 [ 720.734137] [] bch_prio_write+0x19d/0x340 [bcache] [ 720.734715] [] bch_allocator_thread+0x3ff/0x470 [bcache] [ 720.735311] [] ? __schedule+0x2dc/0x950 [ 720.735884] [] ? invalidate_buckets+0x980/0x980 [bcache] Registration thread: [ 720.710403] INFO: task bash:3531 blocked for more than 120 seconds. [ 720.715226] [] schedule+0x37/0x90 [ 720.715805] [] __bch_btree_map_nodes+0x12d/0x150 [bcache] [ 720.716409] [] ? bch_btree_insert_check_key+0x1c0/0x1c0 [bcache] [ 720.717008] [] bch_btree_insert+0xf4/0x170 [bcache] [ 720.717586] [] ? prepare_to_wait_event+0xf0/0xf0 [ 720.718191] [] bch_journal_replay+0x14a/0x290 [bcache] [ 720.718766] [] ? ttwu_do_activate.constprop.94+0x5d/0x70 [ 720.719369] [] ? try_to_wake_up+0x1d4/0x350 [ 720.719968] [] run_cache_set+0x580/0x8e0 [bcache] [ 720.720553] [] register_bcache+0xe2e/0x13b0 [bcache] [ 720.721153] [] kobj_attr_store+0xf/0x20 [ 720.721730] [] sysfs_kf_write+0x3d/0x50 [ 720.722327] [] kernfs_fop_write+0x12a/0x180 [ 720.722904] [] __vfs_write+0x37/0x110 [ 720.723503] [] ? __sb_start_write+0x58/0x110 [ 720.724100] [] ? security_file_permission+0x23/0xa0 [ 720.724675] [] vfs_write+0xa9/0x1b0 [ 720.725275] [] ? do_audit_syscall_entry+0x6c/0x70 [ 720.725849] [] SyS_write+0x55/0xd0 [ 720.726451] [] ? do_page_fault+0x30/0x80 [ 720.727045] [] system_call_fastpath+0x12/0x71 The fifo code in upstream bcache can't use the last element in the buffer, which was the cause of the bug: if you asked for a power of two size, it'd give you a fifo that could hold one less than what you asked for rather than allocating a buffer twice as big. Signed-off-by: Kent Overstreet Tested-by: Eric Wheeler Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 472ea0f4001a7e1a70d1063dd2cf2831949c325b Author: Eric Wheeler Date: Fri Jun 17 15:01:54 2016 -0700 bcache: register_bcache(): call blkdev_put() when cache_alloc() fails [ Upstream commit d9dc1702b297ec4a6bb9c0326a70641b322ba886 ] register_cache() is supposed to return an error string on error so that register_bcache() will will blkdev_put and cleanup other user counters, but it does not set 'char *err' when cache_alloc() fails (eg, due to memory pressure) and thus register_bcache() performs no cleanup. register_bcache() <----------\ <- no jump to err_close, no blkdev_put() | | +->register_cache() | <- fails to set char *err | | +->cache_alloc() ---/ <- returns error This patch sets `char *err` for this failure case so that register_cache() will cause register_bcache() to correctly jump to err_close and do cleanup. This was tested under OOM conditions that triggered the bug. Signed-off-by: Eric Wheeler Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d1d55bb795bef7ebe88869a30c476351cb0c4b55 Author: Christian König Date: Thu Aug 18 11:51:14 2016 +0200 drm/radeon: only apply the SS fractional workaround to RS[78]80 [ Upstream commit ae5b80d2b68eac945b124227dea34462118a6f01 ] Looks like some RV6xx have problems with that. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97099 Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ffdb240a4379c1689af986a16c65dfac5d17aeb7 Author: Christian König Date: Mon Jun 13 16:09:53 2016 +0200 drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled [ Upstream commit 9ef8537e68941d858924a3eacee5a1945767cbab ] Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven for working a lot with the PLLs and figuring this out. Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f98192b6c8ef31995f9dfaa9089a09ac0cbf8c88 Author: Oleg Nesterov Date: Wed Aug 17 17:36:29 2016 +0200 uprobes: Fix the memcg accounting [ Upstream commit 6c4687cc17a788a6dd8de3e27dbeabb7cbd3e066 ] __replace_page() wronlgy calls mem_cgroup_cancel_charge() in "success" path, it should only do this if page_check_address() fails. This means that every enable/disable leads to unbalanced mem_cgroup_uncharge() from put_page(old_page), it is trivial to underflow the page_counter->count and trigger OOM. Reported-and-tested-by: Brenden Blanco Signed-off-by: Oleg Nesterov Reviewed-by: Johannes Weiner Acked-by: Michal Hocko Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vladimir Davydov Cc: stable@vger.kernel.org # 3.17+ Fixes: 00501b531c47 ("mm: memcontrol: rewrite charge API") Link: http://lkml.kernel.org/r/20160817153629.GB29724@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit cc2082d16b1dd1df4f10c56ad98cb266064799a5 Author: Sasha Levin Date: Tue Aug 30 22:04:29 2016 -0400 ARC: Elide redundant setup of DMA callbacks [ Upstream commit 45c3b08a117e2232fc8d7b9e849ead36386f4f96 ] For resources shared by all cores such as SLC and IOC, only the master core needs to do any setups / enabling / disabling etc. Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 63998a4d6d38779daef8062a8f8755e22b50cc22 Author: Sasha Levin Date: Tue Aug 30 21:59:56 2016 -0400 ARC: Call trace_hardirqs_on() before enabling irqs [ Upstream commit 18b43e89d295cc65151c505c643c98fb2c320e59 ] trace_hardirqs_on_caller() in lockdep.c expects to be called before, not after interrupts are actually enabled. The following comment in kernel/locking/lockdep.c substantiates this claim: " /* * We're enabling irqs and according to our state above irqs weren't * already enabled, yet we find the hardware thinks they are in fact * enabled.. someone messed up their IRQ state tracing. */ " An example can be found in include/linux/irqflags.h: do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0) Without this change, we hit the following DEBUG_LOCKS_WARN_ON. [ 7.760000] ------------[ cut here ]------------ [ 7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0 [ 7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [ 7.780000] Modules linked in: [ 7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366 [ 7.790000] [ 7.790000] Stack Trace: [ 7.790000] arc_unwind_core.constprop.1+0xa4/0x118 [ 7.800000] warn_slowpath_fmt+0x72/0x158 [ 7.800000] resume_user_mode_begin+0x48/0xf0 [ 7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]--- Signed-off-by: Daniel Mentz Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 8501430be1f898e6dead2170b2e57d73b58598e7 Author: Jim Lin Date: Tue Aug 16 10:18:05 2016 +0300 usb: xhci: Fix panic if disconnect [ Upstream commit 88716a93766b8f095cdef37a8e8f2c93aa233b21 ] After a device is disconnected, xhci_stop_device() will be invoked in xhci_bus_suspend(). Also the "disconnect" IRQ will have ISR to invoke xhci_free_virt_device() in this sequence. xhci_irq -> xhci_handle_event -> handle_cmd_completion -> xhci_handle_cmd_disable_slot -> xhci_free_virt_device If xhci->devs[slot_id] has been assigned to NULL in xhci_free_virt_device(), then virt_dev->eps[i].ring in xhci_stop_device() may point to an invlid address to cause kernel panic. virt_dev = xhci->devs[slot_id]; : if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) [] Unable to handle kernel paging request at virtual address 00001a68 [] pgd=ffffffc001430000 [] [00001a68] *pgd=000000013c807003, *pud=000000013c807003, *pmd=000000013c808003, *pte=0000000000000000 [] Internal error: Oops: 96000006 [#1] PREEMPT SMP [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U [] Workqueue: pm pm_runtime_work [] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti: ffffffc0bc0ec000 [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4 This issue is found when running with realtek ethernet device (0bda:8153). Signed-off-by: Jim Lin Cc: Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d7fb5c3789e6b3f7d02b2b26e559b043c970ed91 Author: Mathias Nyman Date: Tue Aug 16 10:18:03 2016 +0300 xhci: always handle "Command Ring Stopped" events [ Upstream commit 33be126510974e2eb9679f1ca9bca4f67ee4c4c7 ] Fix "Command completion event does not match command" errors by always handling the command ring stopped events. The command ring stopped event is generated as a result of aborting or stopping the command ring with a register write. It is not caused by a command in the command queue, and thus won't have a matching command in the comman list. Solve it by handling the command ring stopped event before checking for a matching command. In most command time out cases we abort the command ring, and get a command ring stopped event. The events command pointer will point at the current command ring dequeue, which in most cases matches the timed out command in the command list, and no error messages are seen. If we instead get a command aborted event before the command ring stopped event, the abort event will increse the command ring dequeue pointer, and the following command ring stopped events command pointer will point at the next, not yet queued command. This case triggered the error message Signed-off-by: Mathias Nyman CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc29c0338e43ebf3dfd2e625ed0381e4372db3dc Author: Gavin Li Date: Fri Aug 12 00:52:56 2016 -0700 cdc-acm: fix wrong pipe type on rx interrupt xfers [ Upstream commit add125054b8727103631dce116361668436ef6a7 ] This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb(). Signed-off-by: Gavin Li Acked-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 868f1a4895358fbdbe550f37a6cb98a1aae1885b Author: Lu Baolu Date: Thu Aug 11 10:31:14 2016 +0800 usb: misc: usbtest: add fix for driver hang [ Upstream commit 539587511835ea12d8daa444cbed766cf2bc3612 ] In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling into usb_sg_cancel(). usb_sg_cancel() will do nothing and return directly if req->status has been set to a non-zero value. This will cause driver hang whenever transfer time out is triggered. This patch fixes this issue. It could be backported to stable kernel with version later than v3.15. Cc: stable@vger.kernel.org # 3.15+ Cc: Alan Stern Signed-off-by: Lu Baolu Suggested-by: Alan Stern Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4b72a58f22b7fb0ce6b4c4c211089c7a6def99c5 Author: Matthew Auld Date: Fri Aug 5 19:04:40 2016 +0100 drm/i915: fix aliasing_ppgtt leak [ Upstream commit 3871f42a57efcdc6a9da751a8cb6fa196c212289 ] In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This fixes the following kmemleak message: unreferenced object 0xffff880213cca000 (size 8192): comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc_trace+0x142/0x1d0 [] i915_gem_init_ggtt+0x10f/0x210 [i915] [] i915_gem_init+0x5b/0xd0 [i915] [] i915_driver_load+0x97a/0x1460 [i915] [] i915_pci_probe+0x4f/0x70 [i915] [] local_pci_probe+0x45/0xa0 [] pci_device_probe+0x103/0x150 [] driver_probe_device+0x22c/0x440 [] __driver_attach+0xd1/0xf0 [] bus_for_each_dev+0x6c/0xc0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1c3/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x4c/0x50 [] 0xffffffffa013605b Signed-off-by: Matthew Auld Reviewed-by: Chris Wilson Fixes: b18b6bde300e ("drm/i915/bdw: Free PPGTT struct") Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470420280-21417-1-git-send-email-matthew.auld@intel.com (cherry picked from commit cb7f27601c81a1e0454e9461e96f65b31fafbea0) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 1bc6efe066926ad0f3e76d3bd109162cac3f0c3e Author: Felipe Balbi Date: Wed Aug 10 12:35:30 2016 +0300 usb: dwc3: gadget: always cleanup all TRBs [ Upstream commit 7c705dfe2ebe731c8fd068623b6b4df2d3512c08 ] If we stop earlier due to short packet, we will not be able to giveback all TRBs. Cc: Cc: Brian E Rogers Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit de72ed191825536e27049f353526d7977f4995dc Author: Felipe Balbi Date: Wed Aug 10 11:13:26 2016 +0300 usb: dwc3: gadget: fix for short pkts during chained xfers [ Upstream commit e5b36ae2f851024d43c76e51f395d32ce8d769ce ] DWC3 has one interesting peculiarity with chained transfers. If we setup N chained transfers and we get a short packet before processing all N TRBs, DWC3 will (conditionally) issue a XferComplete or XferInProgress event and retire all TRBs from the one which got a short packet to the last without clearing their HWO bits. This means SW must clear HWO bit manually, which this patch is doing. Cc: Cc: Brian E Rogers Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9bf46c6c417470a5072e2529c634a80ff2e9a890 Author: Felipe Balbi Date: Fri Jul 29 03:17:58 2016 +0300 usb: dwc3: gadget: increment request->actual once [ Upstream commit c7de573471832dff7d31f0c13b0f143d6f017799 ] When using SG lists, we would end up setting request->actual to: num_mapped_sgs * (request->length - count) Let's fix that up by incrementing request->actual only once. Cc: Reported-by: Brian E Rogers Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit c68f2d5722f7d77a28b2c26545e753a50eabebfd Author: Stefan Haberland Date: Mon Aug 8 14:08:17 2016 +0200 s390/dasd: fix hanging device after clear subchannel [ Upstream commit 9ba333dc55cbb9523553df973adb3024d223e905 ] When a device is in a status where CIO has killed all I/O by itself the interrupt for a clear request may not contain an irb to determine the clear function. Instead it contains an error pointer -EIO. This was ignored by the DASD int_handler leading to a hanging device waiting for a clear interrupt. Handle -EIO error pointer correctly for requests that are clear pending and treat the clear as successful. Signed-off-by: Stefan Haberland Reviewed-by: Sebastian Ott Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 64a45a08814a6b1c2ce563b60cd5896fdbbb596c Author: Viresh Kumar Date: Thu Aug 4 13:32:22 2016 -0700 usb: hub: Fix unbalanced reference count/memory leak/deadlocks [ Upstream commit 6bb47e8ab98accb1319bd43c64966340ba3bba9a ] Memory leak and unbalanced reference count: If the hub gets disconnected while the core is still activating it, this can result in leaking memory of few USB structures. This will happen if we have done a kref_get() from hub_activate() and scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect() gets called before the delayed work expires, then we will cancel the work from hub_quiesce(), but wouldn't do a kref_put(). And so the unbalance. kmemleak reports this as (with the commit e50293ef9775 backported to 3.10 kernel with other changes, though the same is true for mainline as well): unreferenced object 0xffffffc08af5b800 (size 1024): comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s) hex dump (first 32 bytes): 30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff 0h.............. 01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff ..........}@.... backtrace: [] create_object+0x148/0x2a0 [] kmemleak_alloc+0x80/0xbc [] kmem_cache_alloc_trace+0x120/0x1ac [] hub_probe+0x120/0xb84 [] usb_probe_interface+0x1ec/0x298 [] driver_probe_device+0x160/0x374 [] __device_attach+0x28/0x4c [] bus_for_each_drv+0x78/0xac [] device_attach+0x6c/0x9c [] bus_probe_device+0x28/0xa0 [] device_add+0x324/0x604 [] usb_set_configuration+0x660/0x6cc [] generic_probe+0x44/0x84 [] usb_probe_device+0x54/0x74 [] driver_probe_device+0x160/0x374 [] __device_attach+0x28/0x4c Deadlocks: If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are finished and the init_work is still queued), the core may call hub_quiesce() after acquiring interface device locks and it will wait for the work to be cancelled synchronously. But if the work handler is already running in parallel, it may try to acquire the same interface device lock and this may result in deadlock. Fix both the issues by removing the call to cancel_delayed_work_sync(). CC: #4.4+ Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()") Reported-by: Manu Gautam Signed-off-by: Viresh Kumar Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b7da50c8fca4e0033abce679e78199dbe09a1e8d Author: Russell King Date: Tue Aug 9 08:27:17 2016 +0100 crypto: caam - fix non-hmac hashes [ Upstream commit a0118c8b2be9297aed8e915c60b4013326b256d4 ] Since 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)"), the AF_ALG interface requires userspace to provide a key to any algorithm that has a setkey method. However, the non-HMAC algorithms are not keyed, so setting a key is unnecessary. Fix this by removing the setkey method from the non-keyed hash algorithms. Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)") Cc: Signed-off-by: Russell King Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 30c2bbd8a7b7ff3b6849d6ce1a69d4db9e40183b Author: Dave Carroll Date: Fri Aug 5 13:44:10 2016 -0600 aacraid: Check size values after double-fetch from user [ Upstream commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 ] In aacraid's ioctl_send_fib() we do two fetches from userspace, one the get the fib header's size and one for the fib itself. Later we use the size field from the second fetch to further process the fib. If for some reason the size from the second fetch is different than from the first fix, we may encounter an out-of- bounds access in aac_fib_send(). We also check the sender size to insure it is not out of bounds. This was reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was assigned CVE-2016-6480. Reported-by: Pengfei Wang Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)' Cc: stable@vger.kernel.org Signed-off-by: Dave Carroll Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8b0f82fcce12161ce459e5a0de455eb4ef39b416 Author: Alexey Klimov Date: Mon Aug 8 02:34:46 2016 +0100 USB: serial: fix memleak in driver-registration error path [ Upstream commit 647024a7df36014bbc4479d92d88e6b77c0afcf6 ] udriver struct allocated by kzalloc() will not be freed if usb_register() and next calls fail. This patch fixes this by adding one more step with kfree(udriver) in error path. Signed-off-by: Alexey Klimov Acked-by: Alan Stern Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 52b29d10d54785738d998d7d308f6142dfbdf3ed Author: Daniele Palmas Date: Tue Aug 2 11:29:25 2016 +0200 USB: serial: option: add support for Telit LE920A4 [ Upstream commit 01d7956b58e644ea0d2e8d9340c5727a8fc39d70 ] This patch adds a set of compositions for Telit LE920A4. Compositions in short are: 0x1207: tty + tty 0x1208: tty + adb + tty + tty 0x1211: tty + adb + ecm 0x1212: tty + adb 0x1213: ecm + tty 0x1214: tty + adb + ecm + tty telit_le922_blacklist_usbcfg3 is reused for compositions 0x1211 and 0x1214 due to the same interfaces positions. Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 1fceecb5b1a77c9d07ece73e5e460d887d481cb6 Author: Sheng-Hui J. Chu Date: Thu Jul 28 17:01:45 2016 -0400 USB: serial: ftdi_sio: add device ID for WICED USB UART dev board [ Upstream commit ae34d12cc1e212ffcd92e069030e54dae69c832f ] BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO IC. To support BCM920706V2_EVAL dev board for WICED development on Linux. Add the VID(0a5c) and PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board. Signed-off-by: Sheng-Hui J. Chu Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit b8d74e57e78477401543cef004ba4ed5f44c6d50 Author: Robert Deliën Date: Thu Jul 28 18:52:55 2016 +0000 USB: serial: ftdi_sio: add PIDs for Ivium Technologies devices [ Upstream commit 6977495c06f7f47636a076ee5a0ca571279d9697 ] Ivium Technologies uses the FTDI VID with custom PIDs for their line of electrochemical interfaces and the PalmSens they developed for PalmSens BV. Signed-off-by: Robert Delien Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit a1ad7ce38ad213424e1b79b509b9116807786323 Author: Lubomir Rintel Date: Sun Jul 24 13:53:30 2016 +0200 USB: serial: option: add D-Link DWM-156/A3 [ Upstream commit cf1b18030de29e4e5b0a57695ae5db4a89da0ff7 ] The device has four interfaces; the three serial ports ought to be handled by this driver: 00 Diagnostic interface serial port 01 NMEA device serial port 02 Mass storage (sd card) 03 Modem serial port The other product ids listed in the Windows driver are present already. Signed-off-by: Lubomir Rintel Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 2e46bd052ad18a769a8f28e8df3968bc7914ac74 Author: Felix Fietkau Date: Tue Aug 2 11:13:41 2016 +0200 mac80211: fix purging multicast PS buffer queue [ Upstream commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 ] The code currently assumes that buffered multicast PS frames don't have a pending ACK frame for tx status reporting. However, hostapd sends a broadcast deauth frame on teardown for which tx status is requested. This can lead to the "Have pending ack frames" warning on module reload. Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0efba8d124de904db7766645561a6f39c501f2c1 Author: Eric Dumazet Date: Sun Jul 10 10:04:02 2016 +0200 tcp: make challenge acks less predictable [ Upstream commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 ] Yue Cao claims that current host rate limiting of challenge ACKS (RFC 5961) could leak enough information to allow a patient attacker to hijack TCP sessions. He will soon provide details in an academic paper. This patch increases the default limit from 100 to 1000, and adds some randomization so that the attacker can no longer hijack sessions without spending a considerable amount of probes. Based on initial analysis and patch from Linus. Note that we also have per socket rate limiting, so it is tempting to remove the host limit in the future. v2: randomize the count of challenge acks per second, not the period. Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") Reported-by: Yue Cao Signed-off-by: Eric Dumazet Suggested-by: Linus Torvalds Cc: Yuchung Cheng Cc: Neal Cardwell Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 399a4563ca9034340ba04e237d5631c8deda66f4 Author: Andrew Donnellan Date: Fri Oct 23 17:19:46 2015 +1100 powerpc/eeh: eeh_pci_enable(): fix checking of post-request state [ Upstream commit 949e9b827eb4736d96df520c67d07a54c64e99b8 ] In eeh_pci_enable(), after making the request to set the new options, we call eeh_ops->wait_state() to check that the request finished successfully. At the moment, if eeh_ops->wait_state() returns 0, we return 0 without checking that it reflects the expected outcome. This can lead to callers further up the chain incorrectly assuming the slot has been successfully unfrozen and continuing to attempt recovery. On powernv, this will occur if pnv_eeh_get_pe_state() or pnv_eeh_get_phb_state() return 0, which in turn occurs if the relevant OPAL call returns OPAL_EEH_STOPPED_MMIO_DMA_FREEZE or OPAL_EEH_PHB_ERROR respectively. On pseries, this will occur if pseries_eeh_get_state() returns 0, which in turn occurs if RTAS reports that the PE is in the MMIO Stopped and DMA Stopped states. Obviously, none of these cases represent a successful completion of a request to thaw MMIO or DMA. Fix the check so that a wait_state() return value of 0 won't be considered successful for the EEH_OPT_THAW_MMIO or EEH_OPT_THAW_DMA cases. Signed-off-by: Andrew Donnellan Acked-by: Gavin Shan Reviewed-by: Daniel Axtens Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin