commit 6c21842b5fc16346a34e81101aff3c224e62bdb5 Author: Greg Kroah-Hartman Date: Sat Sep 24 10:10:18 2016 +0200 Linux 4.7.5 commit 352906f9f3f6cd44b356c2be9f924612cb81f79c Author: Guenter Roeck Date: Sat Sep 17 12:57:24 2016 -0700 openrisc: fix the fix of copy_from_user() commit 8e4b72054f554967827e18be1de0e8122e6efc04 upstream. Since commit acb2505d0119 ("openrisc: fix copy_from_user()"), copy_from_user() returns the number of bytes requested, not the number of bytes not copied. Cc: Al Viro Fixes: acb2505d0119 ("openrisc: fix copy_from_user()") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d48163c414c9fa0c46aaae41b929ba98524d2fb5 Author: Guenter Roeck Date: Sat Sep 17 07:52:49 2016 -0700 avr32: fix 'undefined reference to `___copy_from_user' commit 65c0044ca8d7c7bbccae37f0ff2972f0210e9f41 upstream. avr32 builds fail with: arch/avr32/kernel/built-in.o: In function `arch_ptrace': (.text+0x650): undefined reference to `___copy_from_user' arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_doulongvec_ms_jiffies_minmax': (.text+0x5dd8): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_dointvec_minmax_sysadmin': sysctl.c:(.text+0x6174): undefined reference to `___copy_from_user' kernel/built-in.o: In function `ptrace_has_cap': ptrace.c:(.text+0x69c0): undefined reference to `___copy_from_user' kernel/built-in.o:ptrace.c:(.text+0x6b90): more undefined references to `___copy_from_user' follow Fixes: 8630c32275ba ("avr32: fix copy_from_user()") Cc: Al Viro Acked-by: Havard Skinnemoen Acked-by: Hans-Christian Noren Egtvedt Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ea7190945a91e21e08761ae0d6fcec4f6dc89321 Author: Linus Torvalds Date: Wed Jul 27 20:03:31 2016 -0700 Add braces to avoid "ambiguous ‘else’" compiler warnings commit 194dc870a5890e855ecffb30f3b80ba7c88f96d6 upstream. Some of our "for_each_xyz()" macro constructs make gcc unhappy about lack of braces around if-statements inside or outside the loop, because the loop construct itself has a "if-then-else" statement inside of it. The resulting warnings look something like this: drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’: drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses] if (ctx != dev_priv->kernel_context) ^ even if the code itself is fine. Since the warning is fairly easy to avoid by adding a braces around the if-statement near the for_each_xyz() construct, do so, rather than disabling the otherwise potentially useful warning. (The if-then-else statements used in the "for_each_xyz()" constructs are designed to be inherently safe even with no braces, but in this case it's quite understandable that gcc isn't really able to tell that). This finally leaves the standard "allmodconfig" build with just a handful of remaining warnings, so new and valid warnings hopefully will stand out. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7a9d6a281eb203202be17b4288a2adb75ac81f02 Author: Thomas Gleixner Date: Mon Jul 4 15:32:25 2016 +0200 genirq/msi: Fix broken debug output commit 4364e1a29be16b2783c0bcbc263f61236af64281 upstream. virq is not required to be the same for all msi descs. Use the base irq number from the desc in the debug printk. Reported-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 7d05ad5e34adaeffe0a435ddcc98a9b2031d1cc4 Author: Arnd Bergmann Date: Thu May 19 09:58:49 2016 +0200 iwlegacy: avoid warning about missing braces commit 2cce76c3fab410520610a7d2f52faebc3cfcf843 upstream. gcc-6 warns about code in il3945_hw_txq_ctx_free() being somewhat ambiguous: drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] This adds a set of curly braces to avoid the warning. Signed-off-by: Arnd Bergmann Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b25405d92f69c05e2977b861186e83c9cd04f7c0 Author: Al Viro Date: Thu Aug 18 21:31:41 2016 -0400 ia64: copy_from_user() should zero the destination on access_ok() failure commit a5e541f796f17228793694d64b507f5f57db4cd7 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 37d5c69a2cc43f97030b1a5a9c16b162bc6cfdd4 Author: Al Viro Date: Sun Aug 21 19:16:26 2016 -0400 ppc32: fix copy_from_user() commit 224264657b8b228f949b42346e09ed8c90136a8e upstream. should clear on access_ok() failures. Also remove the useless range truncation logics. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 815dce4e98e1d214751537662b5817af339906bf Author: Al Viro Date: Mon Aug 22 00:23:07 2016 -0400 sparc32: fix copy_from_user() commit 917400cecb4b52b5cde5417348322bb9c8272fa6 upstream. Acked-by: David S. Miller Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit be56090aa902e48559089531f3172acfab696fc9 Author: Al Viro Date: Sat Aug 20 16:33:10 2016 -0400 mn10300: copy_from_user() should zero on access_ok() failure... commit ae7cc577ec2a4a6151c9e928fd1f595d953ecef1 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 00f2f319df51dfa3a0c1b7b5136cba0f247e583d Author: Al Viro Date: Sat Aug 20 16:36:36 2016 -0400 nios2: copy_from_user() should zero the tail of destination commit e33d1f6f72cc82fcfc3d1fb20c9e3ad83b1928fa upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 08382338b815a5ca7cdf777c535283dc0206abce Author: Al Viro Date: Sat Aug 20 17:05:21 2016 -0400 openrisc: fix copy_from_user() commit acb2505d0119033a80c85ac8d02dccae41271667 upstream. ... that should zero on faults. Also remove the helpful logics wrt range truncation copied from ppc32. Where it had ever been needed only in case of copy_from_user() *and* had not been merged into the mainline until a month after the need had disappeared. A decade before openrisc went into mainline, I might add... Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e3d74efc704b0e05b79c6f0cdc97ea63453e2f8d Author: Al Viro Date: Sat Aug 20 19:03:37 2016 -0400 parisc: fix copy_from_user() commit aace880feea38875fbc919761b77e5732a3659ef upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 462578faf789323dcf73602faed69624f50405a0 Author: Al Viro Date: Thu Aug 18 22:08:20 2016 -0400 metag: copy_from_user() should zero the destination on access_ok() failure commit 8ae95ed4ae5fc7c3391ed668b2014c9e2079533b upstream. Acked-by: James Hogan Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit f79347fedb973dc7e420631f9506c5f26e21395b Author: Al Viro Date: Wed Aug 17 16:02:32 2016 -0400 alpha: fix copy_from_user() commit 2561d309dfd1555e781484af757ed0115035ddb3 upstream. it should clear the destination even when access_ok() fails. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 5ed23652be92fbf1c033bb65428b941b96c365ab Author: Al Viro Date: Wed Aug 17 16:36:37 2016 -0400 asm-generic: make copy_from_user() zero the destination properly commit 2545e5da080b4839dd859e3b09343a884f6ab0e3 upstream. ... in all cases, including the failing access_ok() Note that some architectures using asm-generic/uaccess.h have __copy_from_user() not zeroing the tail on failure halfway through. This variant works either way. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b05faef93808bf2f28cc855e40b82af2368a7df6 Author: Al Viro Date: Sat Aug 20 16:18:53 2016 -0400 mips: copy_from_user() must zero the destination on access_ok() failure commit e69d700535ac43a18032b3c399c69bf4639e89a2 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 4777b47e7b19a71fec1daa92bafa0857d7404e14 Author: Al Viro Date: Thu Aug 18 21:16:49 2016 -0400 hexagon: fix strncpy_from_user() error return commit f35c1e0671728d1c9abc405d05ef548b5fcb2fc4 upstream. It's -EFAULT, not -1 (and contrary to the comment in there, __strnlen_user() can return 0 - on faults). Acked-by: Richard Kuo Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit c0fd2000f763cded915a196a78668db9991a124c Author: Pan Xinhui Date: Wed Apr 20 14:41:00 2016 +0800 sh: cmpxchg: fix a bit shift bug in big_endian os commit ff18143ceed3424b7d6cdb8659b9692fa734f0d8 upstream. Correct bitoff in big endian OS. Current code works correctly for 1 byte but not for 2 bytes. Fixes: 3226aad81aa6 ("sh: support 1 and 2 byte xchg") Signed-off-by: Pan Xinhui Acked-by: Michael S. Tsirkin Signed-off-by: Rich Felker Signed-off-by: Greg Kroah-Hartman commit b93b47fdce1b846981c0cf1c186226c21630fcd9 Author: Al Viro Date: Sun Aug 21 23:39:47 2016 -0400 sh: fix copy_from_user() commit 6e050503a150b2126620c1a1e9b3a368fcd51eac upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit ed4024b19a6aab26285936e3bcc29b62bd4e8a0c Author: Al Viro Date: Sun Aug 21 22:30:44 2016 -0400 score: fix copy_from_user() and friends commit b615e3c74621e06cd97f86373ca90d43d6d998aa upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 02045148f920433fdbd051355b2717c91844803b Author: Al Viro Date: Fri Sep 9 19:16:58 2016 -0400 blackfin: fix copy_from_user() commit 8f035983dd826d7e04f67b28acf8e2f08c347e41 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit d5207fc0ff7df9486bc4ee228dd1f2231b9b1bac Author: Al Viro Date: Thu Aug 18 19:34:00 2016 -0400 cris: buggered copy_from_user/copy_to_user/clear_user commit eb47e0293baaa3044022059f1fa9ff474bfe35cb upstream. * copy_from_user() on access_ok() failure ought to zero the destination * none of those primitives should skip the access_ok() check in case of small constant size. Acked-by: Jesper Nilsson Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 78df565f510e5f3216d4186f290315d189b0244b Author: Al Viro Date: Thu Aug 18 20:54:02 2016 -0400 frv: fix clear_user() commit 3b8767a8f00cc6538ba6b1cf0f88502e2fd2eb90 upstream. It should check access_ok(). Otherwise a bunch of places turn into trivially exploitable rootholes. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit cf4c19264e9b9c01b9d57fdc859f0e9aa5d138a5 Author: Al Viro Date: Wed Aug 17 23:19:01 2016 -0400 asm-generic: make get_user() clear the destination on errors commit 9ad18b75c2f6e4a78ce204e79f37781f8815c0fa upstream. both for access_ok() failures and for faults halfway through Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 42526dffda06eb2d8d4239f8cabd9fb09f84c9f2 Author: Vineet Gupta Date: Fri Aug 19 12:10:02 2016 -0700 ARC: uaccess: get_user to zero out dest in cause of fault commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream. Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by: Al Viro Cc: Linus Torvalds Cc: linux-snps-arc@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 14d0188cc29e55f298ae9f8b91105f8b4b01e886 Author: Al Viro Date: Sun Aug 21 22:00:54 2016 -0400 s390: get_user() should zero on failure commit fd2d2b191fe75825c4c7a6f12f3fef35aaed7dd7 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b1689ffd1ce1463c42aec0f7c5d704b7bfc5aaf5 Author: Al Viro Date: Sun Aug 21 22:13:39 2016 -0400 score: fix __get_user/get_user commit c2f18fa4cbb3ad92e033a24efa27583978ce9600 upstream. * should zero on any failure * __get_user() should use __copy_from_user(), not copy_from_user() Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 90ad0e49614ea694c9e9e97d90c9687435f08d82 Author: Al Viro Date: Sat Aug 20 16:39:01 2016 -0400 nios2: fix __get_user() commit 2e29f50ad5e23db37dde9be71410d95d50241ecd upstream. a) should not leave crap on fault b) should _not_ require access_ok() in any cases. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b668ad807ae644d287649d1d16772d12e92fba99 Author: Al Viro Date: Sun Aug 21 23:33:47 2016 -0400 sh64: failing __get_user() should zero commit c6852389228df9fb3067f94f3b651de2a7921b36 upstream. It could be done in exception-handling bits in __get_user_b() et.al., but the surgery involved would take more knowledge of sh64 details than I have or _want_ to have. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 4fe20bdfeb7dc828633fcb49ac0faef5350fbe8c Author: Al Viro Date: Fri Sep 9 19:20:13 2016 -0400 m32r: fix __get_user() commit c90a3bc5061d57e7931a9b7ad14784e1a0ed497d upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 08f3fa74dccfed4dde79e8cb26988a2bc94e5931 Author: Al Viro Date: Sat Aug 20 16:32:02 2016 -0400 mn10300: failing __get_user() and get_user() should zero commit 43403eabf558d2800b429cd886e996fd555aa542 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 7642cc2430ba942c773f3faef8f913bcbd363311 Author: Al Viro Date: Thu Sep 15 02:35:29 2016 +0100 fix minor infoleak in get_user_ex() commit 1c109fabbd51863475cd12ac206bdd249aee35af upstream. get_user_ex(x, ptr) should zero x on failure. It's not a lot of a leak (at most we are leaking uninitialized 64bit value off the kernel stack, and in a fairly constrained situation, at that), but the fix is trivial, so... Signed-off-by: Al Viro [ This sat in different branch from the uaccess fixes since mid-August ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 970509fa0ba67f00b984b54d15d35d25824fe912 Author: Al Viro Date: Fri Sep 9 19:22:34 2016 -0400 microblaze: fix copy_from_user() commit d0cf385160c12abd109746cad1f13e3b3e8b50b8 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit d4b8c2e5a2a5b0d9cf6cbd45c380641ee784b011 Author: Al Viro Date: Fri Sep 9 19:28:23 2016 -0400 avr32: fix copy_from_user() commit 8630c32275bac2de6ffb8aea9d9b11663e7ad28e upstream. really ugly, but apparently avr32 compilers turns access_ok() into something so bad that they want it in assembler. Left that way, zeroing added in inline wrapper. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 42e3ee6d94fadc28c5a9ff63bc3eed683e1efe03 Author: Al Viro Date: Fri Sep 9 19:23:33 2016 -0400 microblaze: fix __get_user() commit e98b9e37ae04562d52c96f46b3cf4c2e80222dc1 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e136ec8c23d1454638d7ca872872b60803e5d25c Author: Al Viro Date: Fri Sep 16 00:11:45 2016 +0100 fix iov_iter_fault_in_readable() commit d4690f1e1cdabb4d61207b6787b1605a0dc0aeab upstream. ... by turning it into what used to be multipages counterpart Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aebedc954eeef89e29074b242342222600c16705 Author: Boris Brezillon Date: Tue Sep 13 15:58:29 2016 +0200 irqchip/atmel-aic: Fix potential deadlock in ->xlate() commit 5eb0d6eb3fac3daa60d9190eed9fa41cf809c756 upstream. aic5_irq_domain_xlate() and aic_irq_domain_xlate() take the generic chip lock without disabling interrupts, which can lead to a deadlock if an interrupt occurs while the lock is held in one of these functions. Replace irq_gc_{lock,unlock}() calls by irq_gc_{lock_irqsave,unlock_irqrestore}() ones to prevent this bug from happening. Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers") Signed-off-by: Boris Brezillon Acked-by: Marc Zyngier Cc: Jason Cooper Cc: Nicolas Ferre Cc: Alexandre Belloni Link: http://lkml.kernel.org/r/1473775109-4192-2-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 18f894d54e0689db89ec93a766fb3afc73d496c0 Author: Boris Brezillon Date: Tue Sep 13 15:58:28 2016 +0200 genirq: Provide irq_gc_{lock_irqsave,unlock_irqrestore}() helpers commit ebf9ff753c041b296241990aef76163bbb2cc9c8 upstream. Some irqchip drivers need to take the generic chip lock outside of the irq context. Provide the irq_gc_{lock_irqsave,unlock_irqrestore}() helpers to allow one to disable irqs while entering a critical section protected by gc->lock. Note that we do not provide optimized version of these helpers for !SMP, because they are not called from the hot-path. [ tglx: Added a comment when these helpers should be [not] used ] Signed-off-by: Boris Brezillon Cc: Jason Cooper Cc: Marc Zyngier Cc: Nicolas Ferre Cc: Alexandre Belloni Link: http://lkml.kernel.org/r/1473775109-4192-1-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ad85b7cac3a550c34e8386c36758a33a96e3b280 Author: Lee Jones Date: Thu Sep 8 11:11:36 2016 +0200 mmc: sdhci-st: Handle interconnect clock commit 3ae50f4512ce831e8b63eb54ad969417ff30ada7 upstream. Some ST platforms contain interconnect (ICN) clocks which must be handed correctly in order to obtain full functionality of a given IP. In this case, if the ICN clocks are not handled properly by the ST SDHCI driver MMC will break and the following output can be observed: [ 13.916949] mmc0: Timeout waiting for hardware interrupt. [ 13.922349] sdhci: =========== REGISTER DUMP (mmc0)=========== [ 13.928175] sdhci: Sys addr: 0x00000000 | Version: 0x00001002 [ 13.933999] sdhci: Blk size: 0x00007040 | Blk cnt: 0x00000001 [ 13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013 [ 13.945650] sdhci: Present: 0x1fff0206 | Host ctl: 0x00000011 [ 13.951475] sdhci: Power: 0x0000000f | Blk gap: 0x00000080 [ 13.957300] sdhci: Wake-up: 0x00000000 | Clock: 0x00003f07 [ 13.963126] sdhci: Timeout: 0x00000004 | Int stat: 0x00000000 [ 13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b [ 13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000 [ 13.980602] sdhci: Caps: 0x21ed3281 | Caps_1: 0x00000000 [ 13.986428] sdhci: Cmd: 0x0000063a | Max curr: 0x00000000 [ 13.992252] sdhci: Host ctl2: 0x00000000 [ 13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200 [ 14.001990] sdhci: =========================================== [ 14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress. A decent point was raised about minimising the use of a local variable that we 'could' do without. I've chosen consistency over the possibility of reducing the local variable count by 1. Thinking that it's more important for the code to be grouped and authoured in a similar manner/style for greater maintainability/readability. Tested-by: Peter Griffin Signed-off-by: Lee Jones Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 34479ea67ef52e5efbe2af24ef88b2b393aa48fd Author: Chuck Lever Date: Thu Sep 1 10:50:38 2016 -0400 svcauth_gss: Revert 64c59a3726f2 ("Remove unnecessary allocation") commit bf2c4b6f9b74c2ee1dd3c050b181e9b9c86fbcdb upstream. rsc_lookup steals the passed-in memory to avoid doing an allocation of its own, so we can't just pass in a pointer to memory that someone else is using. If we really want to avoid allocation there then maybe we should preallocate somwhere, or reference count these handles. For now we should revert. On occasion I see this on my server: kernel: kernel BUG at /home/cel/src/linux/linux-2.6/mm/slub.c:3851! kernel: invalid opcode: 0000 [#1] SMP kernel: Modules linked in: cts rpcsec_gss_krb5 sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd btrfs xor iTCO_wdt iTCO_vendor_support raid6_pq pcspkr i2c_i801 i2c_smbus lpc_ich mfd_core mei_me sg mei shpchp wmi ioatdma ipmi_si ipmi_msghandler acpi_pad acpi_power_meter rpcrdma ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm nfsd nfs_acl lockd grace auth_rpcgss sunrpc ip_tables xfs libcrc32c mlx4_ib mlx4_en ib_core sr_mod cdrom sd_mod ast drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel igb mlx4_core ahci libahci libata ptp pps_core dca i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod kernel: CPU: 7 PID: 145 Comm: kworker/7:2 Not tainted 4.8.0-rc4-00006-g9d06b0b #15 kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015 kernel: Workqueue: events do_cache_clean [sunrpc] kernel: task: ffff8808541d8000 task.stack: ffff880854344000 kernel: RIP: 0010:[] [] kfree+0x155/0x180 kernel: RSP: 0018:ffff880854347d70 EFLAGS: 00010246 kernel: RAX: ffffea0020fe7660 RBX: ffff88083f9db064 RCX: 146ff0f9d5ec5600 kernel: RDX: 000077ff80000000 RSI: ffff880853f01500 RDI: ffff88083f9db064 kernel: RBP: ffff880854347d88 R08: ffff8808594ee000 R09: ffff88087fdd8780 kernel: R10: 0000000000000000 R11: ffffea0020fe76c0 R12: ffff880853f01500 kernel: R13: ffffffffa013cf76 R14: ffffffffa013cff0 R15: ffffffffa04253a0 kernel: FS: 0000000000000000(0000) GS:ffff88087fdc0000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00007fed60b020c3 CR3: 0000000001c06000 CR4: 00000000001406e0 kernel: Stack: kernel: ffff8808589f2f00 ffff880853f01500 0000000000000001 ffff880854347da0 kernel: ffffffffa013cf76 ffff8808589f2f00 ffff880854347db8 ffffffffa013d006 kernel: ffff8808589f2f20 ffff880854347e00 ffffffffa0406f60 0000000057c7044f kernel: Call Trace: kernel: [] rsc_free+0x16/0x90 [auth_rpcgss] kernel: [] rsc_put+0x16/0x30 [auth_rpcgss] kernel: [] cache_clean+0x2e0/0x300 [sunrpc] kernel: [] do_cache_clean+0xe/0x70 [sunrpc] kernel: [] process_one_work+0x1ff/0x3b0 kernel: [] worker_thread+0x2bc/0x4a0 kernel: [] ? rescuer_thread+0x3a0/0x3a0 kernel: [] kthread+0xe4/0xf0 kernel: [] ret_from_fork+0x1f/0x40 kernel: [] ? kthread_stop+0x110/0x110 kernel: Code: f7 ff ff eb 3b 65 8b 05 da 30 e2 7e 89 c0 48 0f a3 05 a0 38 b8 00 0f 92 c0 84 c0 0f 85 d1 fe ff ff 0f 1f 44 00 00 e9 f5 fe ff ff <0f> 0b 49 8b 03 31 f6 f6 c4 40 0f 85 62 ff ff ff e9 61 ff ff ff kernel: RIP [] kfree+0x155/0x180 kernel: RSP kernel: ---[ end trace 3fdec044969def26 ]--- It seems to be most common after a server reboot where a client has been using a Kerberos mount, and reconnects to continue its workload. Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f65ada9fea3228f21b9a737219bd5c9f4ad796ea Author: Kristian H. Kristensen Date: Tue Sep 13 14:20:45 2016 -0700 drm: Only use compat ioctl for addfb2 on X86/IA64 commit 47a66e45d7a7613322549c2475ea9d809baaf514 upstream. Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an unaligned 64 bit field (modifier). This get packed differently between 32 bit and 64 bit modes on architectures that can handle unaligned 64 bit access (X86 and IA64). Other architectures pack the structs the same and don't need the compat wrapper. Use the same condition for drm_mode_fb_cmd2 as we use for drm_update_draw. Note that only the modifier will be packed differently between compat and non-compat versions. Reviewed-by: Rob Clark Signed-off-by: Kristian H. Kristensen [seanpaul added not at bottom of commit msg re: modifier] Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/1473801645-116011-1-git-send-email-hoegsberg@chromium.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit d18accc4ef53cc91b93384a5227b787a47f321b4 Author: Ville Syrjälä Date: Tue Sep 13 12:22:19 2016 +0300 drm/i915: Ignore OpRegion panel type except on select machines commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 upstream. Turns out commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some specific systems. Despite trying, I was unable to find any automagic way to determine if the OpRegion panel type is respectable or not. The only glimmer of hope I had was bit 8 in the SCIC response, but that turned out to not work either (it was always 0 on both types of systems). So, to fix the regressions without breaking the machine we know to need the OpRegion panel type, let's just add a quirk for this. Only specific machines known to require the OpRegion panel type will therefore use it. Everyone else will fall bck to the VBT panel type. The only known machine so far is a "Conrac GmbH IX45GM2". The PCI subsystem ID on this machine is just a generic 8086:2a42, so of no use. Instead we'll go with a DMI match. I suspect we can now also revert commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL") but let's leave that to a separate patch. v2: Do the DMI match in the opregion code directly, as dev_priv->quirks gets populated too late Cc: Rob Kramer Cc: Martin van Es Cc: Andrea Arcangeli Cc: Dave Airlie Cc: Marco Krüger Cc: Sean Greenslade Cc: Trudy Tective Cc: Robin Müller Cc: Alexander Kobel Cc: Alexey Shumitsky Cc: Emil Andersen Lauridsen Cc: oceans112@gmail.com Cc: James Hogan Cc: James Bottomley References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") Tested-by: Marco Krüger Tested-by: Alexey Shumitsky Tested-by: Sean Greenslade Tested-by: Emil Andersen Lauridsen Tested-by: Robin Müller Tested-by: oceans112@gmail.com Tested-by: Rob Kramer Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com Acked-by: Jani Nikula (cherry picked from commit c8ebfad7a063fe665417fa0eeb0da7cfe987d8ed) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 7e8396529d598223c67832f012b6c100c006b78d Author: Jan Leupold Date: Wed Jul 6 13:22:35 2016 +0200 drm: atmel-hlcdc: Fix vertical scaling commit d31ed3f05763644840c654a384eaefa94c097ba2 upstream. The code is applying the same scaling for the X and Y components, thus making the scaling feature only functional when both components have the same scaling factor. Do the s/_w/_h/ replacement where appropriate to fix vertical scaling. Signed-off-by: Jan Leupold Fixes: 1a396789f65a2 ("drm: add Atmel HLCDC Display Controller support") Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit f52d52867c0502ab94a470692bfb7cea67567ae9 Author: Arnd Bergmann Date: Thu Sep 1 16:14:47 2016 -0700 kconfig: tinyconfig: provide whole choice blocks to avoid warnings commit 236dec051078a8691950f56949612b4b74107e48 upstream. Using "make tinyconfig" produces a couple of annoying warnings that show up for build test machines all the time: .config:966:warning: override: NOHIGHMEM changes choice state .config:965:warning: override: SLOB changes choice state .config:963:warning: override: KERNEL_XZ changes choice state .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state .config:933:warning: override: SLOB changes choice state .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state .config:870:warning: override: SLOB changes choice state .config:868:warning: override: KERNEL_XZ changes choice state .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state I've made a previous attempt at fixing them and we discussed a number of alternatives. I tried changing the Makefile to use "merge_config.sh -n $(fragment-list)" but couldn't get that to work properly. This is yet another approach, based on the observation that we do want to see a warning for conflicting 'choice' options, and that we can simply make them non-conflicting by listing all other options as disabled. This is a trivial patch that we can apply independent of plans for other changes. Link: http://lkml.kernel.org/r/20160829214952.1334674-2-arnd@arndb.de Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log https://patchwork.kernel.org/patch/9212749/ Signed-off-by: Arnd Bergmann Reviewed-by: Josh Triplett Reviewed-by: Masahiro Yamada Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 63f3f944657af0117509af8967de0483885e8347 Author: Mike Danese Date: Thu May 19 21:54:51 2016 -0700 mpssd: fix buffer overflow warning commit 3610a2add39365a0f153154c60169a66c616d50f upstream. The compilation emits a warning in function ‘snprintf’, inlined from ‘set_cmdline’ at ../Documentation/mic/mpssd/mpssd.c:1541:9: /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: warning: call to __builtin___snprintf_chk will always overflow destination buffer This was introduced in commit f4a66c204482 ("misc: mic: Update MIC host daemon with COSM changes") and is fixed by reverting the changes to the size argument of these snprintf statements. Cc: Ashutosh Dixit Signed-off-by: Mike Danese Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit 63cbe6ea3b9dfaf4761cca70fda448b974ede463 Author: Christophe Leroy Date: Fri Aug 26 16:45:13 2016 +0200 powerpc/32: Fix again csum_partial_copy_generic() commit 8540571e01f973d321b0821f4f32ed6e9ae8263c upstream. Commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic() based on copy_tofrom_user()") introduced a bug when destination address is odd and len is lower than cacheline size. In that case the resulting csum value doesn't have to be rotated one byte because the cache-aligned copy part is skipped so no alignment is performed. Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic() based on copy_tofrom_user()") Cc: stable@vger.kernel.org # v4.6+ Reported-by: Alessio Igor Bogani Signed-off-by: Christophe Leroy Tested-by: Alessio Igor Bogani Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 13c2ad632e69f96e0ab33439745b084d93319522 Author: Christophe Leroy Date: Tue Aug 2 10:07:05 2016 +0200 powerpc/32: Fix csum_partial_copy_generic() commit 1bc8b816cb8058c31f61fe78442f10a43209e582 upstream. Commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic() based on copy_tofrom_user()") introduced a bug when destination address is odd and initial csum is not null In that (rare) case the initial csum value has to be rotated one byte as well as the resulting value is This patch also fixes related comments Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic() based on copy_tofrom_user()") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9a11360e9d25235e2bcf78e3496f0fc354eee1d8 Author: Jeffrey Hugo Date: Mon Aug 29 14:38:54 2016 -0600 x86/efi: Use efi_exit_boot_services() commit d64934019f6cc39202e2f78063709f61ca5cb364 upstream. The eboot code directly calls ExitBootServices. This is inadvisable as the UEFI spec details a complex set of errors, race conditions, and API interactions that the caller of ExitBootServices must get correct. The eboot code attempts allocations after calling ExitBootSerives which is not permitted per the spec. Call the efi_exit_boot_services() helper intead, which handles the allocation scenario properly. Signed-off-by: Jeffrey Hugo Cc: Ard Biesheuvel Cc: Mark Rutland Cc: Leif Lindholm Cc: Ingo Molnar Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 27c307f95addc31607566dff9961f9c55af517f4 Author: Jeffrey Hugo Date: Mon Aug 29 14:38:53 2016 -0600 efi/libstub: Use efi_exit_boot_services() in FDT commit ed9cc156c42ff0c0bf9b1d09df48a12bf0873473 upstream. The FDT code directly calls ExitBootServices. This is inadvisable as the UEFI spec details a complex set of errors, race conditions, and API interactions that the caller of ExitBootServices must get correct. The FDT code does not handle EFI_INVALID_PARAMETER as required by the spec, which causes intermittent boot failures on the Qualcomm Technologies QDF2432. Call the efi_exit_boot_services() helper intead, which handles the EFI_INVALID_PARAMETER scenario properly. Signed-off-by: Jeffrey Hugo Cc: Ard Biesheuvel Cc: Mark Rutland Cc: Leif Lindholm Cc: Ingo Molnar Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 99d1ddb28b60297f7bb30ecb0e5837f00245c9a0 Author: Jeffrey Hugo Date: Mon Aug 29 14:38:52 2016 -0600 efi/libstub: Introduce ExitBootServices helper commit fc07716ba803483be91bc4b2344f9c84985e6f07 upstream. The spec allows ExitBootServices to fail with EFI_INVALID_PARAMETER if a race condition has occurred where the EFI has updated the memory map after the stub grabbed a reference to the map. The spec defines a retry proceedure with specific requirements to handle this scenario. This scenario was previously observed on x86 - commit d3768d885c6c ("x86, efi: retry ExitBootServices() on failure") but the current fix is not spec compliant and the scenario is now observed on the Qualcomm Technologies QDF2432 via the FDT stub which does not handle the error and thus causes boot failures. The user will notice the boot failure as the kernel is not executed and the system may drop back to a UEFI shell, but will be unresponsive to input and the system will require a power cycle to recover. Add a helper to the stub library that correctly adheres to the spec in the case of EFI_INVALID_PARAMETER from ExitBootServices and can be universally used across all stub implementations. Signed-off-by: Jeffrey Hugo Cc: Ard Biesheuvel Cc: Mark Rutland Cc: Leif Lindholm Cc: Ingo Molnar Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 66a3f2155dbe152044e264b9737689b229fa061b Author: Jeffrey Hugo Date: Mon Aug 29 14:38:51 2016 -0600 efi/libstub: Allocate headspace in efi_get_memory_map() commit dadb57abc37499f565b23933dbf49b435c3ba8af upstream. efi_get_memory_map() allocates a buffer to store the memory map that it retrieves. This buffer may need to be reused by the client after ExitBootServices() is called, at which point allocations are not longer permitted. To support this usecase, provide the allocated buffer size back to the client, and allocate some additional headroom to account for any reasonable growth in the map that is likely to happen between the call to efi_get_memory_map() and the client reusing the buffer. Signed-off-by: Jeffrey Hugo Cc: Ard Biesheuvel Cc: Mark Rutland Cc: Leif Lindholm Cc: Ingo Molnar Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 57fea0768c7c7874eeaf59b1ab5011c6cb9251b2 Author: Jan Beulich Date: Mon Aug 15 09:05:45 2016 -0600 efi: Make for_each_efi_memory_desc_in_map() cope with running on Xen commit d4c4fed08f31f3746000c46cb1b20bed2959547a upstream. While commit 55f1ea15216 ("efi: Fix for_each_efi_memory_desc_in_map() for empty memmaps") made an attempt to deal with empty memory maps, it didn't address the case where the map field never gets set, as is apparently the case when running under Xen. Reported-by: Tested-by: Cc: Vitaly Kuznetsov Cc: Jiri Slaby Cc: Mark Rutland Signed-off-by: Jan Beulich [ Guard the loop with a NULL check instead of pointer underflow ] Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit a8529888a4bf3043d5a64de80148fda05c034305 Author: Eli Cooper Date: Fri Aug 26 23:52:29 2016 +0800 ipv6: Don't unset flowi6_proto in ipxip6_tnl_xmit() commit ab34380162cbc9b5172afdadf5136643c687bb73 upstream. Commit 8eb30be0352d0916 ("ipv6: Create ip6_tnl_xmit") unsets flowi6_proto in ip4ip6_tnl_xmit() and ip6ip6_tnl_xmit(). Since xfrm_selector_match() relies on this info, IPv6 packets sent by an ip6tunnel cannot be properly selected by their protocols after removing it. This patch puts flowi6_proto back. Fixes: 8eb30be0352d ("ipv6: Create ip6_tnl_xmit") Signed-off-by: Eli Cooper Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 00f179bf9ca41d436c13246d449d3504512db3c3 Author: Balbir Singh Date: Mon Sep 5 13:16:40 2016 +1000 sched/core: Fix a race between try_to_wake_up() and a woken up task commit 135e8c9250dd5c8c9aae5984fde6f230d0cbfeaf upstream. The origin of the issue I've seen is related to a missing memory barrier between check for task->state and the check for task->on_rq. The task being woken up is already awake from a schedule() and is doing the following: do { schedule() set_current_state(TASK_(UN)INTERRUPTIBLE); } while (!cond); The waker, actually gets stuck doing the following in try_to_wake_up(): while (p->on_cpu) cpu_relax(); Analysis: The instance I've seen involves the following race: CPU1 CPU2 while () { if (cond) break; do { schedule(); set_current_state(TASK_UN..) } while (!cond); wakeup_routine() spin_lock_irqsave(wait_lock) raw_spin_lock_irqsave(wait_lock) wake_up_process() } try_to_wake_up() set_current_state(TASK_RUNNING); .. list_del(&waiter.list); CPU2 wakes up CPU1, but before it can get the wait_lock and set current state to TASK_RUNNING the following occurs: CPU3 wakeup_routine() raw_spin_lock_irqsave(wait_lock) if (!list_empty) wake_up_process() try_to_wake_up() raw_spin_lock_irqsave(p->pi_lock) .. if (p->on_rq && ttwu_wakeup()) .. while (p->on_cpu) cpu_relax() .. CPU3 tries to wake up the task on CPU1 again since it finds it on the wait_queue, CPU1 is spinning on wait_lock, but immediately after CPU2, CPU3 got it. CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and the task is spinning on the wait_lock. Interestingly since p->on_rq is checked under pi_lock, I've noticed that try_to_wake_up() finds p->on_rq to be 0. This was the most confusing bit of the analysis, but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq check is not reliable without this fix IMHO. The race is visible (based on the analysis) only when ttwu_queue() does a remote wakeup via ttwu_queue_remote. In which case the p->on_rq change is not done uder the pi_lock. The result is that after a while the entire system locks up on the raw_spin_irqlock_save(wait_lock) and the holder spins infintely Reproduction of the issue: The issue can be reproduced after a long run on my system with 80 threads and having to tweak available memory to very low and running memory stress-ng mmapfork test. It usually takes a long time to reproduce. I am trying to work on a test case that can reproduce the issue faster, but thats work in progress. I am still testing the changes on my still in a loop and the tests seem OK thus far. Big thanks to Benjamin and Nick for helping debug this as well. Ben helped catch the missing barrier, Nick caught every missing bit in my theory. Signed-off-by: Balbir Singh [ Updated comment to clarify matching barriers. Many architectures do not have a full barrier in switch_to() so that cannot be relied upon. ] Signed-off-by: Peter Zijlstra (Intel) Acked-by: Benjamin Herrenschmidt Cc: Alexey Kardashevskiy Cc: Linus Torvalds Cc: Nicholas Piggin Cc: Nicholas Piggin Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/e02cce7b-d9ca-1ad0-7a61-ea97c7582b37@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f7f1b16b565f01dac50c5d6ab288fbef799a3220 Author: Johannes Berg Date: Mon Aug 8 08:45:33 2016 +0200 Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel" commit 4d0bd46a4d55383f7b925e6cf7865a77e0f0e020 upstream. This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724. Ben Hutchings pointed out that the commit isn't safe since it assumes that the structure used by the driver is iw_point, when in fact there's no way to know about that. Fortunately, the only driver in the tree that ever runs this code path is the wilc1000 staging driver, so it doesn't really matter. Clearly I should have investigated this better before applying, sorry. Reported-by: Ben Hutchings Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 283a243619eaf8db6816bdb1de309d7b98ee048a Author: Alexander Shishkin Date: Thu Sep 15 18:13:52 2016 +0300 perf/x86/intel/pt: Do validate the size of a kernel address filter commit 1155bafcb79208abc6ae234c6e135ac70607755c upstream. Right now, the kernel address filters in PT are prone to integer overflow that may happen in adding filter's size to its offset to obtain the end of the range. Such an overflow would also throw a #GP in the PT event configuration path. Fix this by explicitly validating the result of this calculation. Reported-by: Adrian Hunter Signed-off-by: Alexander Shishkin Acked-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160915151352.21306-4-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4084586079281c092e1e1bf9f7b54a3b853f1ff2 Author: Alexander Shishkin Date: Thu Sep 15 18:13:51 2016 +0300 perf/x86/intel/pt: Fix kernel address filter's offset validation commit ddfdad991e55b65c1cc4ee29502f6dceee04455a upstream. The kernel_ip() filter is used mostly by the DS/LBR code to look at the branch addresses, but Intel PT also uses it to validate the address filter offsets for kernel addresses, for which it is not sufficient: supplying something in bits 64:48 that's not a sign extension of the lower address bits (like 0xf00d000000000000) throws a #GP. This patch adds address validation for the user supplied kernel filters. Reported-by: Adrian Hunter Signed-off-by: Alexander Shishkin Acked-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160915151352.21306-3-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3572314d55d822a557d2aab1142b8bf19eeb60bd Author: Alexander Shishkin Date: Thu Sep 15 18:13:50 2016 +0300 perf/x86/intel/pt: Fix an off-by-one in address filter configuration commit 95f60084acbcee6c466256cf26eb52191fad9edc upstream. PT address filter configuration requires that a range is specified by its first and last address, but at the moment we're obtaining the end of the range by adding user specified size to its start, which is off by one from what it actually needs to be. Fix this and make sure that zero-sized filters don't pass the filter validation. Reported-by: Adrian Hunter Signed-off-by: Alexander Shishkin Acked-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160915151352.21306-2-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6af2dc319f28396610891debfb1eb646ca0c82c6 Author: Matt Fleming Date: Wed Aug 24 14:12:08 2016 +0100 perf/x86/amd: Make HW_CACHE_REFERENCES and HW_CACHE_MISSES measure L2 commit 080fe0b790ad438fc1b61621dac37c1964ce7f35 upstream. While the Intel PMU monitors the LLC when perf enables the HW_CACHE_REFERENCES and HW_CACHE_MISSES events, these events monitor L1 instruction cache fetches (0x0080) and instruction cache misses (0x0081) on the AMD PMU. This is extremely confusing when monitoring the same workload across Intel and AMD machines, since parameters like, $ perf stat -e cache-references,cache-misses measure completely different things. Instead, make the AMD PMU measure instruction/data cache and TLB fill requests to the L2 and instruction/data cache and TLB misses in the L2 when HW_CACHE_REFERENCES and HW_CACHE_MISSES are enabled, respectively. That way the events measure unified caches on both platforms. Signed-off-by: Matt Fleming Acked-by: Peter Zijlstra Cc: Borislav Petkov Cc: Linus Torvalds Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1472044328-21302-1-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ec929acd537f7ed1894d94af539765311a701116 Author: Jiri Olsa Date: Mon Sep 5 17:30:07 2016 +0200 perf/x86/intel/cqm: Check cqm/mbm enabled state in event init commit 79d102cbfd2e9d94257fcc7c82807ef1cdf80322 upstream. Yanqiu Zhang reported kernel panic when using mbm event on system where CQM is detected but without mbm event support, like with perf: # perf stat -e 'intel_cqm/event=3/' -a BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [] update_sample+0xbc/0xe0 ... [] __intel_mbm_event_init+0x18/0x20 [] flush_smp_call_function_queue+0x7b/0x160 [] generic_smp_call_function_single_interrupt+0x13/0x60 [] smp_call_function_interrupt+0x27/0x40 [] call_function_interrupt+0x8c/0xa0 ... The reason is that we currently allow to init mbm event even if mbm support is not detected. Adding checks for both cqm and mbm events and support into cqm's event_init. Fixes: 33c3cc7acfd9 ("perf/x86/mbm: Add Intel Memory B/W Monitoring enumeration and init") Reported-by: Yanqiu Zhang Signed-off-by: Jiri Olsa Acked-by: Peter Zijlstra Cc: Vikas Shivappa Cc: Tony Luck Link: http://lkml.kernel.org/r/1473089407-21857-1-git-send-email-jolsa@kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d6de829d8bf8eafdaa434f20aeb3544c6ecee865 Author: Peter Zijlstra Date: Wed Sep 7 14:42:55 2016 +0200 perf/x86/intel: Fix PEBSv3 record drain commit 8ef9b8455a2a3049efa9e46e8a6402b972a3eb41 upstream. Alexander hit the WARN_ON_ONCE(!event) on his Skylake while running the perf fuzzer. This means the PEBSv3 record included a status bit for an inactive event, something that _should_ not happen. Move the code that filters the status bits against our known PEBS events up a spot to guarantee we only deal with events we know about. Further add "continue" statements to the WARN_ON_ONCE()s such that we'll not die nor generate silly events in case we ever do hit them again. Reported-by: Alexander Shishkin Tested-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Kan Liang Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: a3d86542de88 ("perf/x86/intel/pebs: Add PEBSv3 decoding") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 255b75e2e5f224d1d5ad0130e85d469747254b29 Author: Giedrius Statkevičius Date: Thu Sep 1 20:47:02 2016 +0300 ath9k: bring back direction setting in ath9k_{start_stop} commit e34f2ff40e0339f6a379e1ecf49e8f2759056453 upstream. A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup led_pin initial") that broken the WLAN status led on my laptop with AR9287 after suspending and resuming. Steps to reproduce: * Suspend (laptop) * Resume (laptop) * Observe that the WLAN led no longer turns ON/OFF depending on the status and is always red Even though for my case it only needs to be set to OUT in ath9k_start but for consistency bring back the IN direction setting as well. Fixes: 79d4db1214a0 ("ath9k: cleanup led_pin initial") Cc: Miaoqing Pan Cc: Kalle Valo Link: https://bugzilla.kernel.org/show_bug.cgi?id=151711 Signed-off-by: Giedrius Statkevičius [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 895e861d923f631fed6a0e7abb30a115f1876b04 Author: Felix Fietkau Date: Fri Aug 19 13:37:46 2016 +0300 ath9k: fix using sta->drv_priv before initializing it commit 7711aaf08ad3fc4d0e937eec1de0a63620444ce7 upstream. A station pointer can be passed to the driver on tx, before it has been marked as associated. Since ath9k_sta_state was initializing the entry too late, it resulted in some spurious crashes. Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback") Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 94d9f078ed075b3e68ede1590e36da2774cfa714 Author: Guoqing Jiang Date: Sun Sep 4 22:17:28 2016 -0400 md-cluster: make md-cluster also can work when compiled into kernel commit 47a7b0d8888c04c9746812820b6e60553cc77bbc upstream. The md-cluster is compiled as module by default, if it is compiled by built-in way, then we can't make md-cluster works. [64782.630008] md/raid1:md127: active with 2 out of 2 mirrors [64782.630528] md-cluster module not found. [64782.630530] md127: Could not setup cluster service (-2) Fixes: edb39c9 ("Introduce md_cluster_operations to handle cluster functions") Reported-by: Marc Smith Reviewed-by: NeilBrown Signed-off-by: Guoqing Jiang Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit ecd4c39ec742f764bf9c7c025cc478868af4df34 Author: Arend Van Spriel Date: Mon Sep 5 10:45:47 2016 +0100 brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap() commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream. User-space can choose to omit NL80211_ATTR_SSID and only provide raw IE TLV data. When doing so it can provide SSID IE with length exceeding the allowed size. The driver further processes this IE copying it into a local variable without checking the length. Hence stack can be corrupted and used as exploit. Reported-by: Daxing Guo Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit d1d63fc644f4181e8c181e67a35fba743d282981 Author: Mathias Nyman Date: Wed Sep 7 17:26:33 2016 +0300 xhci: fix null pointer dereference in stop command timeout function commit bcf42aa60c2832510b9be0f30c090bfd35bb172d upstream. The stop endpoint command has its own 5 second timeout timer. If the timeout function is triggered between USB3 and USB2 host removal it will try to call usb_hc_died(xhci_to_hcd(xhci)->primary_hcd) the ->primary_hcd will be set to NULL at USB3 hcd removal. Fix this by first checking if the PCI host is being removed, and also by using only xhci_to_hcd() as it will always return the primary hcd. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 8111453432b3450cb9f97c0e4304c22248d73752 Author: Miklos Szeredi Date: Wed Aug 24 18:17:04 2016 +0200 fuse: direct-io: don't dirty ITER_BVEC pages commit 8fba54aebbdf1f999738121922e74bf796ad60ee upstream. When reading from a loop device backed by a fuse file it deadlocks on lock_page(). This is because the page is already locked by the read() operation done on the loop device. In this case we don't want to either lock the page or dirty it. So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors. Reported-by: Sheng Yang Fixes: aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC") Signed-off-by: Miklos Szeredi Reviewed-by: Sheng Yang Reviewed-by: Ashish Samant Tested-by: Sheng Yang Tested-by: Ashish Samant Signed-off-by: Greg Kroah-Hartman commit d97d64c564a16132dbb797d98bd90d8f191d0f86 Author: Chris Mason Date: Tue Sep 6 05:37:40 2016 -0700 Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns commit cbd60aa7cd17d81a434234268c55192862147439 upstream. We use a btrfs_log_ctx structure to pass information into the tree log commit, and get error values out. It gets added to a per log-transaction list which we walk when things go bad. Commit d1433debe added an optimization to skip waiting for the log commit, but didn't take root_log_ctx out of the list. This patch makes sure we remove things before exiting. Signed-off-by: Chris Mason Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4 Signed-off-by: Greg Kroah-Hartman commit 4faef745435f28cd519b9b3e345b199e3d0611cf Author: Ard Biesheuvel Date: Thu Sep 1 14:25:43 2016 +0100 crypto: cryptd - initialize child shash_desc on import commit 0bd2223594a4dcddc1e34b15774a3a4776f7749e upstream. When calling .import() on a cryptd ahash_request, the structure members that describe the child transform in the shash_desc need to be initialized like they are when calling .init() Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ca15595ada91dd0898a6a19247781ef8954a0bd9 Author: Will Deacon Date: Mon Sep 5 11:56:05 2016 +0100 arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb() commit 872c63fbf9e153146b07f0cece4da0d70b283eeb upstream. smp_mb__before_spinlock() is intended to upgrade a spin_lock() operation to a full barrier, such that prior stores are ordered with respect to loads and stores occuring inside the critical section. Unfortunately, the core code defines the barrier as smp_wmb(), which is insufficient to provide the required ordering guarantees when used in conjunction with our load-acquire-based spinlock implementation. This patch overrides the arm64 definition of smp_mb__before_spinlock() to map to a full smp_mb(). Cc: Peter Zijlstra Reported-by: Alan Stern Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit c59014167defd94b9d1ee6ec2910c36e99871c1b Author: Johan Hovold Date: Sun Jul 24 14:10:58 2016 +0200 memory: omap-gpmc: allow probe of child nodes to fail commit 23540d6e2f3193b946c4de43e3f9654fa6d23fe7 upstream. A recent commit (inadvertently?) changed how failed probe of a gpmc child node was handled. Instead of proceeding with setting up any other children as before, a single error now aborts the whole process. This change broke networking on some Overo boards due to probe failing for an unrelated nand node. This second issue should obviously be fixed, but let's restore the old behaviour of allowing child-node probe to fail to avoid further similar breakage on other systems. Fixes: d2d00862dfbb ("memory: omap-gpmc: Support general purpose input for WAITPINs") Signed-off-by: Johan Hovold Signed-off-by: Roger Quadros Signed-off-by: Greg Kroah-Hartman commit e3293cff7565cb3cff60ac3fc20040fb7d264c29 Author: Icenowy Zheng Date: Tue Aug 23 13:58:25 2016 +0800 pinctrl: sunxi: fix uart1 CTS/RTS pins at PG on A23/A33 commit 486095fae3a8a6b1ae07c51844699d9bd5cfbebc upstream. PG8, PG9 is said to be the CTS/RTS pins for UART1 according to the A23/33 datasheets. However, the function is wrongly named "uart2" in the pinctrl driver. This patch fixes this by modifying them to be named "uart1". Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit d82b9d6f03a15a4c5ea9c66fdf36e5ce335a0b76 Author: James Hartley Date: Fri Aug 19 12:03:23 2016 +0100 pinctrl: pistachio: fix mfio pll_lock pinmux commit a32ac2912f97d7ea9b67eb67bb4aa30b9156a88e upstream. A previous patch attempted to fix the pinmuxes for mfio 84 - 89, but it omitted a change to pistachio_pin_group pistachio_groups, which results in incorrect pll_lock signals being routed. Apply the correct mux settings throughout the driver. fixes: cefc03e5995e ("pinctrl: Add Pistachio SoC pin control driver") fixes: e9adb336d0bf ("pinctrl: pistachio: fix mfio84-89 function description and pinmux.") Signed-off-by: James Hartley Reviewed-by: Sifan Naeem Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 428033b6722b2f957834e4dda0f8edb4f2c967a0 Author: Mikulas Patocka Date: Tue Aug 30 16:38:42 2016 -0400 dm crypt: fix error with too large bios commit 4e870e948fbabf62b78e8410f04c67703e7c816b upstream. When dm-crypt processes writes, it allocates a new bio in crypt_alloc_buffer(). The bio is allocated from a bio set and it can have at most BIO_MAX_PAGES vector entries, however the incoming bio can be larger (e.g. if it was allocated by bcache). If the incoming bio is larger, bio_alloc_bioset() fails and an error is returned. To avoid the error, we test for a too large bio in the function crypt_map() and use dm_accept_partial_bio() to split the bio. dm_accept_partial_bio() trims the current bio to the desired size and asks DM core to send another bio with the rest of the data. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4719c16c6b5cd76c6052670dbe14c022f13ab00c Author: Mikulas Patocka Date: Tue Aug 30 16:11:53 2016 -0400 dm log writes: move IO accounting earlier to fix error path commit a5d60783df61fbb67b7596b8a0f6b4b2e05251d5 upstream. Move log_one_block()'s atomic_inc(&lc->io_blocks) before bio_alloc() to fix a bug that the target hangs if bio_alloc() fails. The error path does put_io_block(lc), so atomic_inc(&lc->io_blocks) must occur before invoking the error path to avoid underflow of lc->io_blocks. Signed-off-by: Mikulas Patocka Reviewed-by: Josef Bacik Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6d4c6d881ab4e7baf91ec16edc44b41c1149d93f Author: Eric Biggers Date: Tue Aug 30 09:51:44 2016 -0700 dm crypt: fix free of bad values after tfm allocation failure commit 5d0be84ec0cacfc7a6d6ea548afdd07d481324cd upstream. If crypt_alloc_tfms() had to allocate multiple tfms and it failed before the last allocation, then it would call crypt_free_tfms() and could free pointers from uninitialized memory -- due to the crypt_free_tfms() check for non-zero cc->tfms[i]. Fix by allocating zeroed memory. Signed-off-by: Eric Biggers Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0e470b8e18d240f2accf305e3a13469a46bd8504 Author: Vladimir Zapolskiy Date: Thu Mar 10 01:22:19 2016 +0200 dm log writes: fix check of kthread_run() return value commit 91e630d9ae6de6f740ef7c8176736eb55366833e upstream. The kthread_run() function returns either a valid task_struct or ERR_PTR() value, check for NULL is invalid. This change fixes potential for oops, e.g. in OOM situation. Signed-off-by: Vladimir Zapolskiy Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 1e2416b136cf4a33be1cedce38e0858de4b7cf1d Author: Pawel Moll Date: Wed Aug 10 17:06:26 2016 +0100 bus: arm-ccn: Fix XP watchpoint settings bitmask commit b928466b2169e061822daad48ecf55b005445547 upstream. The code setting XP watchpoint comparator and mask registers should, in order to be fully compliant with specification, zero one or more most significant bits of each field. In both L cases it means zeroing bit 63. The bitmask doing this was wrong, though, zeroing bit 60 instead. Fortunately, due to a lucky coincidence, this turned out to be fairly innocent with the existing hardware. Fixed now. Signed-off-by: Pawel Moll Signed-off-by: Greg Kroah-Hartman commit afb51efa886f5197cd117d26906b6a69e22620da Author: Pawel Moll Date: Fri Aug 5 15:07:10 2016 +0100 bus: arm-ccn: Do not attempt to configure XPs for cycle counter commit b7c1beb278e8e3dc664ed3df3fc786db126120a9 upstream. Fuzzing the CCN perf driver revealed a small but definitely dangerous mistake in the event setup code. When a cycle counter is requested, the driver should not reconfigure the events bus at all, otherwise it will corrupt (in most but the simplest cases) its configuration and may end up accessing XP array out of its bounds and corrupting control registers. Reported-by: Mark Rutland Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Pawel Moll Signed-off-by: Greg Kroah-Hartman commit b16d12e71cb60087b05c033ea3bfc5d9b7042835 Author: Pawel Moll Date: Tue Aug 2 16:45:37 2016 +0100 bus: arm-ccn: Fix PMU handling of MN commit 4e486cba285ff06a1f28f0fc2991dde1482d1dcf upstream. The "Miscellaneous Node" fell through cracks of node initialisation, as its ID is shared with HN-I. This patch treats MN as a special case (which it is), adding separate validation check for it and pre-defining the node ID in relevant events descriptions. That way one can simply run: # perf stat -a -e ccn/mn_ecbarrier/ Additionally, direction in the MN pseudo-events XP watchpoint definitions is corrected to be "TX" (1) as they are defined from the crosspoint point of view (thus barriers are transmitted from XP to MN). Signed-off-by: Pawel Moll Signed-off-by: Greg Kroah-Hartman commit d550ca7a63f080552c5273c6cfd32b03b501289c Author: Lee Jones Date: Thu Sep 8 11:11:00 2016 +0200 ARM: dts: STiH407-family: Provide interconnect clock for consumption in ST SDHCI commit 78567f135d9bbbaf4538f63656d3e4d957c35fe9 upstream. The STiH4{07,10} platform contains some interconnect clocks which are used by various IPs. If these clocks aren't handled correctly by ST's SDHCI driver MMC will break and the following output can be observed: [ 13.916949] mmc0: Timeout waiting for hardware interrupt. [ 13.922349] sdhci: =========== REGISTER DUMP (mmc0)=========== [ 13.928175] sdhci: Sys addr: 0x00000000 | Version: 0x00001002 [ 13.933999] sdhci: Blk size: 0x00007040 | Blk cnt: 0x00000001 [ 13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013 [ 13.945650] sdhci: Present: 0x1fff0206 | Host ctl: 0x00000011 [ 13.951475] sdhci: Power: 0x0000000f | Blk gap: 0x00000080 [ 13.957300] sdhci: Wake-up: 0x00000000 | Clock: 0x00003f07 [ 13.963126] sdhci: Timeout: 0x00000004 | Int stat: 0x00000000 [ 13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b [ 13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000 [ 13.980602] sdhci: Caps: 0x21ed3281 | Caps_1: 0x00000000 [ 13.986428] sdhci: Cmd: 0x0000063a | Max curr: 0x00000000 [ 13.992252] sdhci: Host ctl2: 0x00000000 [ 13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200 [ 14.001990] sdhci: =========================================== [ 14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress. Tested-by: Peter Griffin Signed-off-by: Lee Jones Acked-by: Patrice Chotard Signed-off-by: Greg Kroah-Hartman commit 8af3c9202dcd35e7c4e100b567dc9d9f419c1c28 Author: Johan Hovold Date: Mon Aug 15 09:10:49 2016 -0700 ARM: dts: overo: fix gpmc nand on boards with ethernet commit 153b58ea932b2d0642fa5cd41c93bb0555f3f09b upstream. The gpmc ranges property for NAND at CS0 was being overridden by later includes that defined gpmc ethernet nodes, effectively breaking NAND on these systems: omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has malformed 'reg' property Instead of redefining the NAND range in every such dtsi, define all currently used ranges in omap3-overo-base.dtsi. Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND") Signed-off-by: Johan Hovold Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 005271dc6ffdb935ae2aa0a7dff29b158347afff Author: Johan Hovold Date: Mon Aug 15 09:10:45 2016 -0700 ARM: dts: overo: fix gpmc nand cs0 range commit 5e0568dfbfb8c13cdb69c9fd06d600593ad4b430 upstream. The gpmc ranges property for NAND at CS0 has been broken since it was first added. This currently prevents the nand gpmc child node from being probed: omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has malformed 'reg' property and consequently the NAND device from being registered. Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND") Signed-off-by: Johan Hovold Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 5b1741150823a8159e1783872ebb75d10b54fc22 Author: Russell King Date: Fri Jul 8 14:58:39 2016 +0100 ARM: dts: armada-388-clearfog: number LAN ports properly commit d9fd3c918114cfd3995947339549c7341181efb0 upstream. Currently, the ports as seen from the rear number as: eth0 sfp lan5 lan4 lan3 lan2 lan1 lan6 which is illogical - this came about because the rev 2.0 boards have the LEDs on the front for the DSA switch (lan5-1) reversed. Rev 2.1 boards fixed the LED issue, and the Clearfog case numbers the lan ports increasing from left to right. Maintaining this illogical numbering causes confusion, with reports that "my link isn't coming up" and "my connection negotiates 10base-Half" both of which are due to people thinking that the port next to the SFP is lan1. Fix this by renumbering the ports to match people's expectations. [gregory.clement@free-electrons.com: added the Fixes and stable tags] Fixes: 4c945e8556ec ("ARM: dts: Add SolidRun Armada 388 Clearfog A1 DT file") Signed-off-by: Russell King Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 73d2f1ebc816376d1233c25929c8fea9fc68d882 Author: Fabio Estevam Date: Wed Aug 31 10:56:48 2016 -0300 ARM: dts: imx6qdl: Fix SPDIF regression commit f065e9e4addd75c21bb976bb2558648bf4f61de6 upstream. Commit 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif") changed many more clocks than only the SPDIF core clock as stated in the commit message. The MLB clock has been added and this causes SPDIF regression as reported by Xavi Drudis Ferran and also in this forum post: https://forum.digikey.com/thread/34240 The MX6Q Reference Manual does not mention that MLB is a clock related to SPDIF, so change it back to a dummy clock to restore SPDIF functionality. Thanks to Ambika for providing the fix at: https://community.nxp.com/thread/387131 Fixes: 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif") Reported-by: Xavi Drudis Ferran Signed-off-by: Fabio Estevam Tested-by: Xavi Drudis Ferran Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 01c3744248a74b4d696caaef62cbcaf9a622c86f Author: Gregory CLEMENT Date: Mon Aug 22 18:09:36 2016 +0200 ARM: dts: kirkwood: Fix PCIe label on OpenRD commit c721da1d05760ad0b4e7670896dae31b6b07d8d6 upstream. While converting PCIe node on kirkwood by using label, the following commit eb13cf8345e9 ("ARM: dts: kirkwood: Fixup pcie DT warnings") introduced a regression on the OpenRD boards: the PCIe didn't work anymore. As reported by Aaro Koskinen, the display/framebuffer was lost. This commit adds the forgotten label. Reported-by: Aaro Koskinen Tested-by: Aaro Koskinen Fixes: eb13cf8345e9 ("ARM: dts: kirkwood: Fixup pcie DT warnings") Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 5e4435839747b5117ed4e9ac4ab0e2a8b3241498 Author: Sebastian Reichel Date: Fri Jun 24 03:59:33 2016 +0200 ARM: OMAP3: hwmod data: Add sysc information for DSI commit b46211d6dcfb81a8af66b8684a42d629183670d4 upstream. Add missing sysconfig/sysstatus information to OMAP3 hwmod. The information has been checked against OMAP34xx and OMAP36xx TRM. Without this change DSI block is not reset during boot, which is required for working Nokia N950 display. Signed-off-by: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit a88732b2e6a1efc91725491ed101c45319f8e753 Author: Simon Baatz Date: Fri Aug 12 19:12:50 2016 +0200 ARM: kirkwood: ib62x0: fix size of u-boot environment partition commit a778937888867aac17a33887d1c429120790fbc2 upstream. Commit 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment partition") split the "u-boot" partition into "u-boot" and "u-boot environment". However, instead of the size of the environment, an offset was given, resulting in overlapping partitions. Signed-off-by: Simon Baatz Fixes: 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment partition") Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Cc: Luka Perkov Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit d132d19ad0a93fb4b6c8ec2e26ce6163df80ae25 Author: Anson Huang Date: Mon Aug 22 23:53:25 2016 +0800 ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx commit 8aade778f787305fdbfd3c1d54e6b583601b5902 upstream. i.MX6SX has bypass PMIC ready function, as this function is normally NOT enabled on the board design, so we need to bypass the PMIC ready pin check during DSM mode resume flow, otherwise, the internal DSM resume logic will be waiting for this signal to be ready forever and cause resume fail. Signed-off-by: Anson Huang Fixes: ff843d621bfc ("ARM: imx: add suspend support for i.mx6sx") Tested-by: Peter Chen Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit a0e5c62802b5e0df7383bca62060e6b86eca1dd7 Author: Peter Chen Date: Tue Aug 9 16:24:43 2016 +0800 ARM: imx6: add missing BM_CLPCR_BYP_MMDC_CH0_LPM_HS setting for imx6ul commit f5a49057c71433e35a4712ab8d8f00641b3e1ec0 upstream. There is a missing BM_CLPCR_BYP_MMDC_CH0_LPM_HS setting for imx6ul, without it, the "standby" mode can't work well, the system can't be resumed. With this commit, the "standby" mode works well. Signed-off-by: Peter Chen Cc: Anson Huang Fixes: ee4a5f838c84 ("ARM: imx: add suspend/resume support for i.mx6ul") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit ccc0f5a34d7a848706442261e0c11303b5fd5c9e Author: Keerthy Date: Mon Jun 20 09:22:25 2016 +0530 ARM: AM43XX: hwmod: Fix RSTST register offset for pruss commit b00ccf5b684992829610d162e78a7836933a1b19 upstream. pruss hwmod RSTST register wrongly points to PWRSTCTRL register in case of am43xx. Fix the RSTST register offset value. This can lead to setting of wrong power state values for PER domain. Fixes: 1c7e224d ("ARM: OMAP2+: hwmod: AM335x: runtime register update") Signed-off-by: Keerthy Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 257505b846a375741f799c79fbbd1f5186121589 Author: Caesar Wang Date: Wed Jul 27 22:24:07 2016 +0800 arm: dts: rockchip: add reset node for the exist saradc SoCs commit 3d4267a5a3a4b7619b80ad1839d8b3bedd8b7a8d upstream. SARADC controller needs to be reset before programming it, otherwise it will not function properly. Signed-off-by: Caesar Wang Acked-by: Heiko Stuebner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 09169bf41155c2189191e34677e97705e9f9097b Author: Zefan Li Date: Tue Aug 9 11:25:01 2016 +0800 cpuset: make sure new tasks conform to the current config of the cpuset commit 06f4e94898918bcad00cdd4d349313a439d6911e upstream. A new task inherits cpus_allowed and mems_allowed masks from its parent, but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems before this new task is inserted into the cgroup's task list, the new task won't be updated accordingly. Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 34a6b508fef2cfbf2d9f70492eb1eceafc33716e Author: Harini Katakam Date: Fri Aug 5 10:31:58 2016 +0530 net: macb: Correct CAPS mask commit c518189567eaf42b2ec50a4d982484c8e38799f8 upstream. USRIO and JUMBO CAPS have the same mask. Fix the same. Fixes: ce721a702197 ("net: ethernet: cadence-macb: Add disabled usrio caps") Signed-off-by: Harini Katakam Acked-by: Nicolas Ferre Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2905b58da16f4f233b701983e6d13a631fa6e4d2 Author: David Daney Date: Tue Aug 16 13:30:36 2016 -0700 net: thunderx: Fix OOPs with ethtool --register-dump commit 1423661fed2c40d6d71b5e2e3aa390f85157f9d5 upstream. The ethtool_ops .get_regs function attempts to read the nonexistent register NIC_QSET_SQ_0_7_CNM_CHG, which produces a "bus error" type OOPs. Fix by not attempting to read, and removing the definition of, NIC_QSET_SQ_0_7_CNM_CHG. A zero is written into the register dump to keep the layout unchanged. Signed-off-by: David Daney Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2e21a659dac2b74ef5255812b1057ca2973c5aa9 Author: Linus Torvalds Date: Sat Sep 3 11:02:50 2016 -0700 devpts: return NULL pts 'priv' entry for non-devpts nodes commit 3e423945ea94412283eaba8bfbe9d6e0a80b434f upstream. In commit 8ead9dd54716 ("devpts: more pty driver interface cleanups") I made devpts_get_priv() just return the dentry->fs_data directly. And because I thought it wouldn't happen, I added a warning if you ever saw a pts node that wasn't on devpts. And no, that warning never triggered under any actual real use, but you can trigger it by creating nonsensical pts nodes by hand. So just revert the warning, and make devpts_get_priv() return NULL for that case like it used to. Reported-by: Dmitry Vyukov Cc: "Eric W Biederman" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8b9bbb3aff2bae9ffdee9be0d4537bd395680d35 Author: Alan Stern Date: Fri Sep 16 10:24:26 2016 -0400 USB: change bInterval default to 10 ms commit 08c5cd37480f59ea39682f4585d92269be6b1424 upstream. Some full-speed mceusb infrared transceivers contain invalid endpoint descriptors for their interrupt endpoints, with bInterval set to 0. In the past they have worked out okay with the mceusb driver, because the driver sets the bInterval field in the descriptor to 1, overwriting whatever value may have been there before. However, this approach was never sanctioned by the USB core, and in fact it does not work with xHCI controllers, because they use the bInterval value that was present when the configuration was installed. Currently usbcore uses 32 ms as the default interval if the value in the endpoint descriptor is invalid. It turns out that these IR transceivers don't work properly unless the interval is set to 10 ms or below. To work around this mceusb problem, this patch changes the endpoint-descriptor parsing routine, making the default interval value be 10 ms rather than 32 ms. Signed-off-by: Alan Stern Tested-by: Wade Berrier Signed-off-by: Greg Kroah-Hartman commit 8d1f6205735205c0e01d4530136925bb3696a2d6 Author: Lee Jones Date: Thu Sep 8 11:11:00 2016 +0200 ARM: dts: STiH410: Handle interconnect clock required by EHCI/OHCI (USB) commit 7e9d2850a8db4e0d85a20bb692198bf2cc4be3b7 upstream. The STiH4{07,10} platform contains some interconnect clocks which are used by various IPs. If this clock isn't handled correctly by ST's EHCI/OHCI drivers, their hub won't be found, the following error be shown and the result will be non-working USB: [ 97.221963] hub 2-1:1.0: hub_ext_port_status failed (err = -110) Tested-by: Peter Griffin Signed-off-by: Lee Jones Acked-by: Patrice Chotard Signed-off-by: Greg Kroah-Hartman commit ad907af183ffcaba876cfc5221ba9cd4e9bfd0b0 Author: Clemens Gruber Date: Mon Sep 5 19:29:58 2016 +0200 usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase commit 6f3c4fb6d05e63c9c6d8968302491c3a5457be61 upstream. Problems with the signal integrity of the high speed USB data lines or noise on reference ground lines can cause the i.MX6 USB controller to violate USB specs and exhibit unexpected behavior. It was observed that USBi_UI interrupts were triggered first and when isr_setup_status_phase was called, ci->status was NULL, which lead to a NULL pointer dereference kernel panic. This patch fixes the kernel panic, emits a warning once and returns -EPIPE to halt the device and let the host get stalled. It also adds a comment to point people, who are experiencing this issue, to their USB hardware design. Signed-off-by: Clemens Gruber Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit 1a520433a8cf0ec3d185fffee49084fbd83ec5e2 Author: Yoshihiro Shimoda Date: Mon Aug 29 18:00:38 2016 +0900 usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition commit 519d8bd4b5d3d82c413eac5bb42b106bb4b9ec15 upstream. The previous driver is possible to stop the transfer wrongly. For example: 1) An interrupt happens, but not BRDY interruption. 2) Read INTSTS0. And than state->intsts0 is not set to BRDY. 3) BRDY is set to 1 here. 4) Read BRDYSTS. 5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly. Remarks: - The INTSTS0.BRDY is read only. - If any bits of BRDYSTS are set to 1, the BRDY is set to 1. - If BRDYSTS is 0, the BRDY is set to 0. So, this patch adds condition to avoid such situation. (And about NRDYSTS, this is not used for now. But, avoiding any side effects, this patch doesn't touch it.) Fixes: d5c6a1e024dd ("usb: renesas_usbhs: fixup interrupt status clear method") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c2147cbf630a56ac42bd305fbd3bf608bf38f897 Author: Yoshihiro Shimoda Date: Tue Aug 23 21:11:13 2016 +0900 usb: gadget: udc: renesas-usb3: clear VBOUT bit in DRD_CON commit b2f1eaaee564c5593c303f4d15d827924cb6d20d upstream. This driver should clear the bit. Otherwise, the VBUS will output wrongly if the usb port on a board has VBUS output capability. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 635d409ec5b4e6aaa3b2f10f4a6309fe7aac5978 Author: Daniele Palmas Date: Fri Sep 2 10:37:56 2016 +0200 USB: serial: simple: add support for another Infineon flashloader commit f190fd92458da3e869b4e2c6289e2c617490ae53 upstream. This patch adds support for Infineon flashloader 0x8087/0x0801. The flashloader is used in Telit LE940B modem family with Telit flashing application. Signed-off-by: Daniele Palmas Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c97f923d6cebed1d90296ab72d62c053cd6fc572 Author: Jimi Damon Date: Wed Jul 20 17:00:40 2016 -0700 serial: 8250: added acces i/o products quad and octal serial cards commit c8d192428f52f244130b84650ad616df09f2b1e1 upstream. Added devices ids for acces i/o products quad and octal serial cards that make use of existing Pericom PI7C9X7954 and PI7C9X7958 configurations . Signed-off-by: Jimi Damon Signed-off-by: Greg Kroah-Hartman commit a78ac704df43624afcc7afc88b5481db91763b02 Author: Andy Shevchenko Date: Fri Jul 1 17:21:49 2016 +0300 serial: 8250_mid: fix divide error bug if baud rate is 0 commit 47b34d2ef266e2c283b514d65c8963c2ccd42474 upstream. Since the commit c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Reported-by: "Mendez Salinas, Fernando" Fixes: c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID") Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 919771b81fa24edb8ff056d5c10cff630615dc38 Author: Colin Ian King Date: Mon Sep 5 15:39:06 2016 +0100 iio: ensure ret is initialized to zero before entering do loop commit 5dba4b14bafe801083d01e1f400816df7e5a8f2e upstream. A recent fix to iio_buffer_read_first_n_outer removed ret from being set by a return from wait_event_interruptible and also added a continue in a loop which causes the variable ret to not be set when it reaches the end of the loop. Fix this by initializing ret to zero. Also remove extraneous white space at the end of the loop. Fixes: fcf68f3c0bb2a5 ("fix sched WARNING "do not call blocking ops when !TASK_RUNNING") Signed-off-by: Colin Ian King Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a3a4fce551ff24b53e04825b9cde6de126888768 Author: Gregor Boirie Date: Fri Sep 2 20:27:46 2016 +0200 iio:core: fix IIO_VAL_FRACTIONAL sign handling commit 171c0091837c81ed5c949fec6966bb5afff2d1cf upstream. 7985e7c100 ("iio: Introduce a new fractional value type") introduced a new IIO_VAL_FRACTIONAL value type meant to represent rational type numbers expressed by a numerator and denominator combination. Formating of IIO_VAL_FRACTIONAL values relies upon do_div() usage. This fails handling negative values properly since parameters are reevaluated as unsigned values. Fix this by using div_s64_rem() instead. Computed integer part will carry properly signed value. Formatted fractional part will always be positive. Fixes: 7985e7c100 ("iio: Introduce a new fractional value type") Signed-off-by: Gregor Boirie Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f0bb3dd494eb7b04296595f5679720668055aebf Author: Linus Walleij Date: Thu Sep 1 11:44:35 2016 +0200 iio: accel: kxsd9: Fix scaling bug commit 307fe9dd11ae44d4f8881ee449a7cbac36e1f5de upstream. All the scaling of the KXSD9 involves multiplication with a fraction number < 1. However the scaling value returned from IIO_INFO_SCALE was unpredictable as only the micros of the value was assigned, and not the integer part, resulting in scaling like this: $cat in_accel_scale -1057462640.011978 Fix this by assigning zero to the integer part. Tested-by: Jonathan Cameron Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 08b7f4c7f7a2fbda7c914517e8b678d80e33050c Author: Kweh, Hock Leong Date: Mon Aug 29 18:50:56 2016 +0800 iio: fix pressure data output unit in hid-sensor-attributes commit 36afb176d3c9580651d7f410ed7f000ec48b5137 upstream. According to IIO ABI definition, IIO_PRESSURE data output unit is kilopascal: http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio This patch fix output unit of HID pressure sensor IIO driver from pascal to kilopascal to follow IIO ABI definition. Signed-off-by: Kweh, Hock Leong Reviewed-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 77f34bc737c67242f07a2b68b273aafe1c6b813d Author: Olof Johansson Date: Thu Aug 25 09:45:33 2016 -0700 iio: accel: bmc150: reset chip at init time commit 1c500840934a138bd6b13556c210516e9301fbee upstream. In at least one known setup, the chip comes up in a state where reading the chip ID returns garbage unless it's been reset, due to noise on the wires during system boot. All supported chips have the same reset method, and based on the datasheets they all need 1.3 or 1.8ms to recover after reset. So, do the conservative thing here and always reset the chip. Signed-off-by: Olof Johansson Reviewed-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cf6ffb120f37977c4d3efa1a90c50f8e8195ed8d Author: Alison Schofield Date: Mon Aug 8 11:14:36 2016 -0700 iio: humidity: hdc100x: fix sensor data reads of temp and humidity commit 0d9dcf852334b796bacc7020364afba3122db81e upstream. Replace the i2c_smbus_read_byte commmands used to retrieve the sensor data with an i2c_master_recv command. The smbus read byte method fails because the device does not expect a stop condition after sending the first byte. When we issue the second read, we are getting the first byte again. Net effect is that of the 14 bits used for the measurement, the 8 most significant bits are correct, the lower 6 are not. None of the smbus read protocols follow the pattern this device requires (S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive transaction. Applicable from original introduction of this driver, but will require backporting due to churn in the code. Signed-off-by: Alison Schofield Cc: Daniel Baluta Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e6b1db623a4d4e8043e4d0c9d60b786fa236c18b Author: Anders Darander Date: Mon Aug 8 14:42:16 2016 +0200 iio: adc: at91: unbreak channel adc channel 3 commit c2ab447454d498e709d9011c0f2d2945ee321f9b upstream. The driver always assumes that an input device has been created when reading channel 3. This causes a kernel panic when dereferencing st->ts_input. The change was introduced in commit 84882b060301 ("iio: adc: at91_adc: Add support for touchscreens without TSMR"). Earlier versions only entered that part of the if-else statement if only the following flags are set: AT91_ADC_IER_XRDY | AT91_ADC_IER_YRDY | AT91_ADC_IER_PRDY Signed-off-by: Anders Darander Acked-by: Alexandre Belloni Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 64162fb8951d2992381c914ae0ba0d762438c5da Author: Alison Schofield Date: Mon Jul 11 08:26:13 2016 -0700 iio: humidity: am2315: set up buffer timestamps for non-zero values commit 3c68858df7c2f0c4c343bb4702733fe827491f9e upstream. Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta Reviewed-By: Tiberiu Breana Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4215a755968d4e21fa982298e16934506723e038 Author: Lars-Peter Clausen Date: Mon Jul 11 13:54:17 2016 +0200 iio: ad799x: Fix buffered capture for ad7991/ad7995/ad7999 commit 7d3cc21dab5313a02f2f3ca8164529b828a030d1 upstream. The data buffer for captured mode for the ad799x driver is allocated in the update_scan_mode() callback. This callback is not set in the iio_info struct for the ad7791/ad7995/ad7999, which means that the data buffer is not allocated when a captured transfer is started. As a result the driver crashes when the first sample is received. To fix this properly set the update_scan_mode() callback. Fixes: d8dca33027c1 ("staging:iio:ad799x: Preallocate sample buffer") Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 075dc2dd4d94bd4747252cf0700d928a75a9ca87 Author: Giorgio Dal Molin Date: Tue Aug 16 20:43:37 2016 +0200 iio:ti-ads1015: fix a wrong pointer definition. commit 522caebb2c3684f4a1d154526fb5e33f1381e92a upstream. The call to i2c_get_clientdata(client) returns a struct iio_dev*, not the needed struct ads1015_data*. We need here an intermediate step as in the function: void ads1015_get_channels_config(struct i2c_client *client). Signed-off-by: Giorgio Dal Molin Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support") Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f85bc118fa276973c930543795a73fbb5408a358 Author: Vignesh R Date: Wed Aug 17 17:43:01 2016 +0530 iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample commit 7175cce1c3f1d8c8840d2004f78f96a3904249b5 upstream. Now that open delay and sample delay for each channel is configurable via DT, the default IDLE_TIMEOUT value is not enough as this is calculated based on hardcoded macros. This results in driver returning EBUSY sometimes. Fix this by increasing the timeout value based on maximum value possible to open delay and sample delays for each channel. Fixes: 5dc11e810676e ("iio: adc: ti_am335x_adc: make sample delay, open delay, averaging DT parameters") Signed-off-by: Vignesh R Acked-by: Lee Jones Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cbf5f82c2a667d0e08f2a9e84a0276af54bc5417 Author: Vignesh R Date: Wed Aug 17 17:43:00 2016 +0530 iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access commit 90c43ec6997a892448f1f86180a515f59cafd8a3 upstream. It is possible that two or more ADC channels can be simultaneously requested for raw samples, in which case there can be race in access to FIFO data resulting in loss of samples. If am335x_tsc_se_set_once() is called again from tiadc_read_raw(), when ADC is still acquired to sample one of the channels, the second process might be put into uninterruptible sleep state. Fix these issues, by protecting FIFO access and channel configurations with a mutex. Since tiadc_read_raw() might take anywhere between few microseconds to few milliseconds to finish execution (depending on averaging and delay values supplied via DT), its better to use mutex instead of spinlock. Fixes: 7ca6740cd1cd4 ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization") Signed-off-by: Vignesh R Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 45a43b26bda8161c5b18938549f7137cb20f68b5 Author: Caesar Wang Date: Wed Jul 27 22:24:04 2016 +0800 iio: adc: rockchip_saradc: reset saradc controller before programming it commit 543852af8e5902aee8f7c72c89e1513663e0f696 upstream. SARADC controller needs to be reset before programming it, otherwise it will not function properly. Signed-off-by: Caesar Wang Cc: Jonathan Cameron Cc: Heiko Stuebner Cc: Rob Herring Cc: linux-iio@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Tested-by: Guenter Roeck Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8a68ec799ac30e3edcd279019fd70a0c9af2c160 Author: Alison Schofield Date: Mon Jul 11 08:26:56 2016 -0700 iio: proximity: as3935: set up buffer timestamps for non-zero values commit f8adf645db03345af2d9a8b6095b02327ea50885 upstream. Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8f0c75b1d68fcd578932378c94ccb82a9f9fa767 Author: Lars-Peter Clausen Date: Mon Jul 11 13:50:01 2016 +0200 iio: sw-trigger: Fix config group initialization commit b2f0c09664b72b2f8c581383a9337ac3092e42c8 upstream. Use the IS_ENABLED() helper macro to ensure that the configfs group is initialized either when configfs is built-in or when configfs is built as a module. Otherwise software trigger creation will result in undefined behaviour when configfs is built as a mdoule since the configfs group for the trigger is not properly initialized. Fixes: b662f809d410 ("iio: core: Introduce IIO software triggers") Signed-off-by: Lars-Peter Clausen Acked-by: Daniel Baluta Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 007f0acf06f4d1853afe45c933cc09e7ca967cda Author: Linus Walleij Date: Tue Aug 16 15:33:28 2016 +0200 iio: accel: kxsd9: Fix raw read return commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 upstream. Any readings from the raw interface of the KXSD9 driver will return an empty string, because it does not return IIO_VAL_INT but rather some random value from the accelerometer to the caller. Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6c6f007505b33004ccbdb9ce9db203d5b2b36680 Author: Paolo Bonzini Date: Wed Sep 14 23:39:12 2016 +0200 kvm: x86: correctly reset dest_map->vector when restoring LAPIC state commit b0eaf4506f5f95d15d6731d72c0ddf4a2179eefa upstream. When userspace sends KVM_SET_LAPIC, KVM schedules a check between the vCPU's IRR and ISR and the IOAPIC redirection table, in order to re-establish the IOAPIC's dest_map (the list of CPUs servicing the real-time clock interrupt with the corresponding vectors). However, __rtc_irq_eoi_tracking_restore_one was forgetting to set dest_map->vectors. Because of this, the IOAPIC did not process the real-time clock interrupt EOI, ioapic->rtc_status.pending_eoi got stuck at a non-zero value, and further RTC interrupts were reported to userspace as coalesced. Fixes: 9e4aabe2bb3454c83dac8139cf9974503ee044db Fixes: 4d99ba898dd0c521ca6cdfdde55c9b58aea3cb3d Cc: Joerg Roedel Cc: David Gilbert Reviewed-by: Radim Krčmář Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 53ccff6d9ea747ff0f3c04777f8501938064a977 Author: Suzuki K Poulose Date: Thu Sep 8 16:25:49 2016 +0100 kvm-arm: Unmap shadow pagetables properly commit 293f293637b55db4f9f522a5a72514e98a541076 upstream. On arm/arm64, we depend on the kvm_unmap_hva* callbacks (via mmu_notifiers::invalidate_*) to unmap the stage2 pagetables when the userspace buffer gets unmapped. However, when the Hypervisor process exits without explicit unmap of the guest buffers, the only notifier we get is kvm_arch_flush_shadow_all() (via mmu_notifier::release ) which does nothing on arm. Later this causes us to access pages that were already released [via exit_mmap() -> unmap_vmas()] when we actually get to unmap the stage2 pagetable [via kvm_arch_destroy_vm() -> kvm_free_stage2_pgd()]. This triggers crashes with CONFIG_DEBUG_PAGEALLOC, which unmaps any free'd pages from the linear map. [ 757.644120] Unable to handle kernel paging request at virtual address ffff800661e00000 [ 757.652046] pgd = ffff20000b1a2000 [ 757.655471] [ffff800661e00000] *pgd=00000047fffe3003, *pud=00000047fcd8c003, *pmd=00000047fcc7c003, *pte=00e8004661e00712 [ 757.666492] Internal error: Oops: 96000147 [#3] PREEMPT SMP [ 757.672041] Modules linked in: [ 757.675100] CPU: 7 PID: 3630 Comm: qemu-system-aar Tainted: G D 4.8.0-rc1 #3 [ 757.683240] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board, BIOS 3.06.15 Aug 19 2016 [ 757.692938] task: ffff80069cdd3580 task.stack: ffff8006adb7c000 [ 757.698840] PC is at __flush_dcache_area+0x1c/0x40 [ 757.703613] LR is at kvm_flush_dcache_pmd+0x60/0x70 [ 757.708469] pc : [] lr : [] pstate: 20000145 ... [ 758.357249] [] __flush_dcache_area+0x1c/0x40 [ 758.363059] [] unmap_stage2_range+0x458/0x5f0 [ 758.368954] [] kvm_free_stage2_pgd+0x34/0x60 [ 758.374761] [] kvm_arch_destroy_vm+0x20/0x68 [ 758.380570] [] kvm_put_kvm+0x210/0x358 [ 758.385860] [] kvm_vm_release+0x2c/0x40 [ 758.391239] [] __fput+0x114/0x2e8 [ 758.396096] [] ____fput+0xc/0x18 [ 758.400869] [] task_work_run+0x108/0x138 [ 758.406332] [] do_exit+0x48c/0x10e8 [ 758.411363] [] do_group_exit+0x6c/0x130 [ 758.416739] [] get_signal+0x284/0xa18 [ 758.421943] [] do_signal+0x158/0x860 [ 758.427060] [] do_notify_resume+0x6c/0x88 [ 758.432608] [] work_pending+0x10/0x14 [ 758.437812] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20) This patch fixes the issue by moving the kvm_free_stage2_pgd() to kvm_arch_flush_shadow_all(). Tested-by: Itaru Kitayama Reported-by: Itaru Kitayama Reported-by: James Morse Cc: Marc Zyngier Cc: Catalin Marinas Cc: Christoffer Dall Signed-off-by: Suzuki K Poulose Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 7c1d58892d58188ed681c22d7366f233494181cf Author: David Hildenbrand Date: Tue Aug 16 14:38:24 2016 +0200 KVM: s390: don't use current->thread.fpu.* when accessing registers commit a7d4b8f2565ad0dfdff9a222d1d87990c73b36e8 upstream. As the meaning of these variables and pointers seems to change more frequently, let's directly access our save area, instead of going via current->thread. Right now, this is broken for set/get_fpu. They simply overwrite the host registers, as the pointers to the current save area were turned into the static host save area. Fixes: 3f6813b9a5e0 ("s390/fpu: allocate 'struct fpu' with the task_struct") Reported-by: Hao QingFeng Signed-off-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 69f5f0641a8c890b822671ba266c3254b815040b Author: Emanuel Czirai Date: Fri Sep 2 07:35:50 2016 +0200 x86/AMD: Apply erratum 665 on machines without a BIOS fix commit d1992996753132e2dafe955cccb2fb0714d3cfc4 upstream. AMD F12h machines have an erratum which can cause DIV/IDIV to behave unpredictably. The workaround is to set MSRC001_1029[31] but sometimes there is no BIOS update containing that workaround so let's do it ourselves unconditionally. It is simple enough. [ Borislav: Wrote commit message. ] Signed-off-by: Emanuel Czirai Signed-off-by: Borislav Petkov Cc: Yaowu Xu Link: http://lkml.kernel.org/r/20160902053550.18097-1-bp@alien8.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 393dabc702972da8a8912354da573a7c8f6151e4 Author: Steven Rostedt Date: Wed May 25 13:47:26 2016 -0400 x86/paravirt: Do not trace _paravirt_ident_*() functions commit 15301a570754c7af60335d094dd2d1808b0641a5 upstream. Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means that those functions are most likely called within critical sections of the funtion tracer, and must not be traced. In newer kenels _paravirt_nop() is defined within gcc asm(), and is no longer an issue. But both _paravirt_ident_{32,64}() causes the following splat when they are traced: mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054) mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070) mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054) mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054) NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469] Modules linked in: e1000e CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000 RIP: 0010:[] [] queued_spin_lock_slowpath+0x118/0x1a0 RSP: 0018:ffff8800d4aefb90 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40 RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030 RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000 R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8 R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0 FS: 00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0 Call Trace: _raw_spin_lock+0x27/0x30 handle_pte_fault+0x13db/0x16b0 handle_mm_fault+0x312/0x670 __do_page_fault+0x1b1/0x4e0 do_page_fault+0x22/0x30 page_fault+0x28/0x30 __vfs_read+0x28/0xe0 vfs_read+0x86/0x130 SyS_read+0x46/0xa0 entry_SYSCALL_64_fastpath+0x1e/0xa8 Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b Reported-by: Łukasz Daniluk Signed-off-by: Steven Rostedt Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0fd86d80ffdd1829a71a281d7bda550477a44b59 Author: Dan Williams Date: Wed Sep 7 08:51:21 2016 -0700 mm: fix cache mode of dax pmd mappings commit 9049771f7d5490a302589976984810064c83ab40 upstream. track_pfn_insert() in vmf_insert_pfn_pmd() is marking dax mappings as uncacheable rendering them impractical for application usage. DAX-pte mappings are cached and the goal of establishing DAX-pmd mappings is to attain more performance, not dramatically less (3 orders of magnitude). track_pfn_insert() relies on a previous call to reserve_memtype() to establish the expected page_cache_mode for the range. While memremap() arranges for reserve_memtype() to be called, devm_memremap_pages() does not. So, teach track_pfn_insert() and untrack_pfn() how to handle tracking without a vma, and arrange for devm_memremap_pages() to establish the write-back-cache reservation in the memtype tree. Cc: Matthew Wilcox Cc: Ross Zwisler Cc: Nilesh Choudhury Cc: Kirill A. Shutemov Reported-by: Toshi Kani Reported-by: Kai Zhang Acked-by: Andrew Morton Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit b4000d206c21d868f9598a6d7b2fee5d48f613ec Author: Easwar Hariharan Date: Mon Jul 25 13:40:03 2016 -0700 IB/hfi1: Reset QSFP on every run through channel tuning commit b5e710195492f682d93097cddac13e594d39a946 upstream. Active QSFP cables were reset only every alternate iteration of the channel tuning algorithm instead of every iteration due to incorrect reset of the flag that controlled QSFP reset, resulting in using stale QSFP status in the channel tuning algorithm. Fixes: 8ebd4cf1852a ("Add active and optical cable support") Reviewed-by: Dean Luick Signed-off-by: Easwar Hariharan Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit d86220a95429bd8c81514f3a0799e102463c034d Author: Jason Gunthorpe Date: Sun Jul 3 15:28:18 2016 +0300 IB/uverbs: Fix race between uverbs_close and remove_one commit d1e09f304a1d9651c5059ebfeb696dc2effc9b32 upstream. Fixes an oops that might happen if uverbs_close races with remove_one. Both contexts may run ib_uverbs_cleanup_ucontext, it depends on the flow. Currently, there is no protection for a case that remove_one didn't make the cleanup it runs to its end, the underlying ib_device was freed then uverbs_close will call ib_uverbs_cleanup_ucontext and OOPs. Above might happen if uverbs_close deleted the file from the list then remove_one didn't find it and runs to its end. Fixes to protect against that case by a new cleanup lock so that ib_uverbs_cleanup_ucontext will be called always before that remove_one is ended. Fixes: 35d4a0b63dc0 ("IB/uverbs: Fix race between ib_uverbs_open and remove_one") Reported-by: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 1c94558c5df3e05f6d0051f947087441f9ff56d4 Author: Mike Marciniszyn Date: Fri Aug 12 11:17:37 2016 -0400 IB/hfi1,IB/qib: Fix qp_stats sleep with rcu read lock held commit c62fb260a86dde3df5b2905432caa0e9f6898434 upstream. The qp init function does a kzalloc() while holding the RCU lock that encounters the following warning with a debug kernel when a cat of the qp_stats is done: [ 231.723948] rcu_scheduler_active = 1, debug_locks = 0 [ 231.731939] 3 locks held by cat/11355: [ 231.736492] #0: (debugfs_srcu){......}, at: [] debugfs_use_file_start+0x5/0x90 [ 231.746955] #1: (&p->lock){+.+.+.}, at: [] seq_read+0x4c/0x3c0 [ 231.755873] #2: (rcu_read_lock){......}, at: [] _qp_stats_seq_start+0x5/0xd0 [hfi1] [ 231.766862] The init functions do an implicit next which requires the rcu read lock before the kzalloc(). Fix for both drivers is to change the scope of the init function to only do the allocation and the initialization of the just allocated iter. The implict next is moved back into the respective start functions to fix the issue. Signed-off-by: Ira Weiny Signed-off-by: Mike Marciniszyn Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit b60784f807b36f89d89d174cbff574df75a7a586 Author: Mike Snitzer Date: Wed Aug 24 21:12:58 2016 -0400 dm flakey: fix reads to be issued if drop_writes configured commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 7bac8850af69c9322a9ee32a6cc449d02eccb01f Author: Mateusz Guzik Date: Tue Aug 23 16:20:39 2016 +0200 audit: fix exe_file access in audit_exe_compare commit 5efc244346f9f338765da3d592f7947b0afdc4b5 upstream. Prior to the change the function would blindly deference mm, exe_file and exe_file->f_inode, each of which could have been NULL or freed. Use get_task_exe_file to safely obtain stable exe_file. Signed-off-by: Mateusz Guzik Acked-by: Konstantin Khlebnikov Acked-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 2daa86f541b8fa873c56b3cc2c8dc32e03b864fc Author: Mateusz Guzik Date: Tue Aug 23 16:20:38 2016 +0200 mm: introduce get_task_exe_file commit cd81a9170e69e018bbaba547c1fd85a585f5697a upstream. For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by: Mateusz Guzik Acked-by: Konstantin Khlebnikov Acked-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 78494c6237c82f0b45fab75c3b2988d00505992c Author: Alexandre Bounine Date: Thu Sep 1 16:15:18 2016 -0700 rapidio/tsi721: fix incorrect detection of address translation condition commit b30069291dc7f9b9a073c33d619818fe4a8e50de upstream. Fix incorrect condition to identify involvment of a address translation mechanism. This bug results in NULL pointer kernel crash dump in cases when mapping of inbound RapidIO address range is requested within existing aprture. Link: http://lkml.kernel.org/r/20160901173144.2983-1-alexandre.bounine@idt.com Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: Andre van Herk Cc: Barry Wood Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1ea19be4d9eb686728b877adaa9b6ad1aae3c1ac Author: Christoph Hellwig Date: Thu Aug 11 07:26:01 2016 -0700 ahci: disable correct irq for dummy ports commit 9b4b3f6a062b22550e62523efe5213776cdd426b upstream. irq already contains the interrupt number for the port, don't add the port index to it. Signed-off-by: Christoph Hellwig Signed-off-by: Tejun Heo Fixes: d684a90d38e2 ("ahci: per-port msix support") Signed-off-by: Greg Kroah-Hartman commit 62e078a4e500b568b64c3dd60dbbff1c715a7bc6 Author: David Rientjes Date: Thu Sep 1 16:15:07 2016 -0700 mm, mempolicy: task->mempolicy must be NULL before dropping final reference commit c11600e4fed67ae4cd6a8096936afd445410e8ed upstream. KASAN allocates memory from the page allocator as part of kmem_cache_free(), and that can reference current->mempolicy through any number of allocation functions. It needs to be NULL'd out before the final reference is dropped to prevent a use-after-free bug: BUG: KASAN: use-after-free in alloc_pages_current+0x363/0x370 at addr ffff88010b48102c CPU: 0 PID: 15425 Comm: trinity-c2 Not tainted 4.8.0-rc2+ #140 ... Call Trace: dump_stack kasan_object_err kasan_report_error __asan_report_load2_noabort alloc_pages_current <-- use after free depot_save_stack save_stack kasan_slab_free kmem_cache_free __mpol_put <-- free do_exit This patch sets current->mempolicy to NULL before dropping the final reference. Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1608301442180.63329@chino.kir.corp.google.com Fixes: cd11016e5f52 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") Signed-off-by: David Rientjes Reported-by: Vegard Nossum Acked-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bec4e55b55867ed948a3afd9f9ccf3506bfdad24 Author: Michal Hocko Date: Thu Sep 1 16:14:41 2016 -0700 mm, oom: prevent premature OOM killer invocation for high order request commit 6b4e3181d7bd5ca5ab6f45929e4a5ffa7ab4ab7f upstream. There have been several reports about pre-mature OOM killer invocation in 4.7 kernel when order-2 allocation request (for the kernel stack) invoked OOM killer even during basic workloads (light IO or even kernel compile on some filesystems). In all reported cases the memory is fragmented and there are no order-2+ pages available. There is usually a large amount of slab memory (usually dentries/inodes) and further debugging has shown that there are way too many unmovable blocks which are skipped during the compaction. Multiple reporters have confirmed that the current linux-next which includes [1] and [2] helped and OOMs are not reproducible anymore. A simpler fix for the late rc and stable is to simply ignore the compaction feedback and retry as long as there is a reclaim progress and we are not getting OOM for order-0 pages. We already do that for CONFING_COMPACTION=n so let's reuse the same code when compaction is enabled as well. [1] http://lkml.kernel.org/r/20160810091226.6709-1-vbabka@suse.cz [2] http://lkml.kernel.org/r/f7a9ea9d-bb88-bfd6-e340-3a933559305a@suse.cz Fixes: 0a0337e0d1d1 ("mm, oom: rework oom detection") Link: http://lkml.kernel.org/r/20160823074339.GB23577@dhcp22.suse.cz Signed-off-by: Michal Hocko Tested-by: Olaf Hering Tested-by: Ralf-Peter Rohbeck Cc: Markus Trippelsdorf Cc: Arkadiusz Miskiewicz Cc: Ralf-Peter Rohbeck Cc: Jiri Slaby Cc: Vlastimil Babka Cc: Joonsoo Kim Cc: Tetsuo Handa Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8f46a24a837b1794b2e14692bc620670110cb2d1 Author: Thiago Jung Bauermann Date: Thu Sep 1 16:14:44 2016 -0700 kexec: fix double-free when failing to relocate the purgatory commit 070c43eea5043e950daa423707ae3c77e2f48edb upstream. If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs and pi->purgatory_buf. This is redundant, because in case of error kimage_file_prepare_segments calls kimage_file_post_load_cleanup, which will also free those buffers. This causes two warnings like the following, one for pi->sechdrs and the other for pi->purgatory_buf: kexec-bzImage64: Loading purgatory failed ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 __vunmap+0xc1/0xd0 Trying to vfree() nonexistent vm area (ffffc90000e91000) Modules linked in: CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x4f/0x60 ? find_vmap_area+0x19/0x70 ? kimage_file_post_load_cleanup+0x47/0xb0 __vunmap+0xc1/0xd0 vfree+0x2e/0x70 kimage_file_post_load_cleanup+0x5e/0xb0 SyS_kexec_file_load+0x448/0x680 ? putname+0x54/0x60 ? do_sys_open+0x190/0x1f0 entry_SYSCALL_64_fastpath+0x13/0x8f ---[ end trace 158bb74f5950ca2b ]--- Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree won't try to free a NULL pointer. Link: http://lkml.kernel.org/r/1472083546-23683-1-git-send-email-bauerman@linux.vnet.ibm.com Signed-off-by: Thiago Jung Bauermann Acked-by: Baoquan He Cc: "Eric W. Biederman" Cc: Vivek Goyal Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b35f5bd1e8ac808a163a260347f6690a93aa1c9b Author: Trond Myklebust Date: Sun Sep 11 14:50:01 2016 -0400 NFSv4.1: Fix the CREATE_SESSION slot number accounting commit b519d408ea32040b1c7e10b155a3ee9a36660947 upstream. Ensure that we conform to the algorithm described in RFC5661, section 18.36.4 for when to bump the sequence id. In essence we do it for all cases except when the RPC call timed out, or in case of the server returning NFS4ERR_DELAY or NFS4ERR_STALE_CLIENTID. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit f8421e38337f3b19d202932af1b1b37b515e5063 Author: Trond Myklebust Date: Sat Sep 3 10:39:51 2016 -0400 pNFS: Ensure LAYOUTGET and LAYOUTRETURN are properly serialised commit bf0291dd2267a2b9a4cd74d65249553d11bb45d6 upstream. According to RFC5661, the client is responsible for serialising LAYOUTGET and LAYOUTRETURN to avoid ambiguity. Consider the case where we send both in parallel. Client Server ====== ====== LAYOUTGET(seqid=X) LAYOUTRETURN(seqid=X) LAYOUTGET return seqid=X+1 LAYOUTRETURN return seqid=X+2 Process LAYOUTRETURN Forget layout stateid Process LAYOUTGET Set seqid=X+1 The client processes the layoutget/layoutreturn in the wrong order, and since the result of the layoutreturn was to clear the only existing layout segment, the client forgets the layout stateid. When the LAYOUTGET comes in, it is treated as having a completely new stateid, and so the client sets the wrong sequence id... Fix is to check if there are outstanding LAYOUTGET requests before we send the LAYOUTRETURN (note that LAYOUGET will already wait if it sees an outstanding LAYOUTRETURN). Signed-off-by: Trond Myklebust Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 33b5cb27b6dab168ca581bc70acad96c28bc181a Author: Chuck Lever Date: Wed Jul 13 16:40:14 2016 -0400 nfsd: Close race between nfsd4_release_lockowner and nfsd4_lock commit 885848186fbc2d1d8fb6d2fdc2156638ae289a46 upstream. nfsd4_release_lockowner finds a lock owner that has no lock state, and drops cl_lock. Then release_lockowner picks up cl_lock and unhashes the lock owner. During the window where cl_lock is dropped, I don't see anything preventing a concurrent nfsd4_lock from finding that same lock owner and adding lock state to it. Move release_lockowner() into nfsd4_release_lockowner and hang onto the cl_lock until after the lock owner's state cannot be found again. Found by inspection, we don't currently have a reproducer. Fixes: 2c41beb0e5cf ("nfsd: reduce cl_lock thrashing in ... ") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 298f9fbf4f1e1a3c9027a2a3749fd6a937521c8c Author: Trond Myklebust Date: Mon Aug 29 11:15:36 2016 -0400 NFSv4.x: Fix a refcount leak in nfs_callback_up_net commit 98b0f80c2396224bbbed81792b526e6c72ba9efa upstream. On error, the callers expect us to return without bumping nn->cb_users[]. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 11d01071d730e6a93193a5954cb9cb04a8bd05dd Author: Trond Myklebust Date: Sat Aug 27 23:44:04 2016 -0400 NFSv4.1: Fix Oopsable condition in server callback races commit e09c978aae5bedfdb379be80363b024b7d82638b upstream. The slot table hasn't been an array since v3.7. Ensure that we use nfs4_lookup_slot() to access the slot correctly. Fixes: 87dda67e7386 ("NFSv4.1: Allow SEQUENCE to resize the slot table...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 36148aaa4fc5826fe9db860a2dcc15ad701159f6 Author: Trond Myklebust Date: Tue Aug 23 11:19:33 2016 -0400 pNFS: The client must not do I/O to the DS if it's lease has expired commit b88fa69eaa8649f11828158c7b65c4bcd886ebd5 upstream. Ensure that the client conforms to the normative behaviour described in RFC5661 Section 12.7.2: "If a client believes its lease has expired, it MUST NOT send I/O to the storage device until it has validated its lease." So ensure that we wait for the lease to be validated before using the layout. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 01b5dd8fe979089c1197bf0665a17ed8a5c7f568 Author: Trond Myklebust Date: Mon Aug 29 15:12:54 2016 -0400 pNFS/flexfiles: Fix an Oopsable condition when connection to the DS fails commit 3dc147359e3dcdf0648f1e2c11f62cfae3160df0 upstream. If the attempt to connect to a DS fails inside ff_layout_pg_init_read or ff_layout_pg_init_write, then we currently end up clearing the layout segment carried by the struct nfs_pageio_descriptor, causing an Oops when we later call into ff_layout_read_pagelist/ff_layout_write_pagelist. The fix is to ensure we return the layout and then retry. Fixes: 446ca2195303 ("pNFS/flexfiles: When initing reads or writes, we...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 951e0d6955a024cf952582558995f91e773b9ef6 Author: Tejun Heo Date: Fri Jun 17 17:51:17 2016 -0400 kernfs: don't depend on d_find_any_alias() when generating notifications commit df6a58c5c5aa8ecb1e088ecead3fa33ae70181f1 upstream. kernfs_notify_workfn() sends out file modified events for the scheduled kernfs_nodes. Because the modifications aren't from userland, it doesn't have the matching file struct at hand and can't use fsnotify_modify(). Instead, it looked up the inode and then used d_find_any_alias() to find the dentry and used fsnotify_parent() and fsnotify() directly to generate notifications. The assumption was that the relevant dentries would have been pinned if there are listeners, which isn't true as inotify doesn't pin dentries at all and watching the parent doesn't pin the child dentries even for dnotify. This led to, for example, inotify watchers not getting notifications if the system is under memory pressure and the matching dentries got reclaimed. It can also be triggered through /proc/sys/vm/drop_caches or a remount attempt which involves shrinking dcache. fsnotify_parent() only uses the dentry to access the parent inode, which kernfs can do easily. Update kernfs_notify_workfn() so that it uses fsnotify() directly for both the parent and target inodes without going through d_find_any_alias(). While at it, supply the target file name to fsnotify() from kernfs_node->name. Signed-off-by: Tejun Heo Reported-by: Evgeny Vereshchagin Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too") Cc: John McCutchan Cc: Robert Love Cc: Eric Paris Signed-off-by: Greg Kroah-Hartman commit e6e89d33ac6ceeb63b598843305811f1df0ab5fa Author: Gavin Shan Date: Tue Sep 6 14:17:18 2016 +1000 powerpc/powernv: Fix corrupted PE allocation bitmap on releasing PE commit caa58f808834fca9a4443233fd09df5ab639690d upstream. In pnv_ioda_free_pe(), the PE object (including the associated PE number) is cleared before resetting the corresponding bit in the PE allocation bitmap. It means PE#0 is always released to the bitmap wrongly. This fixes above issue by caching the PE number before the PE object is cleared. Fixes: 1e9167726c41 ("powerpc/powernv: Use PE instead of number during setup and release" Signed-off-by: Gavin Shan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bf8c173b0d6a9da876d9e9f7eba3a1980520f051 Author: Paul Mackerras Date: Fri Sep 2 21:47:59 2016 +1000 powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET commit f077aaf0754bcba0fffdbd925bc12f09cd1e38aa upstream. In commit c60ac5693c47 ("powerpc: Update kernel VSID range", 2013-03-13) we lost a check on the region number (the top four bits of the effective address) for addresses below PAGE_OFFSET. That commit replaced a check that the top 18 bits were all zero with a check that bits 46 - 59 were zero (performed for all addresses, not just user addresses). This means that userspace can access an address like 0x1000_0xxx_xxxx_xxxx and we will insert a valid SLB entry for it. The VSID used will be the same as if the top 4 bits were 0, but the page size will be some random value obtained by indexing beyond the end of the mm_ctx_high_slices_psize array in the paca. If that page size is the same as would be used for region 0, then userspace just has an alias of the region 0 space. If the page size is different, then no HPTE will be found for the access, and the process will get a SIGSEGV (since hash_page_mm() will refuse to create a HPTE for the bogus address). The access beyond the end of the mm_ctx_high_slices_psize can be at most 5.5MB past the array, and so will be in RAM somewhere. Since the access is a load performed in real mode, it won't fault or crash the kernel. At most this bug could perhaps leak a little bit of information about blocks of 32 bytes of memory located at offsets of i * 512kB past the paca->mm_ctx_high_slices_psize array, for 1 <= i <= 11. Fixes: c60ac5693c47 ("powerpc: Update kernel VSID range") Signed-off-by: Paul Mackerras Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 299f0ab9fe2a5e949d74221c2e8860570c4aa61a Author: Christophe Leroy Date: Thu Aug 11 10:50:40 2016 +0200 powerpc: sysdev: cpm: fix gpio save_regs functions commit 41017a7579cf49cb5513e17df1570dc918760079 upstream. of_mm_gpiochip_add_data() calls mm_gc->save_regs() before setting the data. Therefore ->save_regs() cannot use gpiochip_get_data() [ 0.275940] Unable to handle kernel paging request for data at address 0x00000130 [ 0.283120] Faulting instruction address: 0xc01b44cc [ 0.288175] Oops: Kernel access of bad area, sig: 11 [#1] [ 0.293343] PREEMPT CMPC885 [ 0.296141] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-g65124df-dirty #68 [ 0.304131] task: c6074000 ti: c6080000 task.ti: c6080000 [ 0.309459] NIP: c01b44cc LR: c0011720 CTR: c0011708 [ 0.314372] REGS: c6081d90 TRAP: 0300 Not tainted (4.7.0-g65124df-dirty) [ 0.322267] MSR: 00009032 CR: 24000028 XER: 20000000 [ 0.328813] DAR: 00000130 DSISR: c0000000 GPR00: c01b6d0c c6081e40 c6074000 c6017000 c9028000 c601d028 c6081dd8 00000000 GPR08: c601d028 00000000 ffffffff 00000001 24000044 00000000 c0002790 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c05643b0 00000083 GPR24: c04a1a6c c0560000 c04a8308 c04c6480 c0012498 c6017000 c7ffcc78 c6017000 [ 0.360806] NIP [c01b44cc] gpiochip_get_data+0x4/0xc [ 0.365684] LR [c0011720] cpm1_gpio16_save_regs+0x18/0x44 [ 0.370972] Call Trace: [ 0.373451] [c6081e50] [c01b6d0c] of_mm_gpiochip_add_data+0x70/0xdc [ 0.379624] [c6081e70] [c00124c0] cpm_init_par_io+0x28/0x118 [ 0.385238] [c6081e80] [c04a8ac0] do_one_initcall+0xb0/0x17c [ 0.390819] [c6081ef0] [c04a8cbc] kernel_init_freeable+0x130/0x1dc [ 0.396924] [c6081f30] [c00027a4] kernel_init+0x14/0x110 [ 0.402177] [c6081f40] [c000b424] ret_from_kernel_thread+0x5c/0x64 [ 0.408233] Instruction dump: [ 0.411168] 4182fafc 3f80c040 48234c6d 3bc0fff0 3b9c5ed0 4bfffaf4 81290020 712a0004 [ 0.418825] 4182fb34 48234c51 4bfffb2c 81230004 <80690130> 4e800020 7c0802a6 9421ffe0 [ 0.426763] ---[ end trace fe4113ee21d72ffa ]--- fixes: e65078f1f3490 ("powerpc: sysdev: cpm1: use gpiochip data pointer") fixes: a14a2d484b386 ("powerpc: cpm_common: use gpiochip data pointer") Signed-off-by: Christophe Leroy Reviewed-by: Linus Walleij Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 71458cfcd445686c37fac443e32f3c477d190ed0 Author: Mukesh Ojha Date: Mon Aug 22 12:17:44 2016 +0530 powerpc/powernv : Drop reference added by kset_find_obj() commit a9cbf0b2195b695cbeeeecaa4e2770948c212e9a upstream. In a situation, where Linux kernel gets notified about duplicate error log from OPAL, it is been observed that kernel fails to remove sysfs entries (/sys/firmware/opal/elog/0xXXXXXXXX) of such error logs. This is because, we currently search the error log/dump kobject in the kset list via 'kset_find_obj()' routine. Which eventually increment the reference count by one, once it founds the kobject. So, unless we decrement the reference count by one after it found the kobject, we would not be able to release the kobject properly later. This patch adds the 'kobject_put()' which was missing earlier. Signed-off-by: Mukesh Ojha Reviewed-by: Vasant Hegde Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3a62e9f92f6eb4bc46b9e6e1b139f2c37d705b17 Author: Nicholas Piggin Date: Mon Jul 25 14:26:51 2016 +1000 powerpc/tm: do not use r13 for tabort_syscall commit cc7786d3ee7e3c979799db834b528db2c0834c2e upstream. tabort_syscall runs with RI=1, so a nested recoverable machine check will load the paca into r13 and overwrite what we loaded it with, because exceptions returning to privileged mode do not restore r13. Fixes: b4b56f9ecab4 (powerpc/tm: Abort syscalls in active transactions) Signed-off-by: Nick Piggin Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d0a2b134caadd948f277a62f6715fa86d30e7f2d Author: Artem Germanov Date: Wed Sep 7 10:49:36 2016 -0700 tcp: cwnd does not increase in TCP YeAH [ Upstream commit db7196a0d0984b933ccf2cd6a60e26abf466e8a3 ] Commit 76174004a0f19785a328f40388e87e982bbf69b9 (tcp: do not slow start when cwnd equals ssthresh ) introduced regression in TCP YeAH. Using 100ms delay 1% loss virtual ethernet link kernel 4.2 shows bandwidth ~500KB/s for single TCP connection and kernel 4.3 and above (including 4.8-rc4) shows bandwidth ~100KB/s. That is caused by stalled cwnd when cwnd equals ssthresh. This patch fixes it by proper increasing cwnd in this case. Signed-off-by: Artem Germanov Acked-by: Dmitry Adamushko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28186a5c98d1a173596c1ec94a95d25215428496 Author: Gal Pressman Date: Wed Sep 7 19:08:01 2016 +0300 net/mlx5e: Fix parsing of vlan packets when updating lro header [ Upstream commit cd17d230dd060a12f7451c0caeedb3fd5158eaf9 ] Currently vlan tagged packets were not parsed correctly and assumed to be regular IPv4/IPv6 packets. We should check for 802.1Q/802.1ad tags and update the lro header accordingly. This fixes the use case where LRO is on and rxvlan is off (vlan stripping is off). Fixes: e586b3b0baee ('net/mlx5: Ethernet Datapath files') Signed-off-by: Gal Pressman Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f637323161e0e561c8f216eac0db2c17221f511 Author: Eric Dumazet Date: Wed Sep 7 08:34:11 2016 -0700 tcp: fastopen: avoid negative sk_forward_alloc [ Upstream commit 76061f631c2ea4ab9c4d66f3a96ecc5737f5aaf7 ] When DATA and/or FIN are carried in a SYN/ACK message or SYN message, we append an skb in socket receive queue, but we forget to call sk_forced_mem_schedule(). Effect is that the socket has a negative sk->sk_forward_alloc as long as the message is not read by the application. Josh Hunt fixed a similar issue in commit d22e15371811 ("tcp: fix tcp fin memory accounting") Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path") Signed-off-by: Eric Dumazet Reviewed-by: Josh Hunt Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d Author: Wei Yongjun Date: Mon Sep 5 16:06:31 2016 +0800 ipv6: addrconf: fix dev refcont leak when DAD failed [ Upstream commit 751eb6b6042a596b0080967c1a529a9fe98dac1d ] In general, when DAD detected IPv6 duplicate address, ifp->state will be set to INET6_IFADDR_STATE_ERRDAD and DAD is stopped by a delayed work, the call tree should be like this: ndisc_recv_ns -> addrconf_dad_failure <- missing ifp put -> addrconf_mod_dad_work -> schedule addrconf_dad_work() -> addrconf_dad_stop() <- missing ifp hold before call it addrconf_dad_failure() called with ifp refcont holding but not put. addrconf_dad_work() call addrconf_dad_stop() without extra holding refcount. This will not cause any issue normally. But the race between addrconf_dad_failure() and addrconf_dad_work() may cause ifp refcount leak and netdevice can not be unregister, dmesg show the following messages: IPv6: eth0: IPv6 duplicate address fe80::XX:XXXX:XXXX:XX detected! ... unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Cc: stable@vger.kernel.org Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue") Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95b12dc14d0a69bc3f85dc17b1d7a2ff8fd6ad4b Author: Michael Chan Date: Mon Sep 5 01:57:35 2016 -0400 bnxt_en: Fix TX push operation on ARM64. [ Upstream commit 9d13744bb75078175ab49408f2abb980e4dbccc9 ] There is a code path where we are calling __iowrite64_copy() on an address that is not 64-bit aligned. This causes an exception on some architectures such as arm64. Fix that code path by using __iowrite32_copy(). Reported-by: JD Zheng Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e4a409d45cc42239dc7dc39000f758fc99e2fdec Author: Dave Jones Date: Fri Sep 2 14:39:50 2016 -0400 ipv6: release dst in ping_v6_sendmsg [ Upstream commit 03c2778a938aaba0893f6d6cdc29511d91a79848 ] Neither the failure or success paths of ping_v6_sendmsg release the dst it acquires. This leads to a flood of warnings from "net/core/dst.c:288 dst_release" on older kernels that don't have 8bf4ada2e21378816b28205427ee6b0e1ca4c5f1 backported. That patch optimistically hoped this had been fixed post 3.10, but it seems at least one case wasn't, where I've seen this triggered a lot from machines doing unprivileged icmp sockets. Cc: Martin Lau Signed-off-by: Dave Jones Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ae2ca992d99a7f4239ee6453e2d6ba42bac2905b Author: Linus Torvalds Date: Thu Sep 1 14:43:53 2016 -0700 af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock' [ Upstream commit 6e1ce3c3451291142a57c4f3f6f999a29fb5b3bc ] Right now we use the 'readlock' both for protecting some of the af_unix IO path and for making the bind be single-threaded. The two are independent, but using the same lock makes for a nasty deadlock due to ordering with regards to filesystem locking. The bind locking would want to nest outside the VSF pathname locking, but the IO locking wants to nest inside some of those same locks. We tried to fix this earlier with commit c845acb324aa ("af_unix: Fix splice-bind deadlock") which moved the readlock inside the vfs locks, but that caused problems with overlayfs that will then call back into filesystem routines that take the lock in the wrong order anyway. Splitting the locks means that we can go back to having the bind lock be the outermost lock, and we don't have any deadlocks with lock ordering. Acked-by: Rainer Weikusat Acked-by: Al Viro Signed-off-by: Linus Torvalds Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f713ae93dd1a18b36f84bef1ff6fcee24deb5369 Author: Linus Torvalds Date: Thu Sep 1 14:56:49 2016 -0700 Revert "af_unix: Fix splice-bind deadlock" [ Upstream commit 38f7bd94a97b542de86a2be9229289717e33a7a4 ] This reverts commit c845acb324aa85a39650a14e7696982ceea75dc1. It turns out that it just replaces one deadlock with another one: we can still get the wrong lock ordering with the readlock due to overlayfs calling back into the filesystem layer and still taking the vfs locks after the readlock. The proper solution ends up being to just split the readlock into two pieces: the bind lock (taken *outside* the vfs locks) and the IO lock (taken *inside* the filesystem locks). The two locks are independent anyway. Signed-off-by: Linus Torvalds Reviewed-by: Shmulik Ladkani Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3fdf742b7c141dfac1a052b18965743d4b55b31d Author: Mahesh Bandewar Date: Thu Sep 1 22:18:34 2016 -0700 bonding: Fix bonding crash [ Upstream commit 24b27fc4cdf9e10c5e79e5923b6b7c2c5c95096c ] Following few steps will crash kernel - (a) Create bonding master > modprobe bonding miimon=50 (b) Create macvlan bridge on eth2 > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \ type macvlan (c) Now try adding eth2 into the bond > echo +eth2 > /sys/class/net/bond0/bonding/slaves Bonding does lots of things before checking if the device enslaved is busy or not. In this case when the notifier call-chain sends notifications, the bond_netdev_event() assumes that the rx_handler /rx_handler_data is registered while the bond_enslave() hasn't progressed far enough to register rx_handler for the new slave. This patch adds a rx_handler check that can be performed right at the beginning of the enslave code to avoid getting into this situation. Signed-off-by: Mahesh Bandewar Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 581a20a6dac54203f3a5318a747b072cfc5b959b Author: WANG Cong Date: Sun Aug 28 21:28:26 2016 -0700 kcm: fix a socket double free [ Upstream commit c0338aff2260ea6c092806312dbb154cec07a242 ] Dmitry reported a double free on kcm socket, which could be easily reproduced by: #include #include int main() { int fd = syscall(SYS_socket, 0x29ul, 0x5ul, 0x0ul, 0, 0, 0); syscall(SYS_ioctl, fd, 0x89e2ul, 0x20a98000ul, 0, 0, 0); return 0; } This is because on the error path, after we install the new socket file, we call sock_release() to clean up the socket, which leaves the fd pointing to a freed socket. Fix this by calling sys_close() on that fd directly. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Reported-by: Dmitry Vyukov Cc: Tom Herbert Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d13b39d070ef00ca77a9888d535d3f725606d64a Author: Davide Caratti Date: Wed Aug 31 14:16:44 2016 +0200 bridge: re-introduce 'fix parsing of MLDv2 reports' [ Upstream commit 9264251ee2a55bce8fb93826b3f581fb9eb7e2c2 ] commit bc8c20acaea1 ("bridge: multicast: treat igmpv3 report with INCLUDE and no sources as a leave") seems to have accidentally reverted commit 47cc84ce0c2f ("bridge: fix parsing of MLDv2 reports"). This commit brings back a change to br_ip6_multicast_mld2_report() where parsing of MLDv2 reports stops when the first group is successfully added to the MDB cache. Fixes: bc8c20acaea1 ("bridge: multicast: treat igmpv3 report with INCLUDE and no sources as a leave") Signed-off-by: Davide Caratti Acked-by: Nikolay Aleksandrov Acked-by: Thadeu Lima de Souza Cascardo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e9bceeaf9bcf57508e236e20f8fa0127b290269c Author: Russell King Date: Sat Aug 27 17:33:03 2016 +0100 net: smc91x: fix SMC accesses [ Upstream commit 2fb04fdf30192ff1e2b5834e9b7745889ea8bbcb ] Commit b70661c70830 ("net: smc91x: use run-time configuration on all ARM machines") broke some ARM platforms through several mistakes. Firstly, the access size must correspond to the following rule: (a) at least one of 16-bit or 8-bit access size must be supported (b) 32-bit accesses are optional, and may be enabled in addition to the above. Secondly, it provides no emulation of 16-bit accesses, instead blindly making 16-bit accesses even when the platform specifies that only 8-bit is supported. Reorganise smc91x.h so we can make use of the existing 16-bit access emulation already provided - if 16-bit accesses are supported, use 16-bit accesses directly, otherwise if 8-bit accesses are supported, use the provided 16-bit access emulation. If neither, BUG(). This exactly reflects the driver behaviour prior to the commit being fixed. Since the conversion incorrectly cut down the available access sizes on several platforms, we also need to go through every platform and fix up the overly-restrictive access size: Arnd assumed that if a platform can perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access size needed to be specified - not so, all available access sizes must be specified. This likely fixes some performance regressions in doing this: if a platform does not support 8-bit accesses, 8-bit accesses have been emulated by performing a 16-bit read-modify-write access. Tested on the Intel Assabet/Neponset platform, which supports only 8-bit accesses, which was broken by the original commit. Fixes: b70661c70830 ("net: smc91x: use run-time configuration on all ARM machines") Signed-off-by: Russell King Tested-by: Robert Jarzmik Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9cd36c5357af6ccbf065a9995d0134f46d71bd2c Author: Xander Huff Date: Wed Aug 24 16:47:53 2016 -0500 Revert "phy: IRQ cannot be shared" [ Upstream commit c3e70edd7c2eed6acd234627a6007627f5c76e8e ] This reverts: commit 33c133cc7598 ("phy: IRQ cannot be shared") On hardware with multiple PHY devices hooked up to the same IRQ line, allow them to share it. Sergei Shtylyov says: "I'm not sure now what was the reason I concluded that the IRQ sharing was impossible... most probably I thought that the kernel IRQ handling code exited the loop over the IRQ actions once IRQ_HANDLED was returned -- which is obviously not so in reality..." Signed-off-by: Xander Huff Signed-off-by: Nathan Sullivan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 71e5ca1c955c75b8f8f92ed33716132eed5a03ef Author: Florian Fainelli Date: Wed Aug 24 11:01:20 2016 -0700 net: dsa: bcm_sf2: Fix race condition while unmasking interrupts [ Upstream commit 4f101c47791cdcb831b3ef1f831b1cc51e4fe03c ] We kept shadow copies of which interrupt sources we have enabled and disabled, but due to an order bug in how intrl2_mask_clear was defined, we could run into the following scenario: CPU0 CPU1 intrl2_1_mask_clear(..) sets INTRL2_CPU_MASK_CLEAR bcm_sf2_switch_1_isr read INTRL2_CPU_STATUS and masks with stale irq1_mask value updates irq1_mask value Which would make us loop again and again trying to process and interrupt we are not clearing since our copy of whether it was enabled before still indicates it was not. Fix this by updating the shadow copy first, and then unasking at the HW level. Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 17a95e1308c1570bcf15d4248cfc06fb129c6e0e Author: Soheil Hassas Yeganeh Date: Tue Aug 23 18:22:33 2016 -0400 tun: fix transmit timestamp support [ Upstream commit 7b996243fab46092fb3a29c773c54be8152366e4 ] Instead of using sock_tx_timestamp, use skb_tx_timestamp to record software transmit timestamp of a packet. sock_tx_timestamp resets and overrides the tx_flags of the skb. The function is intended to be called from within the protocol layer when creating the skb, not from a device driver. This is inconsistent with other drivers and will cause issues for TCP. In TCP, we intend to sample the timestamps for the last byte for each sendmsg/sendpage. For that reason, tcp_sendmsg calls tcp_tx_timestamp only with the last skb that it generates. For example, if a 128KB message is split into two 64KB packets we want to sample the SND timestamp of the last packet. The current code in the tun driver, however, will result in sampling the SND timestamp for both packets. Also, when the last packet is split into smaller packets for retranmission (see tcp_fragment), the tun driver will record timestamps for all of the retransmitted packets and not only the last packet. Fixes: eda297729171 (tun: Support software transmit time stamping.) Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: Francis Yan Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7a47a811157a6034212e1fb7228a51ce6e9efda Author: Lance Richardson Date: Tue Aug 23 11:40:52 2016 -0400 sctp: fix overrun in sctp_diag_dump_one() [ Upstream commit 232cb53a45965f8789fbf0a9a1962f8c67ab1a3c ] The function sctp_diag_dump_one() currently performs a memcpy() of 64 bytes from a 16 byte field into another 16 byte field. Fix by using correct size, use sizeof to obtain correct size instead of using a hard-coded constant. Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Lance Richardson Reviewed-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4928a5c879ea7f59576edadf5ae66978d12eb771 Author: Eric Dumazet Date: Mon Aug 22 11:31:10 2016 -0700 tcp: properly scale window in tcp_v[46]_reqsk_send_ack() [ Upstream commit 20a2b49fc538540819a0c552877086548cff8d8d ] When sending an ack in SYN_RECV state, we must scale the offered window if wscale option was negotiated and accepted. Tested: Following packetdrill test demonstrates the issue : 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // Establish a connection. +0 < S 0:0(0) win 20000 +0 > S. 0:0(0) ack 1 win 28960 +0 < . 1:11(10) ack 1 win 156 // check that window is properly scaled ! +0 > . 1:1(0) ack 1 win 226 Signed-off-by: Eric Dumazet Cc: Yuchung Cheng Cc: Neal Cardwell Acked-by: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 80f1325549747a4192233f68fe248ec9da6937aa Author: Eric Dumazet Date: Tue Aug 23 13:59:33 2016 -0700 udp: fix poll() issue with zero sized packets [ Upstream commit e83c6744e81abc93a20d0eb3b7f504a176a6126a ] Laura tracked poll() [and friends] regression caused by commit e6afc8ace6dd ("udp: remove headers from UDP packets before queueing") udp_poll() needs to know if there is a valid packet in receive queue, even if its payload length is 0. Change first_packet_length() to return an signed int, and use -1 as the indication of an empty queue. Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing") Reported-by: Laura Abbott Signed-off-by: Eric Dumazet Tested-by: Laura Abbott Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7b25cb6de30f283c3d9609fa7342437bd1edf1f Author: Jamal Hadi Salim Date: Mon Aug 22 07:10:20 2016 -0400 net sched: fix encoding to use real length [ Upstream commit 28a10c426e81afc88514bca8e73affccf850fdf6 ] Encoding of the metadata was using the padded length as opposed to the real length of the data which is a bug per specification. This has not been an issue todate because all metadatum specified so far has been 32 bit where aligned and data length are the same width. This also includes a bug fix for validating the length of a u16 field. But since there is no metadata of size u16 yes we are fine to include it here. While at it get rid of magic numbers. Fixes: ef6980b6becb ("net sched: introduce IFE action") Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 24d2087cf78d29906826e252488ec88b02c31186 Author: Hadar Hen Zion Date: Thu Aug 18 21:09:07 2016 +0300 net/mlx5e: Use correct flow dissector key on flower offloading [ Upstream commit 1dbd0d373ac338903d27fab5204b13122cc5accd ] The wrong key is used when extracting the address type field set by the flower offload code. We have to use the control key and not the basic key, fix that. Fixes: e3a2b7ed018e ('net/mlx5e: Support offload cls_flower with drop action') Signed-off-by: Hadar Hen Zion Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d8b29c3cbef946e97a7e20038eb5fb42d25947f1 Author: Paul Blakey Date: Thu Aug 18 21:09:05 2016 +0300 net/mlx5: Added missing check of msg length in verifying its signature [ Upstream commit 2c0f8ce1b584a4d7b8ff53140d21dfed99834940 ] Set and verify signature calculates the signature for each of the mailbox nodes, even for those that are unused (from cache). Added a missing length check to set and verify only those which are used. While here, also moved the setting of msg's nodes token to where we already go over them. This saves a pass because checksum is disabled, and the only useful thing remaining that set signature does is setting the token. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Paul Blakey Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a53394da7e7a435bc086b17fe0903f248d773933 Author: Mohamad Haj Yahia Date: Thu Aug 18 21:09:04 2016 +0300 net/mlx5: Fix pci error recovery flow [ Upstream commit 1061c90f524963a0a90e7d2f9a6bfa666458af51 ] When PCI error is detected we should save the state of the pci prior to disabling it. Also when receiving pci slot reset call we need to verify that the device is responsive. Fixes: 89d44f0a6c73 ('net/mlx5_core: Add pci error handlers to mlx5_core driver') Signed-off-by: Mohamad Haj Yahia Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7f93c3130e755e2875bc68f9e01878599333433f Author: Eric Dumazet Date: Wed Aug 17 05:56:26 2016 -0700 tcp: fix use after free in tcp_xmit_retransmit_queue() [ Upstream commit bb1fceca22492109be12640d49f5ea5a544c6bb4 ] When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the tail of the write queue using tcp_add_write_queue_tail() Then it attempts to copy user data into this fresh skb. If the copy fails, we undo the work and remove the fresh skb. Unfortunately, this undo lacks the change done to tp->highest_sack and we can leave a dangling pointer (to a freed skb) Later, tcp_xmit_retransmit_queue() can dereference this pointer and access freed memory. For regular kernels where memory is not unmapped, this might cause SACK bugs because tcp_highest_sack_seq() is buggy, returning garbage instead of tp->snd_nxt, but with various debug features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel. This bug was found by Marco Grassi thanks to syzkaller. Fixes: 6859d49475d4 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb") Reported-by: Marco Grassi Signed-off-by: Eric Dumazet Cc: Ilpo Järvinen Cc: Yuchung Cheng Cc: Neal Cardwell Acked-by: Neal Cardwell Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 03b4f8c15b291500d12fe968029414e6301688e3 Author: Vegard Nossum Date: Sat Jul 23 08:15:04 2016 +0200 tipc: fix NULL pointer dereference in shutdown() [ Upstream commit d2fbdf76b85bcdfe57b8ef2ba09d20e8ada79abd ] tipc_msg_create() can return a NULL skb and if so, we shouldn't try to call tipc_node_xmit_skb() on it. general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 3 PID: 30298 Comm: trinity-c0 Not tainted 4.7.0-rc7+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 task: ffff8800baf09980 ti: ffff8800595b8000 task.ti: ffff8800595b8000 RIP: 0010:[] [] tipc_node_xmit_skb+0x6b/0x140 RSP: 0018:ffff8800595bfce8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003023b0e0 RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffffffff83d12580 RBP: ffff8800595bfd78 R08: ffffed000b2b7f32 R09: 0000000000000000 R10: fffffbfff0759725 R11: 0000000000000000 R12: 1ffff1000b2b7f9f R13: ffff8800595bfd58 R14: ffffffff83d12580 R15: dffffc0000000000 FS: 00007fcdde242700(0000) GS:ffff88011af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcddde1db10 CR3: 000000006874b000 CR4: 00000000000006e0 DR0: 00007fcdde248000 DR1: 00007fcddd73d000 DR2: 00007fcdde248000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000090602 Stack: 0000000000000018 0000000000000018 0000000041b58ab3 ffffffff83954208 ffffffff830bb400 ffff8800595bfd30 ffffffff8309d767 0000000000000018 0000000000000018 ffff8800595bfd78 ffffffff8309da1a 00000000810ee611 Call Trace: [] tipc_shutdown+0x553/0x880 [] SyS_shutdown+0x14b/0x170 [] do_syscall_64+0x19c/0x410 [] entry_SYSCALL64_slow_path+0x25/0x25 Code: 90 00 b4 0b 83 c7 00 f1 f1 f1 f1 4c 8d 6d e0 c7 40 04 00 00 00 f4 c7 40 08 f3 f3 f3 f3 48 89 d8 48 c1 e8 03 c7 45 b4 00 00 00 00 <80> 3c 30 00 75 78 48 8d 7b 08 49 8d 75 c0 48 b8 00 00 00 00 00 RIP [] tipc_node_xmit_skb+0x6b/0x140 RSP ---[ end trace 57b0484e351e71f1 ]--- I feel like we should maybe return -ENOMEM or -ENOBUFS, but I'm not sure userspace is equipped to handle that. Anyway, this is better than a GPF and looks somewhat consistent with other tipc_msg_create() callers. Signed-off-by: Vegard Nossum Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 33251f9f4bb82811261c52c266e1bb8a31a88663 Author: Mike Manning Date: Fri Aug 12 12:02:38 2016 +0100 net: ipv6: Do not keep IPv6 addresses when IPv6 is disabled [ Upstream commit bc561632dddd5af0c4444d919f01cbf6d553aa0a ] If IPv6 is disabled when the option is set to keep IPv6 addresses on link down, userspace is unaware of this as there is no such indication via netlink. The solution is to remove the IPv6 addresses in this case, which results in netlink messages indicating removal of addresses in the usual manner. This fix also makes the behavior consistent with the case of having IPv6 disabled first, which stops IPv6 addresses from being added. Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") Signed-off-by: Mike Manning Acked-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b200d3a9ae76e764ee622761d87c7d521ed6c198 Author: Vegard Nossum Date: Fri Aug 12 09:50:51 2016 +0200 net/sctp: always initialise sctp_ht_iter::start_fail [ Upstream commit 54236ab09e9696a27baaae693c288920a26e8588 ] sctp_transport_seq_start() does not currently clear iter->start_fail on success, but relies on it being zero when it is allocated (by seq_open_net()). This can be a problem in the following sequence: open() // allocates iter (and implicitly sets iter->start_fail = 0) read() - iter->start() // fails and sets iter->start_fail = 1 - iter->stop() // doesn't call sctp_transport_walk_stop() (correct) read() again - iter->start() // succeeds, but doesn't change iter->start_fail - iter->stop() // doesn't call sctp_transport_walk_stop() (wrong) We should initialize sctp_ht_iter::start_fail to zero if ->start() succeeds, otherwise it's possible that we leave an old value of 1 there, which will cause ->stop() to not call sctp_transport_walk_stop(), which causes all sorts of problems like not calling rcu_read_unlock() (and preempt_enable()), eventually leading to more warnings like this: BUG: sleeping function called from invalid context at mm/slab.h:388 in_atomic(): 0, irqs_disabled(): 0, pid: 16551, name: trinity-c2 Preemption disabled at:[] rhashtable_walk_start+0x46/0x150 [] preempt_count_add+0x1fb/0x280 [] _raw_spin_lock+0x12/0x40 [] rhashtable_walk_start+0x46/0x150 [] sctp_transport_walk_start+0x2f/0x60 [] sctp_transport_seq_start+0x4d/0x150 [] traverse+0x170/0x850 [] seq_read+0x7cc/0x1180 [] proc_reg_read+0xbc/0x180 [] do_loop_readv_writev+0x134/0x210 [] do_readv_writev+0x565/0x660 [] vfs_readv+0x67/0xa0 [] do_preadv+0x126/0x170 [] SyS_preadv+0xc/0x10 [] do_syscall_64+0x19c/0x410 [] return_from_SYSCALL_64+0x0/0x6a [] 0xffffffffffffffff Notice that this is a subtly different stacktrace from the one in commit 5fc382d875 ("net/sctp: terminate rhashtable walk correctly"). Cc: Xin Long Cc: Herbert Xu Cc: Eric W. Biederman Cc: Marcelo Ricardo Leitner Signed-off-by: Vegard Nossum Acked-By: Neil Horman Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7642679c1d473706032708ed83077082c8fb75ef Author: Vegard Nossum Date: Fri Aug 12 10:29:13 2016 +0200 net/irda: handle iriap_register_lsap() allocation failure [ Upstream commit 5ba092efc7ddff040777ae7162f1d195f513571b ] If iriap_register_lsap() fails to allocate memory, self->lsap is set to NULL. However, none of the callers handle the failure and irlmp_connect_request() will happily dereference it: iriap_register_lsap: Unable to allocated LSAP! ================================================================================ UBSAN: Undefined behaviour in net/irda/irlmp.c:378:2 member access within null pointer of type 'struct lsap_cb' CPU: 1 PID: 15403 Comm: trinity-c0 Not tainted 4.8.0-rc1+ #81 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 0000000000000000 ffff88010c7e78a8 ffffffff82344f40 0000000041b58ab3 ffffffff84f98000 ffffffff82344e94 ffff88010c7e78d0 ffff88010c7e7880 ffff88010630ad00 ffffffff84a5fae0 ffffffff84d3f5c0 000000000000017a Call Trace: [] dump_stack+0xac/0xfc [] ubsan_epilogue+0xd/0x8a [] __ubsan_handle_type_mismatch+0x157/0x411 [] irlmp_connect_request+0x7ac/0x970 [] iriap_connect_request+0xa0/0x160 [] state_s_disconnect+0x88/0xd0 [] iriap_do_client_event+0x94/0x120 [] iriap_getvaluebyclass_request+0x3e0/0x6d0 [] irda_find_lsap_sel+0x1eb/0x630 [] irda_connect+0x828/0x12d0 [] SYSC_connect+0x22b/0x340 [] SyS_connect+0x9/0x10 [] do_syscall_64+0x1b3/0x4b0 [] entry_SYSCALL64_slow_path+0x25/0x25 ================================================================================ The bug seems to have been around since forever. There's more problems with missing error checks in iriap_init() (and indeed all of irda_init()), but that's a bigger problem that needs very careful review and testing. This patch will fix the most serious bug (as it's easily reached from unprivileged userspace). I have tested my patch with a reproducer. Signed-off-by: Vegard Nossum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af5a13a6ef59da7938682cd2a830726288ef03d7 Author: Daniel Borkmann Date: Thu Aug 11 21:38:37 2016 +0200 bpf: fix write helpers with regards to non-linear parts [ Upstream commit 0ed661d5a48fa6df0b50ae64d27fe759a3ce42cf ] Fix the bpf_try_make_writable() helper and all call sites we have in BPF, it's currently defect with regards to skbs when the write_len spans into non-linear parts, no matter if cloned or not. There are multiple issues at once. First, using skb_store_bits() is not correct since even if we have a cloned skb, page frags can still be shared. To really make them private, we need to pull them in via __pskb_pull_tail() first, which also gets us a private head via pskb_expand_head() implicitly. This is for helpers like bpf_skb_store_bytes(), bpf_l3_csum_replace(), bpf_l4_csum_replace(). Really, the only thing reasonable and working here is to call skb_ensure_writable() before any write operation. Meaning, via pskb_may_pull() it makes sure that parts we want to access are pulled in and if not does so plus unclones the skb implicitly. If our write_len still fits the headlen and we're cloned and our header of the clone is not writable, then we need to make a private copy via pskb_expand_head(). skb_store_bits() is a bit misleading and only safe to store into non-linear data in different contexts such as 357b40a18b04 ("[IPV6]: IPV6_CHECKSUM socket option can corrupt kernel memory"). For above BPF helper functions, it means after fixed bpf_try_make_writable(), we've pulled in enough, so that we operate always based on skb->data. Thus, the call to skb_header_pointer() and skb_store_bits() becomes superfluous. In bpf_skb_store_bytes(), the len check is unnecessary too since it can only pass in maximum of BPF stack size, so adding offset is guaranteed to never overflow. Also bpf_l3/4_csum_replace() helpers must test for proper offset alignment since they use __sum16 pointer for writing resulting csum. The remaining helpers that change skb data not discussed here yet are bpf_skb_vlan_push(), bpf_skb_vlan_pop() and bpf_skb_change_proto(). The vlan helpers internally call either skb_ensure_writable() (pop case) and skb_cow_head() (push case, for head expansion), respectively. Similarly, bpf_skb_proto_xlat() takes care to not mangle page frags. Fixes: 608cd71a9c7c ("tc: bpf: generalize pedit action") Fixes: 91bc4822c3d6 ("tc: bpf: add checksum helpers") Fixes: 3697649ff29e ("bpf: try harder on clones when writing into skb") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8a452ed38f55e7063f3a02434e22fce54084f7c Author: Lance Richardson Date: Tue Aug 9 15:29:42 2016 -0400 vti: flush x-netns xfrm cache when vti interface is removed [ Upstream commit a5d0dc810abf3d6b241777467ee1d6efb02575fc ] When executing the script included below, the netns delete operation hangs with the following message (repeated at 10 second intervals): kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 This occurs because a reference to the lo interface in the "secure" netns is still held by a dst entry in the xfrm bundle cache in the init netns. Address this problem by garbage collecting the tunnel netns flow cache when a cross-namespace vti interface receives a NETDEV_DOWN notification. A more detailed description of the problem scenario (referencing commands in the script below): (1) ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1 The vti_test interface is created in the init namespace. vti_tunnel_init() attaches a struct ip_tunnel to the vti interface's netdev_priv(dev), setting the tunnel net to &init_net. (2) ip link set vti_test netns secure The vti_test interface is moved to the "secure" netns. Note that the associated struct ip_tunnel still has tunnel->net set to &init_net. (3) ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1 The first packet sent using the vti device causes xfrm_lookup() to be called as follows: dst = xfrm_lookup(tunnel->net, skb_dst(skb), fl, NULL, 0); Note that tunnel->net is the init namespace, while skb_dst(skb) references the vti_test interface in the "secure" namespace. The returned dst references an interface in the init namespace. Also note that the first parameter to xfrm_lookup() determines which flow cache is used to store the computed xfrm bundle, so after xfrm_lookup() returns there will be a cached bundle in the init namespace flow cache with a dst referencing a device in the "secure" namespace. (4) ip netns del secure Kernel begins to delete the "secure" namespace. At some point the vti_test interface is deleted, at which point dst_ifdown() changes the dst->dev in the cached xfrm bundle flow from vti_test to lo (still in the "secure" namespace however). Since nothing has happened to cause the init namespace's flow cache to be garbage collected, this dst remains attached to the flow cache, so the kernel loops waiting for the last reference to lo to go away. ip link add br1 type bridge ip link set dev br1 up ip addr add dev br1 1.1.1.1/8 ip netns add secure ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1 ip link set vti_test netns secure ip netns exec secure ip link set vti_test up ip netns exec secure ip link s lo up ip netns exec secure ip addr add dev lo 192.168.100.1/24 ip netns exec secure ip route add 192.168.200.0/24 dev vti_test ip xfrm policy flush ip xfrm state flush ip xfrm policy add dir out tmpl src 1.1.1.1 dst 1.1.1.2 \ proto esp mode tunnel mark 1 ip xfrm policy add dir in tmpl src 1.1.1.2 dst 1.1.1.1 \ proto esp mode tunnel mark 1 ip xfrm state add src 1.1.1.1 dst 1.1.1.2 proto esp spi 1 \ mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788 ip xfrm state add src 1.1.1.2 dst 1.1.1.1 proto esp spi 1 \ mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788 ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1 ip netns del secure Reported-by: Hangbin Liu Reported-by: Jan Tluka Signed-off-by: Lance Richardson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8eb722f4275e70776f1bb037e5351d352142b6b0 Author: David Forster Date: Wed Aug 3 15:13:01 2016 +0100 ipv4: panic in leaf_walk_rcu due to stale node pointer [ Upstream commit 94d9f1c5906b20053efe375b6d66610bca4b8b64 ] Panic occurs when issuing "cat /proc/net/route" whilst populating FIB with > 1M routes. Use of cached node pointer in fib_route_get_idx is unsafe. BUG: unable to handle kernel paging request at ffffc90001630024 IP: [] leaf_walk_rcu+0x10/0xe0 PGD 11b08d067 PUD 11b08e067 PMD dac4b067 PTE 0 Oops: 0000 [#1] SMP Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscac snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep virti acpi_cpufreq button parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd tio_ring virtio floppy uhci_hcd ehci_hcd usbcore usb_common libata scsi_mod CPU: 1 PID: 785 Comm: cat Not tainted 4.2.0-rc8+ #4 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 task: ffff8800da1c0bc0 ti: ffff88011a05c000 task.ti: ffff88011a05c000 RIP: 0010:[] [] leaf_walk_rcu+0x10/0xe0 RSP: 0018:ffff88011a05fda0 EFLAGS: 00010202 RAX: ffff8800d8a40c00 RBX: ffff8800da4af940 RCX: ffff88011a05ff20 RDX: ffffc90001630020 RSI: 0000000001013531 RDI: ffff8800da4af950 RBP: 0000000000000000 R08: ffff8800da1f9a00 R09: 0000000000000000 R10: ffff8800db45b7e4 R11: 0000000000000246 R12: ffff8800da4af950 R13: ffff8800d97a74c0 R14: 0000000000000000 R15: ffff8800d97a7480 FS: 00007fd3970e0700(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffc90001630024 CR3: 000000011a7e4000 CR4: 00000000000006e0 Stack: ffffffff814d00d3 0000000000000000 ffff88011a05ff20 ffff8800da1f9a00 ffffffff811dd8b9 0000000000000800 0000000000020000 00007fd396f35000 ffffffff811f8714 0000000000003431 ffffffff8138dce0 0000000000000f80 Call Trace: [] ? fib_route_seq_start+0x93/0xc0 [] ? seq_read+0x149/0x380 [] ? fsnotify+0x3b4/0x500 [] ? process_echoes+0x70/0x70 [] ? proc_reg_read+0x47/0x70 [] ? __vfs_read+0x23/0xd0 [] ? rw_verify_area+0x52/0xf0 [] ? vfs_read+0x81/0x120 [] ? SyS_read+0x42/0xa0 [] ? entry_SYSCALL_64_fastpath+0x16/0x75 Code: 48 85 c0 75 d8 f3 c3 31 c0 c3 f3 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 a 04 89 f0 33 02 44 89 c9 48 d3 e8 0f b6 4a 05 49 89 RIP [] leaf_walk_rcu+0x10/0xe0 RSP CR2: ffffc90001630024 Signed-off-by: Dave Forster Acked-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d8e294b0879dd2240e1582ae98c7b0d37571d474 Author: Jakub Kicinski Date: Tue Aug 2 16:12:14 2016 +0100 bpf: fix method of PTR_TO_PACKET reg id generation [ Upstream commit 1f415a74b0ca64b5bfacbb12d71ed2ec050a8cfb ] Using per-register incrementing ID can lead to find_good_pkt_pointers() confusing registers which have completely different values. Consider example: 0: (bf) r6 = r1 1: (61) r8 = *(u32 *)(r6 +76) 2: (61) r0 = *(u32 *)(r6 +80) 3: (bf) r7 = r8 4: (07) r8 += 32 5: (2d) if r8 > r0 goto pc+9 R0=pkt_end R1=ctx R6=ctx R7=pkt(id=0,off=0,r=32) R8=pkt(id=0,off=32,r=32) R10=fp 6: (bf) r8 = r7 7: (bf) r9 = r7 8: (71) r1 = *(u8 *)(r7 +0) 9: (0f) r8 += r1 10: (71) r1 = *(u8 *)(r7 +1) 11: (0f) r9 += r1 12: (07) r8 += 32 13: (2d) if r8 > r0 goto pc+1 R0=pkt_end R1=inv56 R6=ctx R7=pkt(id=0,off=0,r=32) R8=pkt(id=1,off=32,r=32) R9=pkt(id=1,off=0,r=32) R10=fp 14: (71) r1 = *(u8 *)(r9 +16) 15: (b7) r7 = 0 16: (bf) r0 = r7 17: (95) exit We need to get a UNKNOWN_VALUE with imm to force id generation so lines 0-5 make r7 a valid packet pointer. We then read two different bytes from the packet and add them to copies of the constructed packet pointer. r8 (line 9) and r9 (line 11) will get the same id of 1, independently. When either of them is validated (line 13) - find_good_pkt_pointers() will also mark the other as safe. This leads to access on line 14 being mistakenly considered safe. Fixes: 969bf05eb3ce ("bpf: direct packet access") Signed-off-by: Jakub Kicinski Acked-by: Alexei Starovoitov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8509ce12df9d26b6ec4e6d5aa3b541803da60e2 Author: Rob Clark Date: Mon Aug 22 15:28:38 2016 -0400 drm/msm: protect against faults from copy_from_user() in submit ioctl commit d78d383ab354b0b9e1d23404ae0d9fbdeb9aa035 upstream. An evil userspace could try to cause deadlock by passing an unfaulted-in GEM bo as submit->bos (or submit->cmds) table. Which will trigger msm_gem_fault() while we already hold struct_mutex. See: https://github.com/freedreno/msmtest/blob/master/evilsubmittest.c Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 399c967d80f1dfc8273a3831d73a9f06daa4b1bc Author: Eric Biggers Date: Thu Sep 8 14:20:38 2016 -0700 fscrypto: require write access to mount to set encryption policy commit ba63f23d69a3a10e7e527a02702023da68ef8a6d upstream. Since setting an encryption policy requires writing metadata to the filesystem, it should be guarded by mnt_want_write/mnt_drop_write. Otherwise, a user could cause a write to a frozen or readonly filesystem. This was handled correctly by f2fs but not by ext4. Make fscrypt_process_policy() handle it rather than relying on the filesystem to get it right. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Acked-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 452d0179f4f8da420c4a1288e0865b21d263d65a Author: James Hogan Date: Fri Aug 19 14:30:29 2016 +0100 MIPS: KVM: Check for pfn noslot case commit ba913e4f72fc9cfd03dad968dfb110eb49211d80 upstream. When mapping a page into the guest we error check using is_error_pfn(), however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an error HVA for the page. This can only happen on MIPS right now due to unusual memslot management (e.g. being moved / removed / resized), or with an Enhanced Virtual Memory (EVA) configuration where the default KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed in a later patch). This case will be treated as a pfn of zero, mapping the first page of physical memory into the guest. It would appear the MIPS KVM port wasn't updated prior to being merged (in v3.10) to take commit 81c52c56e2b4 ("KVM: do not treat noslot pfn as a error pfn") into account (merged v3.8), which converted a bunch of is_error_pfn() calls to is_error_noslot_pfn(). Switch to using is_error_noslot_pfn() instead to catch this case properly. Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini [james.hogan@imgtec.com: Backport to v4.7.y] Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 28375171dbccdfbe8e76f2890e1acb81cb00d4d7 Author: Chen-Yu Tsai Date: Thu Aug 25 14:26:59 2016 +0800 clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e upstream. 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. Signed-off-by: Chen-Yu Tsai Signed-off-by: Daniel Lezcano Acked-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman