commit e6a2ab837b00f1f0ccbc920537ca9fb653591dfd Author: Ben Hutchings Date: Thu Oct 12 15:28:25 2017 +0100 Linux 3.16.49 commit ab736e2d74b71728f5ddab988730e8e346d16ff4 Author: Mikulas Patocka Date: Wed Feb 15 11:26:10 2017 -0500 dm: flush queued bios when process blocks to avoid deadlock commit d67a5f4b5947aba4bfe9a80a2b86079c215ca755 upstream. Commit df2cb6daa4 ("block: Avoid deadlocks with bio allocation by stacking drivers") created a workqueue for every bio set and code in bio_alloc_bioset() that tries to resolve some low-memory deadlocks by redirecting bios queued on current->bio_list to the workqueue if the system is low on memory. However other deadlocks (see below **) may happen, without any low memory condition, because generic_make_request is queuing bios to current->bio_list (rather than submitting them). ** the related dm-snapshot deadlock is detailed here: https://www.redhat.com/archives/dm-devel/2016-July/msg00065.html Fix this deadlock by redirecting any bios on current->bio_list to the bio_set's rescue workqueue on every schedule() call. Consequently, when the process blocks on a mutex, the bios queued on current->bio_list are dispatched to independent workqueus and they can complete without waiting for the mutex to be available. The structure blk_plug contains an entry cb_list and this list can contain arbitrary callback functions that are called when the process blocks. To implement this fix DM (ab)uses the onstack plug's cb_list interface to get its flush_current_bio_list() called at schedule() time. This fixes the snapshot deadlock - if the map method blocks, flush_current_bio_list() will be called and it redirects bios waiting on current->bio_list to appropriate workqueues. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1267650 Depends-on: df2cb6daa4 ("block: Avoid deadlocks with bio allocation by stacking drivers") Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Ben Hutchings commit d1cadb6597bea8e6644328a98282643570cb8a13 Author: Zefan Li Date: Thu Sep 25 09:41:02 2014 +0800 cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags commit 2ad654bc5e2b211e92f66da1d819e47d79a866f0 upstream. When we change cpuset.memory_spread_{page,slab}, cpuset will flip PF_SPREAD_{PAGE,SLAB} bit of tsk->flags for each task in that cpuset. This should be done using atomic bitops, but currently we don't, which is broken. Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happened when one thread tried to clear PF_USED_MATH while at the same time another thread tried to flip PF_SPREAD_PAGE/PF_SPREAD_SLAB. They both operate on the same task. Here's the full report: https://lkml.org/lkml/2014/9/19/230 To fix this, we make PF_SPREAD_PAGE and PF_SPREAD_SLAB atomic flags. v4: - updated mm/slab.c. (Fengguang Wu) - updated Documentation. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Miao Xie Cc: Kees Cook Fixes: 950592f7b991 ("cpusets: update tasks' page/slab spread flags in time") Reported-by: Tetsuo Handa Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit ed7b1fae294e7517e60449a237cca4b6730aa4af Author: Zefan Li Date: Thu Sep 25 09:40:40 2014 +0800 sched: add macros to define bitops for task atomic flags commit e0e5070b20e01f0321f97db4e4e174f3f6b49e50 upstream. This will simplify code when we add new flags. v3: - Kees pointed out that no_new_privs should never be cleared, so we shouldn't define task_clear_no_new_privs(). we define 3 macros instead of a single one. v2: - updated scripts/tags.sh, suggested by Peter Cc: Ingo Molnar Cc: Miao Xie Cc: Tetsuo Handa Acked-by: Peter Zijlstra (Intel) Acked-by: Kees Cook Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit d0999b1d09e6dc09bfcce638bbac6b582b85ad5d Author: Zefan Li Date: Thu Sep 25 09:40:17 2014 +0800 sched: fix confusing PFA_NO_NEW_PRIVS constant commit a2b86f772227bcaf962c8b134f8d187046ac5f0e upstream. Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags") defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing because it is used as bit number. Redefine it as decimal bit number. Note this changes the bit position of PFA_NOW_NEW_PRIVS from 1 to 0. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Miao Xie Signed-off-by: Tetsuo Handa Acked-by: Kees Cook [ lizf: slightly modified subject and changelog ] Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 5f3333219189a3fe4bbbd2d67e636ed1bb74d243 Author: Kees Cook Date: Wed May 21 15:23:46 2014 -0700 sched: move no_new_privs into new atomic flags commit 1d4457f99928a968767f6405b4a1f50845aa15fd upstream. Since seccomp transitions between threads requires updates to the no_new_privs flag to be atomic, the flag must be part of an atomic flag set. This moves the nnp flag into a separate task field, and introduces accessors. Signed-off-by: Kees Cook Reviewed-by: Oleg Nesterov Reviewed-by: Andy Lutomirski [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 9e839401a65a30d15cbe9a1255640cd5ce2b548d Author: Sachin Prabhu Date: Wed Apr 26 14:05:46 2017 +0100 Fix match_prepath() commit cd8c42968ee651b69e00f8661caff32b0086e82d upstream. Incorrect return value for shares not using the prefix path means that we will never match superblocks for these shares. Fixes: commit c1d8b24d1819 ("Compare prepaths when comparing superblocks") Signed-off-by: Sachin Prabhu Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Cc: Aurélien Aptel Signed-off-by: Ben Hutchings commit 1d14078e5ba5745286c87a61d8c80f0defb77ae8 Author: Sachin Prabhu Date: Tue Sep 6 13:22:34 2016 +0100 Fix regression which breaks DFS mounting commit d171356ff11ab1825e456dfb979755e01b3c54a1 upstream. Patch a6b5058 results in -EREMOTE returned by is_path_accessible() in cifs_mount() to be ignored which breaks DFS mounting. Signed-off-by: Sachin Prabhu Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit fa0b39f071686a6c940fd175a99ff543fa88ce4b Author: Sachin Prabhu Date: Fri Jul 29 22:38:21 2016 +0100 Move check for prefix path to within cifs_get_root() commit 348c1bfa84dfc47da1f1234b7f2bf09fa798edea upstream. Signed-off-by: Sachin Prabhu Tested-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit f204fa8b8d4809edc87cf137ba684fbfd03b7c1c Author: Sachin Prabhu Date: Fri Jul 29 22:38:20 2016 +0100 Compare prepaths when comparing superblocks commit c1d8b24d18192764fe82067ec6aa8d4c3bf094e0 upstream. The patch fs/cifs: make share unaccessible at root level mountable makes use of prepaths when any component of the underlying path is inaccessible. When mounting 2 separate shares having different prepaths but are other wise similar in other respects, we end up sharing superblocks when we shouldn't be doing so. Signed-off-by: Sachin Prabhu Tested-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit 5726cde9e952226754e150b999441a6cdd6d566e Author: Sachin Prabhu Date: Fri Jul 29 22:38:19 2016 +0100 Fix memory leaks in cifs_do_mount() commit 4214ebf4654798309364d0c678b799e402f38288 upstream. Fix memory leaks introduced by the patch fs/cifs: make share unaccessible at root level mountable Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb(). Signed-off-by: Sachin Prabhu Tested-by: Aurelien Aptel Signed-off-by: Steve French [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit a2b22f20316fa2b6a523089c9348bec6c95d833e Author: Aurelien Aptel Date: Wed May 25 19:59:09 2016 +0200 fs/cifs: make share unaccessible at root level mountable commit a6b5058fafdf508904bbf16c29b24042cef3c496 upstream. if, when mounting //HOST/share/sub/dir/foo we can query /sub/dir/foo but not any of the path components above: - store the /sub/dir/foo prefix in the cifs super_block info - in the superblock, set root dentry to the subpath dentry (instead of the share root) - set a flag in the superblock to remember it - use prefixpath when building path from a dentry fixes bso#8950 Signed-off-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French [bwh: Backported to 3.16: use Jiri Slaby's backport of the change in cifs_root_iget()] Signed-off-by: Ben Hutchings commit f747d99ca6b0100f8978a52f24590542feae25d5 Author: Stephen Hemminger Date: Sun Oct 23 21:32:47 2016 -0700 netvsc: fix incorrect receive checksum offloading commit e52fed7177f74382f742c27de2cc5314790aebb6 upstream. The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 3da79d050156fdd0dd1733f82e8eeec15109fa9a Author: Tomer Barletz Date: Sun Aug 2 02:08:57 2015 -0700 ALSA: oxygen: Fix logical-not-parentheses warning commit 8ec7cfce3762299ae289c384e281b2f4010ae231 upstream. This fixes the following warning, that is seen with gcc 5.1: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]. Signed-off-by: Tomer Barletz Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 3a4986abaaff615bd1277cedd1b4e68e66ae9c7c Author: Simon Horman Date: Fri Dec 11 11:30:12 2015 +0900 PCI: Limit config space size for Netronome NFP4000 commit c2e771b02792d222cbcd9617fe71482a64f52647 upstream. Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP4000's PF's config space size to 0x600 bytes as is already done for the NFP6000. The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit a2da5ffb14385e167ed4a815e02a2f0ffcfd5995 Author: Simon Horman Date: Fri Dec 11 11:30:11 2015 +0900 PCI: Add Netronome NFP4000 PF device ID commit 69874ec233871a62e1bc8c89e643993af93a8630 upstream. Add the device ID for the PF of the NFP4000. The device ID for the VF, 0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF. Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit 86f5c4bca0c767c613fbf6bd66c26bc4e2d9fbdd Author: Jason S. McMullan Date: Wed Sep 30 15:35:07 2015 +0900 PCI: Limit config space size for Netronome NFP6000 family commit 9f33a2ae59f24452c1076749deb615bccd435ca9 upstream. The NFP6000 has an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP6000's config space size to 0x600 bytes. Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit 5fa2b7b00900a686d13fc6a28258d6c3529d28c7 Author: Jason S. McMullan Date: Wed Sep 30 15:35:06 2015 +0900 PCI: Add Netronome vendor and device IDs commit a755e169031dac9ebaed03302c4921687c271d62 upstream. Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV devices. Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit 17e9bf7c3baba5000d47b83e3b9e6062c080806e Author: Jason S. McMullan Date: Wed Sep 30 15:35:05 2015 +0900 PCI: Support PCIe devices with short cfg_size commit c20aecf6963d1273d8f6d61c042b4845441ca592 upstream. If a device quirk modifies the pci_dev->cfg_size to be less than PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256), the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE. Allow sysfs access to config space up to cfg_size, even if the device doesn't support the entire 4096-byte PCIe config space. Note that pci_read_config() and pci_write_config() limit access to dev->cfg_size even though pcie_config_attr contains 4096 (the maximum size). Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman [bhelgaas: more changelog edits] Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit af84302a01a814250cfcfb86628349a827497779 Author: Andrea Arcangeli Date: Fri Feb 26 15:19:28 2016 -0800 mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED commit ad33bb04b2a6cee6c1f99fabb15cddbf93ff0433 upstream. pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were introduced to locklessy (but atomically) detect when a pmd is a regular (stable) pmd or when the pmd is unstable and can infinitely transition from pmd_none() and pmd_trans_huge() from under us, while only holding the mmap_sem for reading (for writing not). While holding the mmap_sem only for reading, MADV_DONTNEED can run from under us and so before we can assume the pmd to be a regular stable pmd we need to compare it against pmd_none() and pmd_trans_huge() in an atomic way, with pmd_trans_unstable(). The old pmd_trans_huge() left a tiny window for a race. Useful applications are unlikely to notice the difference as doing MADV_DONTNEED concurrently with a page fault would lead to undefined behavior. [akpm@linux-foundation.org: tidy up comment grammar/layout] Signed-off-by: Andrea Arcangeli Reported-by: Kirill A. Shutemov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [js] 3.12 backport: no pmd_devmap in 3.12 yet. Signed-off-by: Jiri Slaby Signed-off-by: Ben Hutchings commit 784154f4c908fd35a316ea07c8ca82862beb4008 Author: Jan Willeke Date: Tue Jul 22 16:50:57 2014 +0200 s390/seccomp: fix error return for filtered system calls commit dc295880c6752076f8b94ba3885d0bfff09e3e82 upstream. The syscall_set_return_value function of s390 negates the error argument before storing the value to the return register gpr2. This is incorrect, the seccomp code already passes the negative error value. Store the unmodified error value to gpr2. Signed-off-by: Jan Willeke Signed-off-by: Martin Schwidefsky Cc: Michael Holzheu Signed-off-by: Ben Hutchings commit 28d6e14b806eca38dfa973e798e16b96b6f13fe7 Author: Lukasz Odzioba Date: Fri Jun 24 14:50:01 2016 -0700 mm/swap.c: flush lru pvecs on compound page arrival commit 8f182270dfec432e93fae14f9208a6b9af01009f upstream. Currently we can have compound pages held on per cpu pagevecs, which leads to a lot of memory unavailable for reclaim when needed. In the systems with hundreads of processors it can be GBs of memory. On of the way of reproducing the problem is to not call munmap explicitly on all mapped regions (i.e. after receiving SIGTERM). After that some pages (with THP enabled also huge pages) may end up on lru_add_pvec, example below. void main() { #pragma omp parallel { size_t size = 55 * 1000 * 1000; // smaller than MEM/CPUS void *p = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS , -1, 0); if (p != MAP_FAILED) memset(p, 0, size); //munmap(p, size); // uncomment to make the problem go away } } When we run it with THP enabled it will leave significant amount of memory on lru_add_pvec. This memory will be not reclaimed if we hit OOM, so when we run above program in a loop: for i in `seq 100`; do ./a.out; done many processes (95% in my case) will be killed by OOM. The primary point of the LRU add cache is to save the zone lru_lock contention with a hope that more pages will belong to the same zone and so their addition can be batched. The huge page is already a form of batched addition (it will add 512 worth of memory in one go) so skipping the batching seems like a safer option when compared to a potential excess in the caching which can be quite large and much harder to fix because lru_add_drain_all is way to expensive and it is not really clear what would be a good moment to call it. Similarly we can reproduce the problem on lru_deactivate_pvec by adding: madvise(p, size, MADV_FREE); after memset. This patch flushes lru pvecs on compound page arrival making the problem less severe - after applying it kill rate of above example drops to 0%, due to reducing maximum amount of memory held on pvec from 28MB (with THP) to 56kB per CPU. Suggested-by: Michal Hocko Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com Signed-off-by: Lukasz Odzioba Acked-by: Michal Hocko Cc: Kirill Shutemov Cc: Andrea Arcangeli Cc: Vladimir Davydov Cc: Ming Li Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: - Drop change in deactivate_file_page() - Adjust context] Signed-off-by: Ben Hutchings commit 34cb9ae07fdb864108f90fd958efe907dee34122 Author: Mark Rutland Date: Tue Mar 1 14:18:50 2016 +0000 arm64: Rework valid_user_regs commit dbd4d7ca563fd0a8949718d35ce197e5642d5d9d upstream. We validate pstate using PSR_MODE32_BIT, which is part of the user-provided pstate (and cannot be trusted). Also, we conflate validation of AArch32 and AArch64 pstate values, making the code difficult to reason about. Instead, validate the pstate value based on the associated task. The task may or may not be current (e.g. when using ptrace), so this must be passed explicitly by callers. To avoid circular header dependencies via sched.h, is_compat_task is pulled out of asm/ptrace.h. To make the code possible to reason about, the AArch64 and AArch32 validation is split into separate functions. Software must respect the RES0 policy for SPSR bits, and thus the kernel mirrors the hardware policy (RAZ/WI) for bits as-yet unallocated. When these acquire an architected meaning writes may be permitted (potentially with additional validation). Signed-off-by: Mark Rutland Acked-by: Will Deacon Cc: Dave Martin Cc: James Morse Cc: Peter Maydell Signed-off-by: Catalin Marinas [ rebased for v3.16 v3.16 does not support SETEND, support for this was added by 2d888f48e056 ("arm64: Emulate SETEND for AArch32 tasks") in v3.20 This backport forces the kernel endianness on userspace. Added a DBG_SPSR_SS define hidden by #ifdefs to avoid conflicts with other backports. ] Signed-off-by: James Morse Signed-off-by: Ben Hutchings commit ff7079dbcd4bda977d6328050194439d81ce5f99 Author: James Hogan Date: Thu Jun 9 10:50:43 2016 +0100 MIPS: KVM: Fix modular KVM under QEMU commit 797179bc4fe06c89e47a9f36f886f68640b423f8 upstream. Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never get a TLB refill exception in it when KVM is built as a module. This was observed to happen with the host MIPS kernel running under QEMU, due to a not entirely transparent optimisation in the QEMU TLB handling where TLB entries replaced with TLBWR are copied to a separate part of the TLB array. Code in those pages continue to be executable, but those mappings persist only until the next ASID switch, even if they are marked global. An ASID switch happens in __kvm_mips_vcpu_run() at exception level after switching to the guest exception base. Subsequent TLB mapped kernel instructions just prior to switching to the guest trigger a TLB refill exception, which enters the guest exception handlers without updating EPC. This appears as a guest triggered TLB refill on a host kernel mapped (host KSeg2) address, which is not handled correctly as user (guest) mode accesses to kernel (host) segments always generate address error exceptions. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Ralf Baechle Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Signed-off-by: Paolo Bonzini [james.hogan@imgtec.com: backported for stable 3.14] Signed-off-by: James Hogan Signed-off-by: Ben Hutchings commit 03dd4e8129827e593b99abbe1feb3eb6f4d8138b Author: Javier Martinez Canillas Date: Thu Jul 30 18:18:30 2015 +0200 macintosh/therm_windtunnel: Export I2C module alias information commit cb0eefcc3271ea1d370476dd29685918b99c5a9f upstream. The I2C core always reports the MODALIAS uevent as "i2c: Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit bdfa07090b4fe416e7f3c3a3c3c8d612e4c3033a Author: Andrey Ryabinin Date: Wed May 11 16:51:51 2016 +0300 perf/x86: Fix undefined shift on 32-bit kernels commit 6d6f2833bfbf296101f9f085e10488aef2601ba5 upstream. Jim reported: UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12 shift exponent 35 is too large for 32-bit type 'long unsigned int' The use of 'unsigned long' type obviously is not correct here, make it 'unsigned long long' instead. Reported-by: Jim Cromie Signed-off-by: Andrey Ryabinin Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: H. Peter Anvin Cc: Imre Palik Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 2c33645d366d ("perf/x86: Honor the architectural performance monitoring version") Link: http://lkml.kernel.org/r/1462974711-10037-1-git-send-email-aryabinin@virtuozzo.com Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 7b3c424bda29843c33d0596c90dc3c1399284c89 Author: Palik, Imre Date: Mon Jun 8 14:46:49 2015 +0200 perf/x86: Honor the architectural performance monitoring version commit 2c33645d366d13b969d936b68b9f4875b1fdddea upstream. Architectural performance monitoring, version 1, doesn't support fixed counters. Currently, even if a hypervisor advertises support for architectural performance monitoring version 1, perf may still try to use the fixed counters, as the constraints are set up based on the CPU model. This patch ensures that perf honors the architectural performance monitoring version returned by CPUID, and it only uses the fixed counters for version 2 and above. (Some of the ideas in this patch came from Peter Zijlstra.) Signed-off-by: Imre Palik Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Andy Lutomirski Cc: Anthony Liguori Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1433767609-1039-1-git-send-email-imrep.amz@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit ceb996d7afb3b7a86cde675bf820f0319a690355 Author: Ralf Baechle Date: Thu Feb 4 01:24:40 2016 +0100 MIPS: Fix 64k page support for 32 bit kernels. commit d7de413475f443957a0c1d256e405d19b3a2cb22 upstream. TASK_SIZE was defined as 0x7fff8000UL which for 64k pages is not a multiple of the page size. Somewhere further down the math fails such that executing an ELF binary fails. Signed-off-by: Ralf Baechle Tested-by: Joshua Henderson Cc: James Hogan Signed-off-by: Ben Hutchings commit 982ff37658a22a7ebe715a197a912b3c3225fab8 Author: Dan Bogdan Nechita Date: Tue Feb 23 11:48:45 2016 +0200 misc: ad525x_dpot: Fix the enabling of the "otpXen" attributes commit 1bb850a1b7f68b66361e658e334f9fdf8231f17d upstream. Currently writing the attributes with "echo" will result in comparing: "enabled\n" with "enabled\0" and attribute is always set to false. Use the sysfs_streq() instead because it treats both NUL and new-line-then-NUL as equivalent string terminations. Signed-off-by: Dan Bogdan Nechita Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 3c0458027103eddd9ec0affdfdec42c51cc7f6aa Author: Chanwoo Choi Date: Thu Apr 21 18:58:31 2016 +0900 serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios() commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream. This patch fixes the broken serial log when changing the clock source of uart device. Before disabling the original clock source, this patch enables the new clock source to protect the clock off state for a split second. Signed-off-by: Chanwoo Choi Reviewed-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e41c5a9b99d76b11966afa92922757bb630e31ad Author: Josef Bacik Date: Fri Mar 25 10:02:41 2016 -0400 Btrfs: don't use src fd for printk commit c79b4713304f812d3d6c95826fc3e5fc2c0b0c14 upstream. The fd we pass in may not be on a btrfs file system, so don't try to do BTRFS_I() on it. Thanks, Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Cc: Jeff Mahoney Signed-off-by: Ben Hutchings commit ac854b1094030898cceb9d4826a4d0d99e92a085 Author: Tony Lindgren Date: Thu May 28 07:22:08 2015 -0700 ARM: OMAP3: Fix booting with thumb2 kernel commit d8a50941c91a68da202aaa96a3dacd471ea9c693 upstream. We get a NULL pointer dereference on omap3 for thumb2 compiled kernels: Internal error: Oops: 80000005 [#1] SMP THUMB2 ... [] (_raw_spin_unlock_irqrestore) from [] (omap3_enter_idle_bm+0xc5/0x178) [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x77/0x27c) [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x155/0x23c) [] (cpu_startup_entry) from [] (start_kernel+0x32f/0x338) [] (start_kernel) from [<8000807f>] (0x8000807f) The power management related assembly on omaps needs to interact with ARM mode bootrom code, so we need to keep most of the related assembly in ARM mode. Turns out this error is because of missing ENDPROC for assembly code as suggested by Stephen Boyd . Let's fix the problem by adding ENDPROC in two places to sleep34xx.S. Let's also remove the now duplicate custom code for mode switching. This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+"). And let's also remove the comments about local variables, they are now just confusing after the ENDPROC. The reason why ENDPROC makes a difference is it sets .type and then the compiler knows what to do with the thumb bit as explained at: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto Reported-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Ben Hutchings commit 34fff37b6442a580a8b7e91aa93dd647c7d50dde Author: Andrey Gelman Date: Tue Oct 6 15:43:43 2015 -0700 Input: ads7846 - correct the value got from SPI commit 879f2fea8a5a748bcbf98d2cdce9139c045505d3 upstream. According to the touch controller spec, SPI return a 16 bit value, only 12 bits are valid, they are bit[14-3]. The value of MISO and MOSI can be configured when SPI is in idle mode. Currently this touch driver assumes the SPI bus sets the MOSI and MISO in low level when SPI bus is in idle mode. So the bit[15] of the value got from SPI bus is always 0. But when SPI bus congfigures the MOSI and MISO in high level during the SPI idle mode, the bit[15] of the value get from SPI is always 1. If bit[15] is not masked, we may get the wrong value. Mask the invalid bit to make sure the correct value gets returned. Regardless of the SPI bus idle configuration. Signed-off-by: Andrey Gelman Signed-off-by: Haibo Chen Signed-off-by: Igor Grinberg Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit e854c4d34f99ea3e76856cdd809f1e405c00f266 Author: Hans Verkuil Date: Mon May 2 10:11:49 2016 +0200 v4l2-dv-timings.h: fix polarity for 4k formats commit 3020ca711871fdaf0c15c8bab677a6bc302e28fe upstream. The VSync polarity was negative instead of positive for the 4k CEA formats. I probably copy-and-pasted these from the DMT 4k format, which does have a negative VSync polarity. Signed-off-by: Hans Verkuil Reported-by: Martin Bugge Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 7dc5d81848092f2a7ceb252db83e1cf3e2f29bb7 Author: Bin Liu Date: Mon Jan 26 16:22:07 2015 -0600 usb: musb: cppi41: improve rx channel abort routine commit cb83df77f3ec151d68a1b6be957207e6fc7b7f50 upstream. 1. set AUTOREQ to NONE at the beginning of teardown; 2. add delay for dma pipeline to drain; 3. Do not set USB_TDOWN bit for RX teardown. The CPPI hw has an issue that when tearing down a RX channel, if another RX channel is receiving data, the CPPI will lockup. To workaround the issue, do not set the CPPI TD bit. The steps before this point ensures the CPPI channel will be torn down properly. Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit e8a4f7cbb13068b7aaf358e3754d249c7a0b70f8 Author: Bin Liu Date: Mon Jan 26 16:22:06 2015 -0600 usb: musb: cppi41: correct the macro name EP_MODE_AUTOREG_* commit 0149b07a9e28b0d8bd2fc1c238ffe7d530c2673f upstream. The macro EP_MODE_AUTOREG_* should be called EP_MODE_AUTOREQ_*, as they are used for register AUTOREQ. Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 910b687e06273ba8b112c984aae35cb648ff9330 Author: Matt Fleming Date: Tue Jan 13 15:25:00 2015 +0000 x86/efi: Avoid triple faults during EFI mixed mode calls commit 96738c69a7fcdbf0d7c9df0c8a27660011e82a7b upstream. Andy pointed out that if an NMI or MCE is received while we're in the middle of an EFI mixed mode call a triple fault will occur. This can happen, for example, when issuing an EFI mixed mode call while running perf. The reason for the triple fault is that we execute the mixed mode call in 32-bit mode with paging disabled but with 64-bit kernel IDT handlers installed throughout the call. At Andy's suggestion, stop playing the games we currently do at runtime, such as disabling paging and installing a 32-bit GDT for __KERNEL_CS. We can simply switch to the __KERNEL32_CS descriptor before invoking firmware services, and run in compatibility mode. This way, if an NMI/MCE does occur the kernel IDT handler will execute correctly, since it'll jump to __KERNEL_CS automatically. However, this change is only possible post-ExitBootServices(). Before then the firmware "owns" the machine and expects for its 32-bit IDT handlers to be left intact to service interrupts, etc. So, we now need to distinguish between early boot and runtime invocations of EFI services. During early boot, we need to restore the GDT that the firmware expects to be present. We can only jump to the __KERNEL32_CS code segment for mixed mode calls after ExitBootServices() has been invoked. A liberal sprinkling of comments in the thunking code should make the differences in early and late environments more apparent. Reported-by: Andy Lutomirski Tested-by: Borislav Petkov Signed-off-by: Matt Fleming [bwh: Backported to 3.16: in arch/x86/boot/compressed/Makefile, add the new object file to VMLINUX_OBJS] Signed-off-by: Ben Hutchings commit ac500cd3863d7f89c448d77416b5fb25b2c734bc Author: Rob Clark Date: Sat Nov 8 10:16:19 2014 -0500 drm/irq: BUG_ON() -> WARN_ON() commit 7f907bf284ba7bb8d271f094b226699d3fef2142 upstream. Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by: Rob Clark Reviewed-by: Michel Dänzer Signed-off-by: Dave Airlie [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit bfc20d54acae250fde0c8d56fc57fd41ea6dbe99 Author: Lv Zheng Date: Wed Oct 29 11:33:43 2014 +0800 Revert "ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC" commit df9ff91801da603079018f21a9412385b62f0f8e upstream. It is reported that the following commit breaks Samsung hardware: Commit: 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4. Subject: ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC Which means the Samsung behavior conflicts with the Acer behavior. 1. Samsung may behave like: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC read event [ -event 1 ] SCI_EVT clear Without the above commit, Samsung can work: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC CAN prepare next QR_EC as SCI_EVT=1 read event [ -event 1 ] SCI_EVT clear write QR_EC read event [ -event 2 ] SCI_EVT clear With the above commit, Samsung cannot work: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC read event [ -event 1 ] SCI_EVT clear CANNOT prepare next QR_EC as SCI_EVT=0 2. Acer may behave like: [ +event 1 ] SCI_EVT set [ +event 2 ] write QR_EC read event [ -event 1 ] SCI_EVT clear [ +event 2 ] SCI_EVT set Without the above commit, Acer cannot work when there is only 1 event: [ +event 1 ] SCI_EVT set write QR_EC can prepared next QR_EC as SCI_EVT=1 read event [ -event 1 ] SCI_EVT clear CANNOT write QR_EC as SCI_EVT=0 With the above commit, Acer can work: [ +event 1 ] SCI_EVT set [ +event 2 ] write QR_EC read event [ -event 1 ] SCI_EVT set can prepare next QR_EC because SCI_EVT=0 CAN write QR_EC as SCI_EVT=1 Since Acer can also work with only the following commit applied: Commit: 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 can be reverted. Fixes: 558e4736f2e1 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 54e0d01bb60532f6ede5dc1ae683a2f5197c3cd2 Author: Jamal Hadi Salim Date: Mon Oct 24 20:18:27 2016 -0400 net sched filters: fix notification of filter delete with proper handle [ Upstream commit 9ee7837449b3d6f0fcf9132c6b5e5aaa58cc67d4 ] Daniel says: While trying out [1][2], I noticed that tc monitor doesn't show the correct handle on delete: $ tc monitor qdisc clsact ffff: dev eno1 parent ffff:fff1 filter dev eno1 ingress protocol all pref 49152 bpf handle 0x2a [...] deleted filter dev eno1 ingress protocol all pref 49152 bpf handle 0xf3be0c80 some context to explain the above: The user identity of any tc filter is represented by a 32-bit identifier encoded in tcm->tcm_handle. Example 0x2a in the bpf filter above. A user wishing to delete, get or even modify a specific filter uses this handle to reference it. Every classifier is free to provide its own semantics for the 32 bit handle. Example: classifiers like u32 use schemes like 800:1:801 to describe the semantics of their filters represented as hash table, bucket and node ids etc. Classifiers also have internal per-filter representation which is different from this externally visible identity. Most classifiers set this internal representation to be a pointer address (which allows fast retrieval of said filters in their implementations). This internal representation is referenced with the "fh" variable in the kernel control code. When a user successfuly deletes a specific filter, by specifying the correct tcm->tcm_handle, an event is generated to user space which indicates which specific filter was deleted. Before this patch, the "fh" value was sent to user space as the identity. As an example what is shown in the sample bpf filter delete event above is 0xf3be0c80. This is infact a 32-bit truncation of 0xffff8807f3be0c80 which happens to be a 64-bit memory address of the internal filter representation (address of the corresponding filter's struct cls_bpf_prog); After this patch the appropriate user identifiable handle as encoded in the originating request tcm->tcm_handle is generated in the event. One of the cardinal rules of netlink rules is to be able to take an event (such as a delete in this case) and reflect it back to the kernel and successfully delete the filter. This patch achieves that. Note, this issue has existed since the original TC action infrastructure code patch back in 2004 as found in: https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/ [1] http://patchwork.ozlabs.org/patch/682828/ [2] http://patchwork.ozlabs.org/patch/682829/ Fixes: 4e54c4816bfe ("[NET]: Add tc extensions infrastructure.") Reported-by: Daniel Borkmann Acked-by: Cong Wang Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 17eb279dbb32e5bf42f19c8232e4412426de173c Author: Jason A. Donenfeld Date: Wed Jun 15 11:14:53 2016 +0200 net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG commit daddef76c3deaaa7922f9d7b18edbf0a061215c3 upstream. The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the usual definition of the dynamic_pr_debug macro, but alter it by adding a call to "net_ratelimit()" in the if statement. This is, in fact, the correct approach. However, while doing this, the author of the commit forgot to surround fmt by pr_fmt, resulting in unprefixed log messages appearing in the console. So, this commit adds back the pr_fmt(fmt) invocation, making net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and DYNAMIC_DEBUG cases, and bringing parity with the behavior of dynamic_pr_debug as well. Fixes: 2c94b5373 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case") Signed-off-by: Jason A. Donenfeld Cc: Tim Bingham Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 036684548f9cbb0058d42e550fec3e8310411d10 Author: Tim Bingham Date: Fri Apr 29 13:30:23 2016 -0400 net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case commit 2c94b53738549d81dc7464a32117d1f5112c64d3 upstream. Prior to commit d92cff89a0c8 ("net_dbg_ratelimited: turn into no-op when !DEBUG") the implementation of net_dbg_ratelimited() was buggy for both the DEBUG and CONFIG_DYNAMIC_DEBUG cases. The bug was that net_ratelimit() was being called and, despite returning true, nothing was being printed to the console. This resulted in messages like the following - "net_ratelimit: %d callbacks suppressed" with no other output nearby. After commit d92cff89a0c8 ("net_dbg_ratelimited: turn into no-op when !DEBUG") the bug is fixed for the DEBUG case. However, there's no output at all for CONFIG_DYNAMIC_DEBUG case. This patch restores debug output (if enabled) for the CONFIG_DYNAMIC_DEBUG case. Add a definition of net_dbg_ratelimited() for the CONFIG_DYNAMIC_DEBUG case. The implementation takes care to check that dynamic debugging is enabled before calling net_ratelimit(). Fixes: d92cff89a0c8 ("net_dbg_ratelimited: turn into no-op when !DEBUG") Signed-off-by: Tim Bingham Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8520f5c9a7bd32001690a73a0ed286f190a53b0e Author: Jason A. Donenfeld Date: Tue Aug 4 18:26:19 2015 +0200 net_dbg_ratelimited: turn into no-op when !DEBUG commit d92cff89a0c80e7e49796366e441d97f07b5d321 upstream. The pr_debug family of functions turns into a no-op when -DDEBUG is not specified, opting instead to call "no_printk", which gets compiled to a no-op (but retains gcc's nice warnings about printf-style arguments). The problem with net_dbg_ratelimited is that it is defined to be a variant of net_ratelimited_function, which expands to essentially: if (net_ratelimit()) pr_debug(fmt, ...); When DEBUG is not defined, then this becomes, if (net_ratelimit()) ; This seems benign, except it isn't. Firstly, there's the obvious overhead of calling net_ratelimit needlessly, which does quite some book keeping for the rate limiting. Given that the pr_debug and net_dbg_ratelimited family of functions are sprinkled liberally through performance critical code, with developers assuming they'll be compiled out to a no-op most of the time, we certainly do not want this needless book keeping. Secondly, and most visibly, even though no debug message is printed when DEBUG is not defined, if there is a flood of invocations, dmesg winds up peppered with messages such as "net_ratelimit: 320 callbacks suppressed". This is because our aforementioned net_ratelimit() function actually prints this text in some circumstances. It's especially odd to see this when there isn't any other accompanying debug message. So, in sum, it doesn't make sense to have this function's current behavior, and instead it should match what every other debug family of functions in the kernel does with !DEBUG -- nothing. This patch replaces calls to net_dbg_ratelimited when !DEBUG with no_printk, keeping with the idiom of all the other debug print helpers. Also, though not strictly neccessary, it guards the call with an if (0) so that all evaluation of any arguments are sure to be compiled out. Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 855e954aa31997a86b39d317ebaca18d87665524 Author: David S. Miller Date: Sat May 28 20:41:12 2016 -0700 sparc64: Fix return from trap window fill crashes. [ Upstream commit 7cafc0b8bf130f038b0ec2dcdd6a9de6dc59b65a ] We must handle data access exception as well as memory address unaligned exceptions from return from trap window fill faults, not just normal TLB misses. Otherwise we can get an OOPS that looks like this: ld-linux.so.2(36808): Kernel bad sw trap 5 [#1] CPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 #34 task: fff8000303be5c60 ti: fff8000301344000 task.ti: fff8000301344000 TSTATE: 0000004410001601 TPC: 0000000000a1a784 TNPC: 0000000000a1a788 Y: 00000002 Not tainted TPC: g0: fff8000024fc8248 g1: 0000000000db04dc g2: 0000000000000000 g3: 0000000000000001 g4: fff8000303be5c60 g5: fff800030e672000 g6: fff8000301344000 g7: 0000000000000001 o0: 0000000000b95ee8 o1: 000000000000012b o2: 0000000000000000 o3: 0000000200b9b358 o4: 0000000000000000 o5: fff8000301344040 sp: fff80003013475c1 ret_pc: 0000000000a1a77c RPC: l0: 00000000000007ff l1: 0000000000000000 l2: 000000000000005f l3: 0000000000000000 l4: fff8000301347e98 l5: fff8000024ff3060 l6: 0000000000000000 l7: 0000000000000000 i0: fff8000301347f60 i1: 0000000000102400 i2: 0000000000000000 i3: 0000000000000000 i4: 0000000000000000 i5: 0000000000000000 i6: fff80003013476a1 i7: 0000000000404d4c I7: Call Trace: [0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c The window trap handlers are slightly clever, the trap table entries for them are composed of two pieces of code. First comes the code that actually performs the window fill or spill trap handling, and then there are three instructions at the end which are for exception processing. The userland register window fill handler is: add %sp, STACK_BIAS + 0x00, %g1; \ ldxa [%g1 + %g0] ASI, %l0; \ mov 0x08, %g2; \ mov 0x10, %g3; \ ldxa [%g1 + %g2] ASI, %l1; \ mov 0x18, %g5; \ ldxa [%g1 + %g3] ASI, %l2; \ ldxa [%g1 + %g5] ASI, %l3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %l4; \ ldxa [%g1 + %g2] ASI, %l5; \ ldxa [%g1 + %g3] ASI, %l6; \ ldxa [%g1 + %g5] ASI, %l7; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i0; \ ldxa [%g1 + %g2] ASI, %i1; \ ldxa [%g1 + %g3] ASI, %i2; \ ldxa [%g1 + %g5] ASI, %i3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i4; \ ldxa [%g1 + %g2] ASI, %i5; \ ldxa [%g1 + %g3] ASI, %i6; \ ldxa [%g1 + %g5] ASI, %i7; \ restored; \ retry; nop; nop; nop; nop; \ b,a,pt %xcc, fill_fixup_dax; \ b,a,pt %xcc, fill_fixup_mna; \ b,a,pt %xcc, fill_fixup; And the way this works is that if any of those memory accesses generate an exception, the exception handler can revector to one of those final three branch instructions depending upon which kind of exception the memory access took. In this way, the fault handler doesn't have to know if it was a spill or a fill that it's handling the fault for. It just always branches to the last instruction in the parent trap's handler. For example, for a regular fault, the code goes: winfix_trampoline: rdpr %tpc, %g3 or %g3, 0x7c, %g3 wrpr %g3, %tnpc done All window trap handlers are 0x80 aligned, so if we "or" 0x7c into the trap time program counter, we'll get that final instruction in the trap handler. On return from trap, we have to pull the register window in but we do this by hand instead of just executing a "restore" instruction for several reasons. The largest being that from Niagara and onward we simply don't have enough levels in the trap stack to fully resolve all possible exception cases of a window fault when we are already at trap level 1 (which we enter to get ready to return from the original trap). This is executed inline via the FILL_*_RTRAP handlers. rtrap_64.S's code branches directly to these to do the window fill by hand if necessary. Now if you look at them, we'll see at the end: ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; And oops, all three cases are handled like a fault. This doesn't work because each of these trap types (data access exception, memory address unaligned, and faults) store their auxiliary info in different registers to pass on to the C handler which does the real work. So in the case where the stack was unaligned, the unaligned trap handler sets up the arg registers one way, and then we branched to the fault handler which expects them setup another way. So the FAULT_TYPE_* value ends up basically being garbage, and randomly would generate the backtrace seen above. Reported-by: Nick Alcock Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e1b056ed75ecd0c684653192ab1832b32f7a1c9d Author: David S. Miller Date: Sat May 28 21:21:31 2016 -0700 sparc: Harden signal return frame checks. [ Upstream commit d11c2a0de2824395656cf8ed15811580c9dd38aa ] All signal frames must be at least 16-byte aligned, because that is the alignment we explicitly create when we build signal return stack frames. All stack pointers must be at least 8-byte aligned. Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4c39b621a1acadfd29d80e9313e7e114f64c7290 Author: David S. Miller Date: Wed May 25 12:51:20 2016 -0700 sparc64: Take ctx_alloc_lock properly in hugetlb_setup(). [ Upstream commit 9ea46abe22550e3366ff7cee2f8391b35b12f730 ] On cheetahplus chips we take the ctx_alloc_lock in order to modify the TLB lookup parameters for the indexed TLBs, which are stored in the context register. This is called with interrupts disabled, however ctx_alloc_lock is an IRQ safe lock, therefore we must take acquire/release it properly with spin_{lock,unlock}_irq(). Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8bfb07ff7f54bac3906d8d09b934884c75feed6c Author: Babu Moger Date: Thu Mar 24 13:02:22 2016 -0700 sparc/PCI: Fix for panic while enabling SR-IOV [ Upstream commit d0c31e02005764dae0aab130a57e9794d06b824d ] We noticed this panic while enabling SR-IOV in sparc. mlx4_core: Mellanox ConnectX core driver v2.2-1 (Jan 1 2015) mlx4_core: Initializing 0007:01:00.0 mlx4_core 0007:01:00.0: Enabling SR-IOV with 5 VFs mlx4_core: Initializing 0007:01:00.1 Unable to handle kernel NULL pointer dereference insmod(10010): Oops [#1] CPU: 391 PID: 10010 Comm: insmod Not tainted 4.1.12-32.el6uek.kdump2.sparc64 #1 TPC: I7: <__mlx4_init_one+0x324/0x500 [mlx4_core]> Call Trace: [00000000104c5ea4] __mlx4_init_one+0x324/0x500 [mlx4_core] [00000000104c613c] mlx4_init_one+0xbc/0x120 [mlx4_core] [0000000000725f14] local_pci_probe+0x34/0xa0 [0000000000726028] pci_call_probe+0xa8/0xe0 [0000000000726310] pci_device_probe+0x50/0x80 [000000000079f700] really_probe+0x140/0x420 [000000000079fa24] driver_probe_device+0x44/0xa0 [000000000079fb5c] __device_attach+0x3c/0x60 [000000000079d85c] bus_for_each_drv+0x5c/0xa0 [000000000079f588] device_attach+0x88/0xc0 [000000000071acd0] pci_bus_add_device+0x30/0x80 [0000000000736090] virtfn_add.clone.1+0x210/0x360 [00000000007364a4] sriov_enable+0x2c4/0x520 [000000000073672c] pci_enable_sriov+0x2c/0x40 [00000000104c2d58] mlx4_enable_sriov+0xf8/0x180 [mlx4_core] [00000000104c49ac] mlx4_load_one+0x42c/0xd40 [mlx4_core] Disabling lock debugging due to kernel taint Caller[00000000104c5ea4]: __mlx4_init_one+0x324/0x500 [mlx4_core] Caller[00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core] Caller[0000000000725f14]: local_pci_probe+0x34/0xa0 Caller[0000000000726028]: pci_call_probe+0xa8/0xe0 Caller[0000000000726310]: pci_device_probe+0x50/0x80 Caller[000000000079f700]: really_probe+0x140/0x420 Caller[000000000079fa24]: driver_probe_device+0x44/0xa0 Caller[000000000079fb5c]: __device_attach+0x3c/0x60 Caller[000000000079d85c]: bus_for_each_drv+0x5c/0xa0 Caller[000000000079f588]: device_attach+0x88/0xc0 Caller[000000000071acd0]: pci_bus_add_device+0x30/0x80 Caller[0000000000736090]: virtfn_add.clone.1+0x210/0x360 Caller[00000000007364a4]: sriov_enable+0x2c4/0x520 Caller[000000000073672c]: pci_enable_sriov+0x2c/0x40 Caller[00000000104c2d58]: mlx4_enable_sriov+0xf8/0x180 [mlx4_core] Caller[00000000104c49ac]: mlx4_load_one+0x42c/0xd40 [mlx4_core] Caller[00000000104c5f90]: __mlx4_init_one+0x410/0x500 [mlx4_core] Caller[00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core] Caller[0000000000725f14]: local_pci_probe+0x34/0xa0 Caller[0000000000726028]: pci_call_probe+0xa8/0xe0 Caller[0000000000726310]: pci_device_probe+0x50/0x80 Caller[000000000079f700]: really_probe+0x140/0x420 Caller[000000000079fa24]: driver_probe_device+0x44/0xa0 Caller[000000000079fb08]: __driver_attach+0x88/0xa0 Caller[000000000079d90c]: bus_for_each_dev+0x6c/0xa0 Caller[000000000079f29c]: driver_attach+0x1c/0x40 Caller[000000000079e35c]: bus_add_driver+0x17c/0x220 Caller[00000000007a02d4]: driver_register+0x74/0x120 Caller[00000000007263fc]: __pci_register_driver+0x3c/0x60 Caller[00000000104f62bc]: mlx4_init+0x60/0xcc [mlx4_core] Kernel panic - not syncing: Fatal exception Press Stop-A (L1-A) to return to the boot prom ---[ end Kernel panic - not syncing: Fatal exception Details: Here is the call sequence virtfn_add->__mlx4_init_one->dma_set_mask->dma_supported The panic happened at line 760(file arch/sparc/kernel/iommu.c) 758 int dma_supported(struct device *dev, u64 device_mask) 759 { 760 struct iommu *iommu = dev->archdata.iommu; 761 u64 dma_addr_mask = iommu->dma_addr_mask; 762 763 if (device_mask >= (1UL << 32UL)) 764 return 0; 765 766 if ((device_mask & dma_addr_mask) == dma_addr_mask) 767 return 1; 768 769 #ifdef CONFIG_PCI 770 if (dev_is_pci(dev)) 771 return pci64_dma_supported(to_pci_dev(dev), device_mask); 772 #endif 773 774 return 0; 775 } 776 EXPORT_SYMBOL(dma_supported); Same panic happened with Intel ixgbe driver also. SR-IOV code looks for arch specific data while enabling VFs. When VF device is added, driver probe function makes set of calls to initialize the pci device. Because the VF device is added different way than the normal PF device(which happens via of_create_pci_dev for sparc), some of the arch specific initialization does not happen for VF device. That causes panic when archdata is accessed. To fix this, I have used already defined weak function pcibios_setup_device to copy archdata from PF to VF. Also verified the fix. Signed-off-by: Babu Moger Signed-off-by: Sowmini Varadhan Reviewed-by: Ethan Zhao Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 39e590544483f10fbbc08ff77622ade88ed84a76 Author: David S. Miller Date: Tue Mar 1 00:25:32 2016 -0500 sparc64: Fix sparc64_set_context stack handling. [ Upstream commit 397d1533b6cce0ccb5379542e2e6d079f6936c46 ] Like a signal return, we should use synchronize_user_stack() rather than flush_user_windows(). Reported-by: Ilya Malakhov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7058a92a6074606b0a7a058ad11d077489d0045f Author: David S. Miller Date: Wed Apr 27 17:27:37 2016 -0400 sparc64: Fix bootup regressions on some Kconfig combinations. [ Upstream commit 49fa5230462f9f2c4e97c81356473a6bdf06c422 ] The system call tracing bug fix mentioned in the Fixes tag below increased the amount of assembler code in the sequence of assembler files included by head_64.S This caused to total set of code to exceed 0x4000 bytes in size, which overflows the expression in head_64.S that works to place swapper_tsb at address 0x408000. When this is violated, the TSB is not properly aligned, and also the trap table is not aligned properly either. All of this together results in failed boots. So, do two things: 1) Simplify some code by using ba,a instead of ba/nop to get those bytes back. 2) Add a linker script assertion to make sure that if this happens again the build will fail. Fixes: 1a40b95374f6 ("sparc: Fix system call tracing register handling.") Reported-by: Meelis Roos Reported-by: Joerg Abraham Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit d210b82c1fbebdb4ca214f76c81f13262df8f6fb Author: Mike Frysinger Date: Mon Jan 18 06:32:30 2016 -0500 sparc: Fix system call tracing register handling. [ Upstream commit 1a40b95374f680625318ab61d81958e949e0afe3 ] A system call trace trigger on entry allows the tracing process to inspect and potentially change the traced process's registers. Account for that by reloading the %g1 (syscall number) and %i0-%i5 (syscall argument) values. We need to be careful to revalidate the range of %g1, and reload the system call table entry it corresponds to into %l7. Reported-by: Mike Frysinger Signed-off-by: David S. Miller Tested-by: Mike Frysinger Signed-off-by: Ben Hutchings commit 46b21026072982166592555e889e1bd5a9414159 Author: Sudip Mukherjee Date: Tue Dec 29 14:54:19 2015 -0800 m32r: add io*_rep helpers commit 92a8ed4c7643809123ef0a65424569eaacc5c6b0 upstream. m32r allmodconfig was failing with the error: error: implicit declaration of function 'read' On checking io.h it turned out that 'read' is not defined but 'readb' is defined and 'ioread8' will then obviously mean 'readb'. At the same time some of the helper functions ioreadN_rep() and iowriteN_rep() were missing which also led to the build failure. Signed-off-by: Sudip Mukherjee Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e3bf269ef3b0ca85d9ff53981d25e734b9fdbaf4 Author: Abhilash Kesavan Date: Fri Feb 6 19:15:26 2015 +0530 m32r: add definition of ioremap_wc to io.h commit 71a49d16f06de2ccdf52ca247d496a2bb1ca36fe upstream. Before adding a resource managed ioremap_wc function, we need to have ioremap_wc defined for m32r to prevent build errors. Signed-off-by: Abhilash Kesavan Acked-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman Cc: Sudip Mukherjee Signed-off-by: Ben Hutchings commit 0bdce0a368321adb9fcd2d7255cd5f3e71140212 Author: Paolo Abeni Date: Thu Apr 21 22:23:31 2016 +0200 ipv4/fib: don't warn when primary address is missing if in_dev is dead [ Upstream commit 391a20333b8393ef2e13014e6e59d192c5594471 ] After commit fbd40ea0180a ("ipv4: Don't do expensive useless work during inetdev destroy.") when deleting an interface, fib_del_ifaddr() can be executed without any primary address present on the dead interface. The above is safe, but triggers some "bug: prim == NULL" warnings. This commit avoids warning if the in_dev is dead Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 246e7965d0e9043d7d265a000a8dba6ad7148ccd Author: Paolo Abeni Date: Fri May 13 18:33:41 2016 +0200 net/route: enforce hoplimit max value [ Upstream commit 626abd59e51d4d8c6367e03aae252a8aa759ac78 ] Currently, when creating or updating a route, no check is performed in both ipv4 and ipv6 code to the hoplimit value. The caller can i.e. set hoplimit to 256, and when such route will be used, packets will be sent with hoplimit/ttl equal to 0. This commit adds checks for the RTAX_HOPLIMIT value, in both ipv4 ipv6 route code, substituting any value greater than 255 with 255. This is consistent with what is currently done for ADVMSS and MTU in the ipv4 code. Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller [bwh: Backported to 3.16: for IPv6, add the check to fib6_commit_metrics()] Signed-off-by: Ben Hutchings commit b97f7773a3aa57402868958eab4560b7de317287 Author: Paul Hüber Date: Sun Feb 26 17:58:19 2017 +0100 l2tp: avoid use-after-free caused by l2tp_ip_backlog_recv commit 51fb60eb162ab84c5edf2ae9c63cf0b878e5547e upstream. l2tp_ip_backlog_recv may not return -1 if the packet gets dropped. The return value is passed up to ip_local_deliver_finish, which treats negative values as an IP protocol number for resubmission. Signed-off-by: Paul Hüber Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8a7b081660857a80c3efc463b3da790c4fa0c801 Author: Ben Seri Date: Sat Sep 9 23:15:59 2017 +0200 Bluetooth: Properly check L2CAP config option output buffer length commit e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3 upstream. Validate the output buffer length for L2CAP config requests and responses to avoid overflowing the stack buffer used for building the option blocks. Signed-off-by: Ben Seri Signed-off-by: Marcel Holtmann Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit a1b438ad8590add8f6b0b679171bf5e0d45e2da1 Author: Xin Long Date: Sun Aug 27 20:25:26 2017 +0800 scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly commit c88f0e6b06f4092995688211a631bb436125d77b upstream. ChunYu found a kernel crash by syzkaller: [ 651.617875] kasan: CONFIG_KASAN_INLINE enabled [ 651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 651.618731] general protection fault: 0000 [#1] SMP KASAN [ 651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32 [ 651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 651.622309] task: ffff880117780000 task.stack: ffff8800a3188000 [ 651.622762] RIP: 0010:skb_release_data+0x26c/0x590 [...] [ 651.627260] Call Trace: [ 651.629156] skb_release_all+0x4f/0x60 [ 651.629450] consume_skb+0x1a5/0x600 [ 651.630705] netlink_unicast+0x505/0x720 [ 651.632345] netlink_sendmsg+0xab2/0xe70 [ 651.633704] sock_sendmsg+0xcf/0x110 [ 651.633942] ___sys_sendmsg+0x833/0x980 [ 651.637117] __sys_sendmsg+0xf3/0x240 [ 651.638820] SyS_sendmsg+0x32/0x50 [ 651.639048] entry_SYSCALL_64_fastpath+0x1f/0xc2 It's caused by skb_shared_info at the end of sk_buff was overwritten by ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx. During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh), ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a new value to skb_shinfo(SKB)->nr_frags by ev->type. This patch is to fix it by checking nlh->nlmsg_len properly there to avoid over accessing sk_buff. Reported-by: ChunYu Wang Signed-off-by: Xin Long Acked-by: Chris Leech Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 1e48f7b93c3a8f1d7bb136ab7fa61e763893a6fd Author: Richard Wareing Date: Wed Sep 13 09:09:35 2017 +1000 xfs: XFS_IS_REALTIME_INODE() should be false if no rt device present commit b31ff3cdf540110da4572e3e29bd172087af65cc upstream. If using a kernel with CONFIG_XFS_RT=y and we set the RHINHERIT flag on a directory in a filesystem that does not have a realtime device and create a new file in that directory, it gets marked as a real time file. When data is written and a fsync is issued, the filesystem attempts to flush a non-existent rt device during the fsync process. This results in a crash dereferencing a null buftarg pointer in xfs_blkdev_issue_flush(): BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xfs_blkdev_issue_flush+0xd/0x20 ..... Call Trace: xfs_file_fsync+0x188/0x1c0 vfs_fsync_range+0x3b/0xa0 do_fsync+0x3d/0x70 SyS_fsync+0x10/0x20 do_syscall_64+0x4d/0xb0 entry_SYSCALL64_slow_path+0x25/0x25 Setting RT inode flags does not require special privileges so any unprivileged user can cause this oops to occur. To reproduce, confirm kernel is compiled with CONFIG_XFS_RT=y and run: # mkfs.xfs -f /dev/pmem0 # mount /dev/pmem0 /mnt/test # mkdir /mnt/test/foo # xfs_io -c 'chattr +t' /mnt/test/foo # xfs_io -f -c 'pwrite 0 5m' -c fsync /mnt/test/foo/bar Or just run xfstests with MKFS_OPTIONS="-d rtinherit=1" and wait. Kernels built with CONFIG_XFS_RT=n are not exposed to this bug. Fixes: f538d4da8d52 ("[XFS] write barrier support") Signed-off-by: Richard Wareing Signed-off-by: Dave Chinner Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 093d5ecdeb49c6ad4ea4c1fb39c481e9bcfc1871 Author: Vladis Dronov Date: Mon Sep 4 16:00:50 2017 +0200 video: fbdev: aty: do not leak uninitialized padding in clk to userspace commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream. 'clk' is copied to a userland with padding byte(s) after 'vclk_post_div' field unitialized, leaking data from the stack. Fix this ensuring all of 'clk' is initialized to zero. References: https://github.com/torvalds/linux/pull/441 Reported-by: sohu0106 Signed-off-by: Vladis Dronov Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Ben Hutchings commit 423a7a81efb8da25dbbcfe7a33bd8bfdce34150b Author: Jim Mattson Date: Tue Sep 12 13:02:54 2017 -0700 kvm: nVMX: Don't allow L2 to access the hardware CR8 commit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f upstream. If L1 does not specify the "use TPR shadow" VM-execution control in vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store exiting" VM-execution controls in vmcs02. Failure to do so will give the L2 VM unrestricted read/write access to the hardware CR8. This fixes CVE-2017-12154. Signed-off-by: Jim Mattson Reviewed-by: David Hildenbrand Signed-off-by: Paolo Bonzini [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit ed2305f2eba403d41dc4213746f60d47273980f6 Author: Vladis Dronov Date: Wed Sep 13 00:21:21 2017 +0200 nl80211: check for the required netlink attributes presence commit e785fa0a164aa11001cba931367c7f94ffaff888 upstream. nl80211_set_rekey_data() does not check if the required attributes NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by users with CAP_NET_ADMIN privilege and may result in NULL dereference and a system crash. Add a check for the required attributes presence. This patch is based on the patch by bo Zhang. This fixes CVE-2017-12153. References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046 Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload") Reported-by: bo Zhang Signed-off-by: Vladis Dronov Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit f6c711a2f630b15479466f5b25b25850b04a7106 Author: Steven Toth Date: Tue Jun 6 09:30:27 2017 -0300 saa7164: fix double fetch PCIe access condition commit 6fb05e0dd32e566facb96ea61a48c7488daa5ac3 upstream. Avoid a double fetch by reusing the values from the prior transfer. Originally reported via https://bugzilla.kernel.org/show_bug.cgi?id=195559 Thanks to Pengfei Wang for reporting. Signed-off-by: Steven Toth Reported-by: Pengfei Wang Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 0ea076b858a085b7c8142d7e2f1159d7e7f49227 Author: Hans Verkuil Date: Fri Nov 7 11:39:46 2014 -0300 saa7164: fix sparse warnings commit 065e1477d277174242e73e7334c717b840d0693f upstream. Fix many sparse warnings: drivers/media/pci/saa7164/saa7164-core.c:97:18: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-core.c:122:31: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-core.c:122:31: warning: incorrect type in initializer (different address spaces) drivers/media/pci/saa7164/saa7164-core.c:122:31: expected unsigned char [noderef] [usertype] *bufcpu drivers/media/pci/saa7164/saa7164-core.c:122:31: got unsigned char [usertype] * drivers/media/pci/saa7164/saa7164-core.c:282:44: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-core.c:286:38: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-core.c:286:35: warning: incorrect type in assignment (different address spaces) drivers/media/pci/saa7164/saa7164-core.c:286:35: expected unsigned char [noderef] [usertype] *p drivers/media/pci/saa7164/saa7164-core.c:286:35: got unsigned char [usertype] * drivers/media/pci/saa7164/saa7164-core.c:352:44: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-core.c:527:53: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-core.c:129:30: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:133:38: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:133:72: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:134:35: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:287:61: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:288:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:289:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:290:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:291:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:292:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:293:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-core.c:294:65: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-fw.c:548:52: warning: incorrect type in argument 5 (different address spaces) drivers/media/pci/saa7164/saa7164-fw.c:548:52: expected unsigned char [usertype] *dst drivers/media/pci/saa7164/saa7164-fw.c:548:52: got unsigned char [noderef] [usertype] * drivers/media/pci/saa7164/saa7164-fw.c:579:44: warning: incorrect type in argument 5 (different address spaces) drivers/media/pci/saa7164/saa7164-fw.c:579:44: expected unsigned char [usertype] *dst drivers/media/pci/saa7164/saa7164-fw.c:579:44: got unsigned char [noderef] [usertype] * drivers/media/pci/saa7164/saa7164-fw.c:597:44: warning: incorrect type in argument 5 (different address spaces) drivers/media/pci/saa7164/saa7164-fw.c:597:44: expected unsigned char [usertype] *dst drivers/media/pci/saa7164/saa7164-fw.c:597:44: got unsigned char [noderef] [usertype] * drivers/media/pci/saa7164/saa7164-bus.c:36:36: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-bus.c:41:36: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-bus.c:151:19: warning: incorrect type in assignment (different base types) drivers/media/pci/saa7164/saa7164-bus.c:151:19: expected unsigned short [unsigned] [usertype] size drivers/media/pci/saa7164/saa7164-bus.c:151:19: got restricted __le16 [usertype] drivers/media/pci/saa7164/saa7164-bus.c:152:22: warning: incorrect type in assignment (different base types) drivers/media/pci/saa7164/saa7164-bus.c:152:22: expected unsigned int [unsigned] [usertype] command drivers/media/pci/saa7164/saa7164-bus.c:152:22: got restricted __le32 [usertype] drivers/media/pci/saa7164/saa7164-bus.c:153:30: warning: incorrect type in assignment (different base types) drivers/media/pci/saa7164/saa7164-bus.c:153:30: expected unsigned short [unsigned] [usertype] controlselector drivers/media/pci/saa7164/saa7164-bus.c:153:30: got restricted __le16 [usertype] drivers/media/pci/saa7164/saa7164-bus.c:172:20: warning: cast to restricted __le32 drivers/media/pci/saa7164/saa7164-bus.c:173:20: warning: cast to restricted __le32 drivers/media/pci/saa7164/saa7164-bus.c:206:28: warning: cast to restricted __le32 drivers/media/pci/saa7164/saa7164-bus.c:287:9: warning: incorrect type in argument 1 (different base types) drivers/media/pci/saa7164/saa7164-bus.c:287:9: expected unsigned int [unsigned] val drivers/media/pci/saa7164/saa7164-bus.c:287:9: got restricted __le32 [usertype] drivers/media/pci/saa7164/saa7164-bus.c:339:20: warning: cast to restricted __le32 drivers/media/pci/saa7164/saa7164-bus.c:340:20: warning: cast to restricted __le32 drivers/media/pci/saa7164/saa7164-bus.c:463:9: warning: incorrect type in argument 1 (different base types) drivers/media/pci/saa7164/saa7164-bus.c:463:9: expected unsigned int [unsigned] val drivers/media/pci/saa7164/saa7164-bus.c:463:9: got restricted __le32 [usertype] drivers/media/pci/saa7164/saa7164-bus.c:466:21: warning: cast to restricted __le16 drivers/media/pci/saa7164/saa7164-bus.c:467:24: warning: cast to restricted __le32 drivers/media/pci/saa7164/saa7164-bus.c:468:32: warning: cast to restricted __le16 drivers/media/pci/saa7164/saa7164-buffer.c:122:18: warning: incorrect type in assignment (different address spaces) drivers/media/pci/saa7164/saa7164-buffer.c:122:18: expected unsigned long long [noderef] [usertype] *cpu drivers/media/pci/saa7164/saa7164-buffer.c:122:18: got void * drivers/media/pci/saa7164/saa7164-buffer.c:127:21: warning: incorrect type in assignment (different address spaces) drivers/media/pci/saa7164/saa7164-buffer.c:127:21: expected unsigned long long [noderef] [usertype] *pt_cpu drivers/media/pci/saa7164/saa7164-buffer.c:127:21: got void * drivers/media/pci/saa7164/saa7164-buffer.c:134:20: warning: cast removes address space of expression drivers/media/pci/saa7164/saa7164-buffer.c:156:63: warning: incorrect type in argument 3 (different address spaces) drivers/media/pci/saa7164/saa7164-buffer.c:156:63: expected void *vaddr drivers/media/pci/saa7164/saa7164-buffer.c:156:63: got unsigned long long [noderef] [usertype] *cpu drivers/media/pci/saa7164/saa7164-buffer.c:179:57: warning: incorrect type in argument 3 (different address spaces) drivers/media/pci/saa7164/saa7164-buffer.c:179:57: expected void *vaddr drivers/media/pci/saa7164/saa7164-buffer.c:179:57: got unsigned long long [noderef] [usertype] *cpu drivers/media/pci/saa7164/saa7164-buffer.c:180:56: warning: incorrect type in argument 3 (different address spaces) drivers/media/pci/saa7164/saa7164-buffer.c:180:56: expected void *vaddr drivers/media/pci/saa7164/saa7164-buffer.c:180:56: got unsigned long long [noderef] [usertype] *pt_cpu drivers/media/pci/saa7164/saa7164-buffer.c:84:17: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-buffer.c:147:31: warning: dereference of noderef expression drivers/media/pci/saa7164/saa7164-buffer.c:148:17: warning: dereference of noderef expression Most are caused by pointers marked as __iomem when they aren't or not marked as __iomem when they should. Also note that readl/writel already do endian conversion, so there is no need to do it again. saa7164_bus_set/get were a bit tricky: you have to make sure the msg endian conversion is done at the right time, and that the code isn't using fields that are still little endian instead of cpu-endianness. The approach chosen is to convert just before writing to the ring buffer and to convert it back right after reading from the ring buffer. Signed-off-by: Hans Verkuil Cc: Steven Toth Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit dcba46d1070643e1de93a1182cb5357fc0c4f26e Author: Ernesto A. Fernández Date: Wed Aug 2 03:18:27 2017 -0300 btrfs: preserve i_mode if __btrfs_set_acl() fails commit d7d824966530acfe32b94d1ed672e6fe1638cd68 upstream. When changing a file's acl mask, btrfs_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by restoring the original mode bits if __btrfs_set_acl fails. Signed-off-by: Ernesto A. Fernández Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Ben Hutchings commit a8b3317a765caf1ad4867621bc898e99574fcfe9 Author: Ernesto A. Fernández Date: Sun Jul 23 22:32:54 2017 -0300 f2fs: preserve i_mode if __f2fs_set_acl() fails commit 14af20fcb1833dd776822361891963c90f7b0262 upstream. When changing a file's acl mask, __f2fs_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. Signed-off-by: Ernesto A. Fernández Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 610e6bd7911304e33dc8e74f8d21b5fda3010388 Author: Jaegeuk Kim Date: Tue Jul 11 14:56:49 2017 -0700 f2fs: Don't clear SGID when inheriting ACLs commit c925dc162f770578ff4a65ec9b08270382dba9e6 upstream. This patch copies commit b7f8a09f80: "btrfs: Don't clear SGID when inheriting ACLs" written by Jan. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Jan Kara Reviewed-by: Chao Yu Reviewed-by: Jan Kara Signed-off-by: Jaegeuk Kim Signed-off-by: Ben Hutchings commit afb4151249ec45c57de70c61310e8791c1c6b148 Author: Jan Kara Date: Sun Jul 30 23:33:01 2017 -0400 ext4: Don't clear SGID when inheriting ACLs commit a3bb2d5587521eea6dab2d05326abb0afb460abd upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __ext4_set_acl() into ext4_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Theodore Ts'o Signed-off-by: Jan Kara Reviewed-by: Andreas Gruenbacher [bwh: Backported to 3.16: - Keep using ext4_current_time() - Adjust context] Signed-off-by: Ben Hutchings commit b7ad938695fb3332ed49bf7682aa81e6f5e5d7b0 Author: Ernesto A. Fernández Date: Sun Jul 30 22:43:41 2017 -0400 ext4: preserve i_mode if __ext4_set_acl() fails commit 397e434176bb62bc6068d2210af1d876c6212a7e upstream. When changing a file's acl mask, __ext4_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. Signed-off-by: Ernesto A. Fernández Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara [bwh: Backported to 3.16: keep using ext4_current_time()] Signed-off-by: Ben Hutchings commit 10527cf5f3c08ebd33e3e0bc6794b8fa5e3ea964 Author: Ernesto A. Fernández Date: Wed Jul 12 06:55:35 2017 -0300 jfs: preserve i_mode if __jfs_set_acl() fails commit f070e5ac9bc7de71c34402048ce5526dccbd347c upstream. When changing a file's acl mask, __jfs_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. Signed-off-by: Ernesto A. Fernández Signed-off-by: Dave Kleikamp [bwh: Backported to 3.16: keep using CURRENT_TIME] Signed-off-by: Ben Hutchings commit 270092a915c5a20c0ac0641e12f0b2cf189e020f Author: Jan Kara Date: Thu Jun 22 15:31:10 2017 +0200 jfs: Don't clear SGID when inheriting ACLs commit 9bcf66c72d726322441ec82962994e69157613e4 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __jfs_set_acl() into jfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: jfs-discussion@lists.sourceforge.net Signed-off-by: Jan Kara Signed-off-by: Dave Kleikamp [bwh: Backported to 3.16: - Keep using CURRENT_TIME - Adjust context] Signed-off-by: Ben Hutchings commit 77eb35944909da453451723e423e5a03e8dfcf4b Author: Ernesto A. Fernández Date: Mon Jul 17 18:42:41 2017 +0200 reiserfs: preserve i_mode if __reiserfs_set_acl() fails commit fcea8aed91f53b51f9b943dc01f12d8aa666c720 upstream. When changing a file's acl mask, reiserfs_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. Signed-off-by: Ernesto A. Fernández Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit 8edaf0739593be85c87ee54bd9c1673468695a91 Author: Jan Kara Date: Thu Jun 22 09:32:49 2017 +0200 reiserfs: Don't clear SGID when inheriting ACLs commit 6883cd7f68245e43e91e5ee583b7550abf14523f upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __reiserfs_set_acl() into reiserfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: reiserfs-devel@vger.kernel.org Signed-off-by: Jan Kara [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 9b38ef4fd288d1785435ecd61bfc4ead3f9aab61 Author: Jan Kara Date: Wed Jun 21 15:02:47 2017 +0200 hfsplus: Don't clear SGID when inheriting ACLs commit 84969465ddc4f8aeb3b993123b571aa01c5f2683 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by creating __hfsplus_set_posix_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Jan Kara [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit ff8c7374e5b333918bed10a85eba73c39989843d Author: Ben Hutchings Date: Sun Oct 8 14:48:44 2017 +0100 ext3: preserve i_mode if ext2_set_acl() fails Based on Ernesto A. Fernández's fix for ext2 (commit fe26569eb919), from which the following description is taken: > When changing a file's acl mask, ext2_set_acl() will first set the group > bits of i_mode to the value of the mask, and only then set the actual > extended attribute representing the new acl. > > If the second part fails (due to lack of space, for example) and the file > had no acl attribute to begin with, the system will from now on assume > that the mask permission bits are actual group permission bits, potentially > granting access to the wrong users. > > Prevent this by only changing the inode mode after the acl has been set. Cc: Ernesto A. Fernández Cc: Jan Kara Signed-off-by: Ben Hutchings commit f651969ce7668b24cdeffb5a1e73fc7d2ef382ef Author: Ben Hutchings Date: Fri Oct 6 03:18:40 2017 +0100 ext3: Don't clear SGID when inheriting ACLs Based on Jan Kara's fix for ext2 (commit a992f2d38e4c), from which the following description is taken: > When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit > set, DIR1 is expected to have SGID bit set (and owning group equal to > the owning group of 'DIR0'). However when 'DIR0' also has some default > ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on > 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving the posix_acl_update_mode() call up from __ext3_set_acl() into ext3_set_acl(). Fixes: 073931017b49 ("posix_acl: Clear SGID bit when setting file permissions") Cc: linux-ext4@vger.kernel.org Cc: Jan Kara Signed-off-by: Ben Hutchings commit c698e2b3c6e8a36b9098974bd4f3f8b1e7e88b97 Author: Ernesto A. Fernández Date: Wed Jul 12 06:54:19 2017 -0300 ext2: preserve i_mode if ext2_set_acl() fails commit fe26569eb9197d845d73abe7dd20f603d79eb031 upstream. When changing a file's acl mask, ext2_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. [JK: Rebased on top of "ext2: Don't clear SGID when inheriting ACLs"] Signed-off-by: Ernesto A. Fernández Signed-off-by: Jan Kara [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 7be5730b591637137d88d3dd82e9d6305e7aef80 Author: Jan Kara Date: Wed Jun 21 14:34:15 2017 +0200 ext2: Don't clear SGID when inheriting ACLs commit a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by creating __ext2_set_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: linux-ext4@vger.kernel.org Signed-off-by: Jan Kara [bwh: Backported to 3.16: keep using CURRENT_TIME_SEC] Signed-off-by: Ben Hutchings commit 4bb02b6aa1d043d9d9d2b24cf11a6af8e88c4767 Author: Helge Deller Date: Fri Jul 14 14:49:38 2017 -0700 mm: fix overflow check in expand_upwards() commit 37511fb5c91db93d8bd6e3f52f86e5a7ff7cfcdf upstream. Jörn Engel noticed that the expand_upwards() function might not return -ENOMEM in case the requested address is (unsigned long)-PAGE_SIZE and if the architecture didn't defined TASK_SIZE as multiple of PAGE_SIZE. Affected architectures are arm, frv, m68k, blackfin, h8300 and xtensa which all define TASK_SIZE as 0xffffffff, but since none of those have an upwards-growing stack we currently have no actual issue. Nevertheless let's fix this just in case any of the architectures with an upward-growing stack (currently parisc, metag and partly ia64) define TASK_SIZE similar. Link: http://lkml.kernel.org/r/20170702192452.GA11868@p100.box Fixes: bd726c90b6b8 ("Allow stack to grow up to address space limit") Signed-off-by: Helge Deller Reported-by: Jörn Engel Cc: Hugh Dickins Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 5116caf8fc868e061e074da65947a9ff6f856bff Author: Richard Weinberger Date: Fri Jun 16 16:21:44 2017 +0200 ubifs: Don't leak kernel memory to the MTD commit 4acadda74ff8b949c448c0282765ae747e088c87 upstream. When UBIFS prepares data structures which will be written to the MTD it ensues that their lengths are multiple of 8. Since it uses kmalloc() the padded bytes are left uninitialized and we leak a few bytes of kernel memory to the MTD. To make sure that all bytes are initialized, let's switch to kzalloc(). Kzalloc() is fine in this case because the buffers are not huge and in the IO path the performance bottleneck is anyway the MTD. Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger [bwh: Backported to 3.16: - Drop change in ubifs_jnl_xrename() - Adjust context] Signed-off-by: Ben Hutchings commit 112ea4a19a8c3f88ff392cb0f35945ad7151728a Author: Richard Weinberger Date: Wed May 17 00:20:27 2017 +0200 ubifs: Correctly evict xattr inodes commit 272eda8298dc82eb411ece82bbb2c62911087b24 upstream. UBIFS handles extended attributes just like files, as consequence of that, they also have inodes. Therefore UBIFS does all the inode machinery also for xattrs. Since new inodes have i_nlink of 1, a file or xattr inode will be evicted if i_nlink goes down to 0 after an unlink. UBIFS assumes this model also for xattrs, which is not correct. One can create a file "foo" with xattr "user.test". By reading "user.test" an inode will be created, and by deleting "user.test" it will get evicted later. The assumption breaks if the file "foo", which hosts the xattrs, will be removed. VFS nor UBIFS does not remove each xattr via ubifs_xattr_remove(), it just removes the host inode from the TNC and all underlying xattr nodes too and the inode will remain in the cache and wastes memory. To solve this problem, remove xattr inodes from the VFS inode cache in ubifs_xattr_remove() to make sure that they get evicted. Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 269bed5aa035e4e38fe91ba6502c3d908f6ffae6 Author: Jason A. Donenfeld Date: Sat Jun 10 04:59:07 2017 +0200 sunrpc: use constant time memory comparison for mac commit 15a8b93fd5690de017ce665382ea45e5d61811a4 upstream. Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld Cc: "J. Bruce Fields" Cc: Jeff Layton Cc: Trond Myklebust Cc: Anna Schumaker Cc: linux-nfs@vger.kernel.org Signed-off-by: Anna Schumaker [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 5ceaff45fb7d526c6bab53c89cb740685dd960ce Author: Luis R. Rodriguez Date: Wed Jul 12 14:33:27 2017 -0700 sysctl: fix lax sysctl_check_table() sanity check commit 89c5b53b16bf577079d4f0311406dbea3c71202c upstream. Patch series "sysctl: few fixes", v5. I've been working on making kmod more deterministic, and as I did that I couldn't help but notice a few issues with sysctl. My end goal was just to fix unsigned int support, which back then was completely broken. Liping Zhang has sent up small atomic fixes, however it still missed yet one more fix and Alexey Dobriyan had also suggested to just drop array support given its complexity. I have inspected array support using Coccinelle and indeed its not that popular, so if in fact we can avoid it for new interfaces, I agree its best. I did develop a sysctl stress driver but will hold that off for another series. This patch (of 5): Commit 7c60c48f58a7 ("sysctl: Improve the sysctl sanity checks") improved sanity checks considerbly, however the enhancements on sysctl_check_table() meant adding a functional change so that only the last table entry's sanity error is propagated. It also changed the way errors were propagated so that each new check reset the err value, this means only last sanity check computed is used for an error. This has been in the kernel since v3.4 days. Fix this by carrying on errors from previous checks and iterations as we traverse the table and ensuring we keep any error from previous checks. We keep iterating on the table even if an error is found so we can complain for all errors found in one shot. This works as -EINVAL is always returned on error anyway, and the check for error is any non-zero value. Fixes: 7c60c48f58a7 ("sysctl: Improve the sysctl sanity checks") Link: http://lkml.kernel.org/r/20170519033554.18592-2-mcgrof@kernel.org Signed-off-by: Luis R. Rodriguez Cc: Al Viro Cc: "Eric W. Biederman" Cc: Alexey Dobriyan Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit b8e534a556b1a6a6eca8fcdca79725f0dea21555 Author: Chen Hong Date: Sun Jul 2 15:11:10 2017 -0700 Input: i8042 - fix crash at boot time commit 340d394a789518018f834ff70f7534fc463d3226 upstream. The driver checks port->exists twice in i8042_interrupt(), first when trying to assign temporary "serio" variable, and second time when deciding whether it should call serio_interrupt(). The value of port->exists may change between the 2 checks, and we may end up calling serio_interrupt() with a NULL pointer: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [] _spin_lock_irqsave+0x1f/0x40 PGD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:[] [] _spin_lock_irqsave+0x1f/0x40 RSP: 0018:ffff880028203cc0 EFLAGS: 00010082 RAX: 0000000000010000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000282 RSI: 0000000000000098 RDI: 0000000000000050 RBP: ffff880028203cc0 R08: ffff88013e79c000 R09: ffff880028203ee0 R10: 0000000000000298 R11: 0000000000000282 R12: 0000000000000050 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000098 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000050 CR3: 0000000001a85000 CR4: 00000000001407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88013e79c000, task ffff88013e79b500) Stack: ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000098 ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac Call Trace: [] serio_interrupt+0x36/0xa0 [] i8042_interrupt+0x132/0x3a0 [] ? kvm_clock_read+0x1c/0x20 [] ? kvm_clock_get_cycles+0x9/0x10 [] handle_IRQ_event+0x60/0x170 [] ? kvm_guest_apic_eoi_write+0x44/0x50 [] handle_edge_irq+0xde/0x180 [] handle_irq+0x49/0xa0 [] do_IRQ+0x6c/0xf0 [] ret_from_intr+0x0/0x11 [] ? __do_softirq+0x73/0x1e0 [] ? hrtimer_interrupt+0x14b/0x260 [] ? call_softirq+0x1c/0x30 [] ? do_softirq+0x65/0xa0 [] ? irq_exit+0x85/0x90 [] ? smp_apic_timer_interrupt+0x70/0x9b [] ? apic_timer_interrupt+0x13/0x20 To avoid the issue let's change the second check to test whether serio is NULL or not. Also, let's take i8042_lock in i8042_start() and i8042_stop() instead of trying to be overly smart and using memory barriers. Signed-off-by: Chen Hong [dtor: take lock in i8042_start()/i8042_stop()] Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 114e0337e1b6f67628e8817648f233759eeb4ca5 Author: Dan Carpenter Date: Mon Jul 10 10:21:40 2017 +0300 PM / QoS: return -EINVAL for bogus strings commit 2ca30331c156ca9e97643ad05dd8930b8fe78b01 upstream. In the current code, if the user accidentally writes a bogus command to this sysfs file, then we set the latency tolerance to an uninitialized variable. Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type) Signed-off-by: Dan Carpenter Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 6614442bb0e21454bacb94aeefa26cad248cfd83 Author: Michael Ellerman Date: Tue Jul 11 22:10:54 2017 +1000 powerpc/64: Fix atomic64_inc_not_zero() to return an int commit 01e6a61aceb82e13bec29502a8eb70d9574f97ad upstream. Although it's not documented anywhere, there is an expectation that atomic64_inc_not_zero() returns a result which fits in an int. This is the behaviour implemented on all arches except powerpc. This has caused at least one bug in practice, in the percpu-refcount code, where the long result from our atomic64_inc_not_zero() was truncated to an int leading to lost references and stuck systems. That was worked around in that code in commit 966d2b04e070 ("percpu-refcount: fix reference leak during percpu-atomic transition"). To the best of my grepping abilities there are no other callers in-tree which truncate the value, but we should fix it anyway. Because the breakage is subtle and potentially very harmful I'm also tagging it for stable. Code generation is largely unaffected because in most cases the callers are just using the result for a test anyway. In particular the case of fget() that was mentioned in commit a6cf7ed5119f ("powerpc/atomic: Implement atomic*_inc_not_zero") generates exactly the same code. Fixes: a6cf7ed5119f ("powerpc/atomic: Implement atomic*_inc_not_zero") Noticed-by: Linus Torvalds Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit bc00952a27f2120b700753a5e7c1d2998b53d914 Author: Gilad Ben-Yossef Date: Wed Jun 28 10:22:03 2017 +0300 crypto: atmel - only treat EBUSY as transient if backlog commit 1606043f214f912a52195293614935811a6e3e53 upstream. The Atmel SHA driver was treating -EBUSY as indication of queueing to backlog without checking that backlog is enabled for the request. Fix it by checking request flags. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit d06bac317ecbb92098b14dd022fc3ad6037c8154 Author: Horia Geantă Date: Fri Jul 7 16:57:06 2017 +0300 crypto: caam - fix signals handling commit 7459e1d25ffefa2b1be799477fcc1f6c62f6cec7 upstream. Driver does not properly handle the case when signals interrupt wait_for_completion_interruptible(): -it does not check for return value -completion structure is allocated on stack; in case a signal interrupts the sleep, it will go out of scope, causing the worker thread (caam_jr_dequeue) to fail when it accesses it wait_for_completion_interruptible() is replaced with uninterruptable wait_for_completion(). We choose to block all signals while waiting for I/O (device executing the split key generation job descriptor) since the alternative - in order to have a deterministic device state - would be to flush the job ring (aborting *all* in-progress jobs). Fixes: 045e36780f115 ("crypto: caam - ahash hmac support") Fixes: 4c1ec1f930154 ("crypto: caam - refactor key_gen, sg") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 3e7aa3a9721511ce89b2588bb23affe8016b6903 Author: Anton Blanchard Date: Thu Jun 15 09:46:39 2017 +1000 powerpc: Fix emulation of mfocrf in emulate_step() commit 64e756c55aa46fc18fd53e8f3598b73b528d8637 upstream. From POWER4 onwards, mfocrf() only places the specified CR field into the destination GPR, and the rest of it is set to 0. The PowerPC AS from version 3.0 now requires this behaviour. The emulation code currently puts the entire CR into the destination GPR. Fix it. Fixes: 6888199f7fe5 ("[POWERPC] Emulate more instructions in software") Signed-off-by: Anton Blanchard Acked-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit a1325b1bccc31f16d6da5cff46dd722ab620b361 Author: Nicholas Bellinger Date: Fri Jul 7 14:45:49 2017 -0700 iscsi-target: Add login_keys_workaround attribute for non RFC initiators commit 138d351eefb727ab9e41a3dc5f112ceb4f6e59f2 upstream. This patch re-introduces part of a long standing login workaround that was recently dropped by: commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46 Author: Nicholas Bellinger Date: Sun Apr 2 13:36:44 2017 -0700 iscsi-target: Drop work-around for legacy GlobalSAN initiator Namely, the workaround for FirstBurstLength ended up being required by Mellanox Flexboot PXE boot ROMs as reported by Robert. So this patch re-adds the work-around for FirstBurstLength within iscsi_check_proposer_for_optional_reply(), and makes the key optional to respond when the initiator does not propose, nor respond to it. Also as requested by Arun, this patch introduces a new TPG attribute named 'login_keys_workaround' that controls the use of both the FirstBurstLength workaround, as well as the two other existing workarounds for gPXE iSCSI boot client. By default, the workaround is enabled with login_keys_workaround=1, since Mellanox FlexBoot requires it, and Arun has verified the Qlogic MSFT initiator already proposes FirstBurstLength, so it's uneffected by this re-adding this part of the original work-around. Reported-by: Robert LeBlanc Cc: Robert LeBlanc Reviewed-by: Arun Easi Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.16: - Use DEF_TPG_ATTRIB() + TPG_ATTR() to define the attribute - Adjust context] Signed-off-by: Ben Hutchings commit 059007511bce001b30cea462b778182d53e37722 Author: James Hogan Date: Thu Jun 29 10:12:34 2017 +0100 MIPS: Negate error syscall return in trace commit 4f32a39d49b25eaa66d2420f1f03d371ea4cd906 upstream. The sys_exit trace event takes a single return value for the system call, which MIPS passes the value of the $v0 (result) register, however MIPS returns positive error codes in $v0 with $a3 specifying that $v0 contains an error code. As a result erroring system calls are traced returning positive error numbers that can't always be distinguished from success. Use regs_return_value() to negate the error code if $a3 is set. Fixes: 1d7bf993e073 ("MIPS: ftrace: Add support for syscall tracepoints.") Signed-off-by: James Hogan Cc: Steven Rostedt Cc: Ingo Molnar Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16651/ Acked-by: Steven Rostedt (VMware) Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 0ad934334c03a5313efb8f433558bf4d84b56920 Author: Oliver O'Halloran Date: Thu Jul 6 18:46:43 2017 +1000 powerpc/asm: Mark cr0 as clobbered in mftb() commit 2400fd822f467cb4c886c879d8ad99feac9cf319 upstream. The workaround for the CELL timebase bug does not correctly mark cr0 as being clobbered. This means GCC doesn't know that the asm block changes cr0 and might leave the result of an unrelated comparison in cr0 across the block, which we then trash, leading to basically random behaviour. Fixes: 859deea949c3 ("[POWERPC] Cell timebase bug workaround") Signed-off-by: Oliver O'Halloran [mpe: Tweak change log and flag for stable] Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit 6c49ba2f8694c911884e592964f2d05273d8a4c8 Author: Sahitya Tummala Date: Mon Jul 10 15:50:00 2017 -0700 fs/dcache.c: fix spin lockup issue on nlru->lock commit b17c070fb624cf10162cf92ea5e1ec25cd8ac176 upstream. __list_lru_walk_one() acquires nlru spin lock (nlru->lock) for longer duration if there are more number of items in the lru list. As per the current code, it can hold the spin lock for upto maximum UINT_MAX entries at a time. So if there are more number of items in the lru list, then "BUG: spinlock lockup suspected" is observed in the below path: spin_bug+0x90 do_raw_spin_lock+0xfc _raw_spin_lock+0x28 list_lru_add+0x28 dput+0x1c8 path_put+0x20 terminate_walk+0x3c path_lookupat+0x100 filename_lookup+0x6c user_path_at_empty+0x54 SyS_faccessat+0xd0 el0_svc_naked+0x24 This nlru->lock is acquired by another CPU in this path - d_lru_shrink_move+0x34 dentry_lru_isolate_shrink+0x48 __list_lru_walk_one.isra.10+0x94 list_lru_walk_node+0x40 shrink_dcache_sb+0x60 do_remount_sb+0xbc do_emergency_remount+0xb0 process_one_work+0x228 worker_thread+0x2e0 kthread+0xf4 ret_from_fork+0x10 Fix this lockup by reducing the number of entries to be shrinked from the lru list to 1024 at once. Also, add cond_resched() before processing the lru list again. Link: http://marc.info/?t=149722864900001&r=1&w=2 Link: http://lkml.kernel.org/r/1498707575-2472-1-git-send-email-stummala@codeaurora.org Signed-off-by: Sahitya Tummala Suggested-by: Jan Kara Suggested-by: Vladimir Davydov Acked-by: Vladimir Davydov Cc: Alexander Polakov Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit af703e1767c5b8a7522f6838b13c679c7b9c7f0f Author: Michal Hocko Date: Mon Jul 10 15:49:51 2017 -0700 mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack commit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f upstream. Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") has introduced a regression in some rust and Java environments which are trying to implement their own stack guard page. They are punching a new MAP_FIXED mapping inside the existing stack Vma. This will confuse expand_{downwards,upwards} into thinking that the stack expansion would in fact get us too close to an existing non-stack vma which is a correct behavior wrt safety. It is a real regression on the other hand. Let's work around the problem by considering PROT_NONE mapping as a part of the stack. This is a gros hack but overflowing to such a mapping would trap anyway an we only can hope that usespace knows what it is doing and handle it propely. Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas") Link: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.cz Signed-off-by: Michal Hocko Debugged-by: Vlastimil Babka Cc: Ben Hutchings Cc: Willy Tarreau Cc: Oleg Nesterov Cc: Rik van Riel Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit c4e4270d90c6f8d0a241425d3b2abf8a2be28000 Author: Mario Kleiner Date: Fri Jul 7 04:57:04 2017 +0200 drm/radeon: Fix eDP for single-display iMac10,1 (v2) commit 564d8a2cf3abf16575af48bdc3e86e92ee8a617d upstream. The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via MiniDP to DVI or HDMI adapter. However, booting the machine single-display with only eDP panel results in a completely black display - even backlight powering off, as soon as the radeon modesetting driver loads. This patch fixes the single dispay eDP case by assigning encoders based on dig->linkb, similar to DCE-4+. While this should not be generally necessary (Alex: "...atom on normal boards should be able to handle any mapping."), Apple seems to use some special routing here. One remaining problem not solved by this patch is that an external Minidisplayport->DP sink does still not work on iMac10,1, whereas external DVI and HDMI sinks continue to work. The problem affects at least all tested kernels since Linux 3.13 - didn't test earlier kernels, so backporting to stable probably makes sense. v2: With the original patch from 2016, Alex was worried it will break other DCE3.2 systems. Use dmi_match() to apply this special encoder assignment only for the Apple iMac 10,1 from late 2009. Signed-off-by: Mario Kleiner Cc: Alex Deucher Cc: Michel Dänzer Signed-off-by: Alex Deucher [bwh: Backported to 3.16: - Return the selected encoder rather than assiging it - Adjust context] Signed-off-by: Ben Hutchings commit 3d63d77a528a08feed92562c0f978d2afeae5d2c Author: Srinivas Dasari Date: Fri Jul 7 01:43:42 2017 +0300 cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES commit d7f13f7450369281a5d0ea463cc69890a15923ae upstream. validate_scan_freqs() retrieves frequencies from attributes nested in the attribute NL80211_ATTR_SCAN_FREQUENCIES with nla_get_u32(), which reads 4 bytes from each attribute without validating the size of data received. Attributes nested in NL80211_ATTR_SCAN_FREQUENCIES don't have an nla policy. Validate size of each attribute before parsing to avoid potential buffer overread. Fixes: 2a519311926 ("cfg80211/nl80211: scanning (and mac80211 update to use it)") Signed-off-by: Srinivas Dasari Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 2a5d2a519162f5c52121c1053439535f2de705af Author: Srinivas Dasari Date: Fri Jul 7 01:43:41 2017 +0300 cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE commit 8feb69c7bd89513be80eb19198d48f154b254021 upstream. Buffer overread may happen as nl80211_set_station() reads 4 bytes from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without validating the size of data received when userspace sends less than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE. Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid the buffer overread. Fixes: 3b1c5a5307f ("{cfg,nl}80211: mesh power mode primitives and userspace access") Signed-off-by: Srinivas Dasari Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit e6a0a92a731219421be411f721fe973a742c4c35 Author: Srinivas Dasari Date: Fri Jul 7 01:43:39 2017 +0300 cfg80211: Check if PMKID attribute is of expected size commit 9361df14d1cbf966409d5d6f48bb334384fbe138 upstream. nla policy checks for only maximum length of the attribute data when the attribute type is NLA_BINARY. If userspace sends less data than specified, the wireless drivers may access illegal memory. When type is NLA_UNSPEC, nla policy check ensures that userspace sends minimum specified length number of bytes. Remove type assignment to NLA_BINARY from nla_policy of NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum WLAN_PMKID_LEN bytes are received from userspace with NL80211_ATTR_PMKID. Fixes: 67fbb16be69d ("nl80211: PMKSA caching support") Signed-off-by: Srinivas Dasari Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 74247d9c33894549f674f4cc1a2751fa61a3fde1 Author: Jiang Yi Date: Sun Jun 25 12:28:50 2017 -0700 target: Fix COMPARE_AND_WRITE caw_sem leak during se_cmd quiesce commit 1d6ef276594a781686058802996e09c8550fd767 upstream. This patch addresses a COMPARE_AND_WRITE se_device->caw_sem leak, that would be triggered during normal se_cmd shutdown or abort via __transport_wait_for_tasks(). This would occur because target_complete_cmd() would catch this early and do complete_all(&cmd->t_transport_stop_comp), but since target_complete_ok_work() or target_complete_failure_work() are never called to invoke se_cmd->transport_complete_callback(), the COMPARE_AND_WRITE specific callbacks never release caw_sem. To address this special case, go ahead and release caw_sem directly from target_complete_cmd(). (Remove '&& success' from check, to release caw_sem regardless of scsi_status - nab) Signed-off-by: Jiang Yi Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit deebb33450ede9b554962bdad8556a2b50cc4f1f Author: Jarkko Sakkinen Date: Tue Jun 20 11:38:02 2017 +0200 tpm: fix a kernel memory leak in tpm-sysfs.c commit 13b47cfcfc60495cde216eef4c01040d76174cbe upstream. While cleaning up sysfs callback that prints EK we discovered a kernel memory leak. This commit fixes the issue by zeroing the buffer used for TPM command/response. The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or xen-tpmfront. Fixes: 0883743825e3 ("TPM: sysfs functions consolidation") Reported-by: Jason Gunthorpe Tested-by: Stefan Berger Signed-off-by: Jarkko Sakkinen Signed-off-by: James Morris [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 20f57a543a03dca09c6012c6ad6acd212b345d82 Author: Dan Carpenter Date: Fri Jun 23 11:29:00 2017 +0300 rtc: rtc-nuc900: fix loop timeout test commit d0a67c372df410b579197ea818596001fe20070d upstream. We should change this post-op to a pre-op because we want the loop to exit with "timeout" set to zero. Fixes: 0a89b55364e0 ("nuc900/rtc: change the waiting for device ready implement") Signed-off-by: Dan Carpenter Signed-off-by: Alexandre Belloni Signed-off-by: Ben Hutchings commit ef2490dcadf35d91627ae37676419c31517c3c74 Author: Rabin Vincent Date: Thu Jun 29 16:01:42 2017 +0200 CIFS: fix circular locking dependency commit 966681c9f029afd5decee069b7658bb58ad0a863 upstream. When a CIFS filesystem is mounted with the forcemand option and the following command is run on it, lockdep warns about a circular locking dependency between CifsInodeInfo::lock_sem and the inode lock. while echo foo > hello; do :; done & while touch -c hello; do :; done cifs_writev() takes the locks in the wrong order, but note that we can't only flip the order around because it releases the inode lock before the call to generic_write_sync() while it holds the lock_sem across that call. But, AFAICS, there is no need to hold the CifsInodeInfo::lock_sem across the generic_write_sync() call either, so we can release both the locks before generic_write_sync(), and change the order. ====================================================== WARNING: possible circular locking dependency detected 4.12.0-rc7+ #9 Not tainted ------------------------------------------------------ touch/487 is trying to acquire lock: (&cifsi->lock_sem){++++..}, at: cifsFileInfo_put+0x88f/0x16a0 but task is already holding lock: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: utimes_common+0x3ad/0x870 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#11){+.+.+.}: __lock_acquire+0x1f74/0x38f0 lock_acquire+0x1cc/0x600 down_write+0x74/0x110 cifs_strict_writev+0x3cb/0x8c0 __vfs_write+0x4c1/0x930 vfs_write+0x14c/0x2d0 SyS_write+0xf7/0x240 entry_SYSCALL_64_fastpath+0x1f/0xbe -> #0 (&cifsi->lock_sem){++++..}: check_prevs_add+0xfa0/0x1d10 __lock_acquire+0x1f74/0x38f0 lock_acquire+0x1cc/0x600 down_write+0x74/0x110 cifsFileInfo_put+0x88f/0x16a0 cifs_setattr+0x992/0x1680 notify_change+0x61a/0xa80 utimes_common+0x3d4/0x870 do_utimes+0x1c1/0x220 SyS_utimensat+0x84/0x1a0 entry_SYSCALL_64_fastpath+0x1f/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sb->s_type->i_mutex_key#11); lock(&cifsi->lock_sem); lock(&sb->s_type->i_mutex_key#11); lock(&cifsi->lock_sem); *** DEADLOCK *** 2 locks held by touch/487: #0: (sb_writers#10){.+.+.+}, at: mnt_want_write+0x41/0xb0 #1: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: utimes_common+0x3ad/0x870 stack backtrace: CPU: 0 PID: 487 Comm: touch Not tainted 4.12.0-rc7+ #9 Call Trace: dump_stack+0xdb/0x185 print_circular_bug+0x45b/0x790 __lock_acquire+0x1f74/0x38f0 lock_acquire+0x1cc/0x600 down_write+0x74/0x110 cifsFileInfo_put+0x88f/0x16a0 cifs_setattr+0x992/0x1680 notify_change+0x61a/0xa80 utimes_common+0x3d4/0x870 do_utimes+0x1c1/0x220 SyS_utimensat+0x84/0x1a0 entry_SYSCALL_64_fastpath+0x1f/0xbe Fixes: 19dfc1f5f2ef03a52 ("cifs: fix the race in cifs_writev()") Signed-off-by: Rabin Vincent Signed-off-by: Steve French Acked-by: Pavel Shilovsky [bwh: Backported to 3.16: - Keep using mutex_{,un}lock() - Update both branches of if (!cifs_find_lock_conflict(...))] Signed-off-by: Ben Hutchings commit 15ee118283dbb3636dc6fbab13291ca2a3d17758 Author: Herbert Xu Date: Tue Jul 4 12:21:12 2017 +0800 crypto: sha1-ssse3 - Disable avx2 commit b82ce24426a4071da9529d726057e4e642948667 upstream. It has been reported that sha1-avx2 can cause page faults by reading beyond the end of the input. This patch disables it until it can be fixed. Fixes: 7c1da8d0d046 ("crypto: sha - SHA1 transform x86_64 AVX2") Reported-by: Jan Stancek Signed-off-by: Herbert Xu [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit a06749016adf68ad281256ddcf74e3bdf7ae28f7 Author: Jiri Olsa Date: Thu Jun 29 11:38:11 2017 +0200 s390/syscalls: Fix out of bounds arguments access commit c46fc0424ced3fb71208e72bd597d91b9169a781 upstream. Zorro reported following crash while having enabled syscall tracing (CONFIG_FTRACE_SYSCALLS): Unable to handle kernel pointer dereference at virtual ... Oops: 0011 [#1] SMP DEBUG_PAGEALLOC SNIP Call Trace: ([<000000000024d79c>] ftrace_syscall_enter+0xec/0x1d8) [<00000000001099c6>] do_syscall_trace_enter+0x236/0x2f8 [<0000000000730f1c>] sysc_tracesys+0x1a/0x32 [<000003fffcf946a2>] 0x3fffcf946a2 INFO: lockdep is turned off. Last Breaking-Event-Address: [<000000000022dd44>] rb_event_data+0x34/0x40 ---[ end trace 8c795f86b1b3f7b9 ]--- The crash happens in syscall_get_arguments function for syscalls with zero arguments, that will try to access first argument (args[0]) in event entry, but it's not allocated. Bail out of there are no arguments. Reported-by: Zorro Lang Signed-off-by: Jiri Olsa Signed-off-by: Martin Schwidefsky Signed-off-by: Ben Hutchings commit 01e831610b06a7b1eb2edda3047a49154b04e13a Author: Jamal Hadi Salim Date: Mon Jul 3 09:51:50 2017 -0400 net: reflect mark on tcp syn ack packets commit e05a90ec9e1680952454ea9510da9a761a5baac9 upstream. SYN-ACK responses on a server in response to a SYN from a client did not get the injected skb mark that was tagged on the SYN packet. Fixes: 84f39b08d786 ("net: support marking accepting TCP sockets") Reviewed-by: Lorenzo Colitti Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ae186935cce3aed53f9306db1ccc9bae2a531041 Author: Boris Pismenny Date: Tue Jun 27 15:09:13 2017 +0300 RDMA/uverbs: Check port number supplied by user verbs cmds commit 5ecce4c9b17bed4dc9cb58bfb10447307569b77b upstream. The ib_uverbs_create_ah() ind ib_uverbs_modify_qp() calls receive the port number from user input as part of its attributes and assumes it is valid. Down on the stack, that parameter is used to access kernel data structures. If the value is invalid, the kernel accesses memory it should not. To prevent this, verify the port number before using it. BUG: KASAN: use-after-free in ib_uverbs_create_ah+0x6d5/0x7b0 Read of size 4 at addr ffff880018d67ab8 by task syz-executor/313 BUG: KASAN: slab-out-of-bounds in modify_qp.isra.4+0x19d0/0x1ef0 Read of size 4 at addr ffff88006c40ec58 by task syz-executor/819 Fixes: 67cdb40ca444 ("[IB] uverbs: Implement more commands") Fixes: 189aba99e70 ("IB/uverbs: Extend modify_qp and support packet pacing") Cc: Cc: Yevgeny Kliteynik Cc: Tziporet Koren Cc: Alex Polak Signed-off-by: Boris Pismenny Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford [bwh: Backported to 3.16: - In modify_qp(), command structure is cmd not cmd->base - In ib_uverbs_create_ah(), add definition of ib_dev - Adjust context] Signed-off-by: Ben Hutchings commit 9dfc4a5a483dc9e7473d28a3b2b475f4cc3e6985 Author: Yuval Shaia Date: Wed Jan 25 18:41:37 2017 +0200 IB/core: Add inline function to validate port commit 24dc831b77eca9361cf835be59fa69ea0e471afc upstream. Signed-off-by: Yuval Shaia Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford [bwh: Backported to 3.16: - Drop inapplicable changes - Adjust context] Signed-off-by: Ben Hutchings commit ad84b0f7ee017b5eb0819f79bf00e47b4290ce32 Author: Ira Weiny Date: Wed May 13 20:02:55 2015 -0400 IB/core: Create common start/end port functions commit 0cf18d7723055709faf51b50f5a33253b480637f upstream. Previously start_port and end_port were defined in 2 places, cache.c and device.c and this prevented their use in other modules. Make these common functions, change the name to reflect the rdma name space, and update existing users. Signed-off-by: Ira Weiny Signed-off-by: Doug Ledford Signed-off-by: Ben Hutchings commit 48446d4163fca4247c941129713b23571bfed905 Author: Thomas Bogendoerfer Date: Mon Jul 3 10:38:05 2017 +0200 parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs commit 33f9e02495d15a061f0c94ef46f5103a2d0c20f3 upstream. Enabling parport pc driver on a B2600 (and probably other 64bit PARISC systems) produced following BUG: CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-30198-g1132d5e #156 task: 000000009e050000 task.stack: 000000009e04c000 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00001000000001101111111100001111 Not tainted r00-03 000000ff0806ff0f 000000009e04c990 0000000040871b78 000000009e04cac0 r04-07 0000000040c14de0 ffffffffffffffff 000000009e07f098 000000009d82d200 r08-11 000000009d82d210 0000000000000378 0000000000000000 0000000040c345e0 r12-15 0000000000000005 0000000040c345e0 0000000000000000 0000000040c9d5e0 r16-19 0000000040c345e0 00000000f00001c4 00000000f00001bc 0000000000000061 r20-23 000000009e04ce28 0000000000000010 0000000000000010 0000000040b89e40 r24-27 0000000000000003 0000000000ffffff 000000009d82d210 0000000040c14de0 r28-31 0000000000000000 000000009e04ca90 000000009e04cb40 0000000000000000 sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000404aece0 00000000404aece4 IIR: 03ffe01f ISR: 0000000010340000 IOR: 000001781304cac8 CPU: 0 CR30: 000000009e04c000 CR31: 00000000e2976de2 ORIG_R28: 0000000000000200 IAOQ[0]: sba_dma_supported+0x80/0xd0 IAOQ[1]: sba_dma_supported+0x84/0xd0 RP(r2): parport_pc_probe_port+0x178/0x1200 Cause is a call to dma_coerce_mask_and_coherenet in parport_pc_probe_port, which PARISC DMA API doesn't handle very nicely. This commit gives back DMA_ERROR_CODE for DMA API calls, if device isn't capable of DMA transaction. Signed-off-by: Thomas Bogendoerfer Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit 5855157cb427f2ff20b5306d985d62de3e080deb Author: Ville Syrjälä Date: Mon Jun 26 23:30:51 2017 +0300 drm/i915: Disable MSI for all pre-gen5 commit ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae upstream. We have pretty clear evidence that MSIs are getting lost on g4x and somehow the interrupt logic doesn't seem to recover from that state even if we try hard to clear the IIR. Disabling IER around the normal IIR clearing in the irq handler isn't sufficient to avoid this, so the problem really seems to be further up the interrupt chain. This should guarantee that there's always an edge if any IIR bits are set after the interrupt handler is done, which should normally guarantee that the CPU interrupt is generated. That approach seems to work perfectly on VLV/CHV, but apparently not on g4x. MSI is documented to be broken on 965gm at least. The chipset spec says MSI is defeatured because interrupts can be delayed or lost, which fits well with what we're seeing on g4x. Previously we've already disabled GMBUS interrupts on g4x because somehow GMBUS manages to raise legacy interrupts even when MSI is enabled. Since there's such widespread MSI breakahge all over in the pre-gen5 land let's just give up on MSI on these platforms. Seqno reporting might be negatively affected by this since the legcy interrupts aren't guaranteed to be ordered with the seqno writes, whereas MSI interrupts may be? But an occasioanlly missed seqno seems like a small price to pay for generally working interrupts. Cc: Diego Viola Tested-by: Diego Viola Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter (cherry picked from commit e38c2da01f76cca82b59ca612529b81df82a7cc7) Signed-off-by: Jani Nikula [bwh: Backported to 3.16: - Open-code INTEL_GEN() - Adjust filename, context] Signed-off-by: Ben Hutchings commit 2b211fd62a2fe8917d51a01f272bddd104460981 Author: Marek Marczykowski-Górecki Date: Mon Jun 26 14:49:46 2017 +0200 x86/xen: allow userspace access during hypercalls commit c54590cac51db8ab5fd30156bdaba34af915e629 upstream. Userspace application can do a hypercall through /dev/xen/privcmd, and some for some hypercalls argument is a pointers to user-provided structure. When SMAP is supported and enabled, hypervisor can't access. So, lets allow it. The same applies to HYPERVISOR_dm_op, where additionally privcmd driver carefully verify buffer addresses. Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross [bwh: Backported to 3.16: drop change in HYPERVISOR_dm_op()] Signed-off-by: Ben Hutchings commit a1e3e81b6d25cfcd8f91462b48ad696a0106eeee Author: Sabrina Dubroca Date: Thu Jun 29 16:56:54 2017 +0200 ipv6: dad: don't remove dynamic addresses if link is down commit ec8add2a4c9df723c94a863b8fcd6d93c472deed upstream. Currently, when the link for $DEV is down, this command succeeds but the address is removed immediately by DAD (1): ip addr add 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800 In the same situation, this will succeed and not remove the address (2): ip addr add 1111::12/64 dev $DEV ip addr change 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800 The comment in addrconf_dad_begin() when !IF_READY makes it look like this is the intended behavior, but doesn't explain why: * If the device is not ready: * - keep it tentative if it is a permanent address. * - otherwise, kill it. We clearly cannot prevent userspace from doing (2), but we can make (1) work consistently with (2). addrconf_dad_stop() is only called in two cases: if DAD failed, or to skip DAD when the link is down. In that second case, the fix is to avoid deleting the address, like we already do for permanent addresses. Fixes: 3c21edbd1137 ("[IPV6]: Defer IPv6 device initialization until the link becomes ready.") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 6edc4c03363d583896d54488d9bfbac9be0426b8 Author: Lubomir Rintel Date: Fri Jan 8 13:47:23 2016 +0100 ipv6: always add flag an address that failed DAD with DADFAILED commit 3d171f3907329d4b1ce31d5ec9c852c5f0269578 upstream. The userspace needs to know why is the address being removed so that it can perhaps obtain a new address. Without the DADFAILED flag it's impossible to distinguish removal of a temporary and tentative address due to DAD failure from other reasons (device removed, manual address removal). Signed-off-by: Lubomir Rintel Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit dfa65e73857556498bc81a0f7347730e2f0325c3 Author: Helge Deller Date: Sun Jul 2 22:00:41 2017 +0200 parisc: Report SIGSEGV instead of SIGBUS when running out of stack commit 247462316f85a9e0479445c1a4223950b68ffac1 upstream. When a process runs out of stack the parisc kernel wrongly faults with SIGBUS instead of the expected SIGSEGV signal. This example shows how the kernel faults: do_page_fault() command='a.out' type=15 address=0xfaac2000 in libc-2.24.so[f8308000+16c000] trap #15: Data TLB miss fault, vm_start = 0xfa2c2000, vm_end = 0xfaac2000 The vma->vm_end value is the first address which does not belong to the vma, so adjust the check to include vma->vm_end to the range for which to send the SIGSEGV signal. This patch unbreaks building the debian libsigsegv package. Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit 9066ae99f721a161427c78d8d063a3402c8c67f3 Author: Eric Biggers Date: Mon Jun 12 23:18:30 2017 -0700 parisc: use compat_sys_keyctl() commit b0f94efd5aa8daa8a07d7601714c2573266cd4c9 upstream. Architectures with a compat syscall table must put compat_sys_keyctl() in it, not sys_keyctl(). The parisc architecture was not doing this; fix it. Signed-off-by: Eric Biggers Acked-by: Helge Deller Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit d2bc7a3e8fdb6a4022afb426a5fc5ec12fd8127d Author: Ewan D. Milne Date: Tue Jun 27 14:55:58 2017 -0400 scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state commit f9279c968c257ee39b0d7bd2571a4d231a67bcc1 upstream. The addition of the STARGET_REMOVE state had the side effect of introducing a race condition that can cause a crash. scsi_target_reap_ref_release() checks the starget->state to see if it still in STARGET_CREATED, and if so, skips calling transport_remove_device() and device_del(), because the starget->state is only set to STARGET_RUNNING after scsi_target_add() has called device_add() and transport_add_device(). However, if an rport loss occurs while a target is being scanned, it can happen that scsi_remove_target() will be called while the starget is still in the STARGET_CREATED state. In this case, the starget->state will be set to STARGET_REMOVE, and as a result, scsi_target_reap_ref_release() will take the wrong path. The end result is a panic: [ 1255.356653] Oops: 0000 [#1] SMP [ 1255.360154] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel ghash_clmulni_i [ 1255.393234] CPU: 5 PID: 149 Comm: kworker/u96:4 Tainted: G W 4.11.0+ #8 [ 1255.401879] Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013 [ 1255.410327] Workqueue: scsi_wq_6 fc_scsi_scan_rport [scsi_transport_fc] [ 1255.417720] task: ffff88060ca8c8c0 task.stack: ffffc900048a8000 [ 1255.424331] RIP: 0010:kernfs_find_ns+0x13/0xc0 [ 1255.429287] RSP: 0018:ffffc900048abbf0 EFLAGS: 00010246 [ 1255.435123] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 1255.443083] RDX: 0000000000000000 RSI: ffffffff8188d659 RDI: 0000000000000000 [ 1255.451043] RBP: ffffc900048abc10 R08: 0000000000000000 R09: 0000012433fe0025 [ 1255.459005] R10: 0000000025e5a4b5 R11: 0000000025e5a4b5 R12: ffffffff8188d659 [ 1255.466972] R13: 0000000000000000 R14: ffff8805f55e5088 R15: 0000000000000000 [ 1255.474931] FS: 0000000000000000(0000) GS:ffff880616b40000(0000) knlGS:0000000000000000 [ 1255.483959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1255.490370] CR2: 0000000000000068 CR3: 0000000001c09000 CR4: 00000000000406e0 [ 1255.498332] Call Trace: [ 1255.501058] kernfs_find_and_get_ns+0x31/0x60 [ 1255.505916] sysfs_unmerge_group+0x1d/0x60 [ 1255.510498] dpm_sysfs_remove+0x22/0x60 [ 1255.514783] device_del+0xf4/0x2e0 [ 1255.518577] ? device_remove_file+0x19/0x20 [ 1255.523241] attribute_container_class_device_del+0x1a/0x20 [ 1255.529457] transport_remove_classdev+0x4e/0x60 [ 1255.534607] ? transport_add_class_device+0x40/0x40 [ 1255.540046] attribute_container_device_trigger+0xb0/0xc0 [ 1255.546069] transport_remove_device+0x15/0x20 [ 1255.551025] scsi_target_reap_ref_release+0x25/0x40 [ 1255.556467] scsi_target_reap+0x2e/0x40 [ 1255.560744] __scsi_scan_target+0xaa/0x5b0 [ 1255.565312] scsi_scan_target+0xec/0x100 [ 1255.569689] fc_scsi_scan_rport+0xb1/0xc0 [scsi_transport_fc] [ 1255.576099] process_one_work+0x14b/0x390 [ 1255.580569] worker_thread+0x4b/0x390 [ 1255.584651] kthread+0x109/0x140 [ 1255.588251] ? rescuer_thread+0x330/0x330 [ 1255.592730] ? kthread_park+0x60/0x60 [ 1255.596815] ret_from_fork+0x29/0x40 [ 1255.600801] Code: 24 08 48 83 42 40 01 5b 41 5c 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 [ 1255.621876] RIP: kernfs_find_ns+0x13/0xc0 RSP: ffffc900048abbf0 [ 1255.628479] CR2: 0000000000000068 [ 1255.632756] ---[ end trace 34a69ba0477d036f ]--- Fix this by adding another scsi_target state STARGET_CREATED_REMOVE to distinguish this case. Fixes: f05795d3d771 ("scsi: Add intermediate STARGET_REMOVE state to scsi_target_state") Reported-by: David Jeffery Signed-off-by: Ewan D. Milne Reviewed-by: Laurence Oberman Tested-by: Laurence Oberman Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit dbe514c87fbeda1cbe6fe0325d8588e610b9dbdc Author: Maurizio Lombardi Date: Tue Jun 27 11:53:27 2017 +0200 scsi: ses: do not add a device to an enclosure if enclosure_add_links() fails. commit 62e62ffd95539b9220894a7900a619e0f3ef4756 upstream. The enclosure_add_device() function should fail if it can't create the relevant sysfs links. Signed-off-by: Maurizio Lombardi Tested-by: Douglas Miller Acked-by: James Bottomley Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit b657f2742871a071a015328ec45c26679998096c Author: Chen Yu Date: Thu May 25 16:49:07 2017 +0800 PCI/PM: Restore the status of PCI devices across hibernation commit e60514bd4485c0c7c5a7cf779b200ce0b95c70d6 upstream. Currently we saw a lot of "No irq handler" errors during hibernation, which caused the system hang finally: ata4.00: qc timeout (cmd 0xec) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata4.00: revalidation failed (errno=-5) ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) do_IRQ: 31.151 No irq handler for vector According to above logs, there is an interrupt triggered and it is dispatched to CPU31 with a vector number 151, but there is no handler for it, thus this IRQ will not get acked and will cause an IRQ flood which kills the system. To be more specific, the 31.151 is an interrupt from the AHCI host controller. After some investigation, the reason why this issue is triggered is because the thaw_noirq() function does not restore the MSI/MSI-X settings across hibernation. The scenario is illustrated below: 1. Before hibernation, IRQ 34 is the handler for the AHCI device, which is bound to CPU31. 2. Hibernation starts, the AHCI device is put into low power state. 3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to the last alive one - CPU0. 4. After the snapshot has been created, all the nonboot CPUs are brought up again; IRQ 34 remains bound to CPU0. 5. AHCI devices are put into D0. 6. The snapshot is written to the disk. The issue is triggered in step 6. The AHCI interrupt should be delivered to CPU0, however it is delivered to the original CPU31 instead, which causes the "No irq handler" issue. Ying Huang has provided a clue that, in step 3 it is possible that writing to the register might not take effect as the PCI devices have been suspended. In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but in fact it is not. In __pci_write_msi_msg(), if the device is already in low power state, the low level MSI message entry will not be updated but cached. During the device restore process after a normal suspend/resume, pci_restore_msi_state() writes the cached MSI back to the hardware. But this is not the case for hibernation. pci_restore_msi_state() is not currently called in pci_pm_thaw_noirq(), although pci_save_state() has saved the necessary PCI cached information in pci_pm_freeze_noirq(). Restore the PCI status for the device during hibernation. Otherwise the status might be lost across hibernation (for example, settings for MSI, MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation. Suggested-by: Ying Huang Suggested-by: Rafael J. Wysocki Signed-off-by: Chen Yu [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Cc: Len Brown Cc: Dan Williams Cc: Rui Zhang Cc: Ying Huang Signed-off-by: Ben Hutchings commit 612ac6db99be30beeb1bbde041ed6c349031282f Author: Ganapathi Bhat Date: Wed Jun 28 12:26:58 2017 +0530 mwifiex: do not update MCS set from hostapd commit 8a063a27815a759b99ad710402da1ccd1b0987f7 upstream. We should not copy the MCS set from hostapd RX-STBC. We have to just use the MCS set supported by the hardware. This fixes an issue, where mwifiex is advertising wrong MCS sets in beacons. Fixes: 474a41e94dfc ("mwifiex: update MCS set as per RX-STBC bit from hostapd") Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo [bwh: Backported to 3.16: - Deleted code is slightly different - Adjust filename] Signed-off-by: Ben Hutchings commit bb22c0b4cdd5a87fb79adcf53fd58900c277d99a Author: Jan Kara Date: Thu Jun 22 15:31:07 2017 +0200 btrfs: Don't clear SGID when inheriting ACLs commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __btrfs_set_acl() into btrfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: linux-btrfs@vger.kernel.org CC: David Sterba Signed-off-by: Jan Kara Signed-off-by: David Sterba [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 068449587ce3f23f38e1349cf3b46714b88c3902 Author: Dave Martin Date: Thu Jun 29 15:25:47 2017 +0100 arm64: ptrace: Avoid setting compat FP[SC]R to garbage if get_user fails commit 53b1a742ed251780267a57415bc955bd50f40c3d upstream. If get_user() fails when reading the new FPSCR value from userspace in compat_vfp_get(), then garbage* will be written to the task's FPSR and FPCR registers. This patch prevents this by checking the return from get_user() first. [*] Actually, zero, due to the behaviour of get_user() on error, but that's still not what userspace expects. Fixes: 478fcb2cdb23 ("arm64: Debugging support") Signed-off-by: Dave Martin Signed-off-by: Will Deacon Signed-off-by: Ben Hutchings commit 1c0c993391dc3741a0f1cfce5d645267bfe7b3ed Author: Devin Heitmueller Date: Tue Jun 27 13:08:51 2017 -0400 Add USB quirk for HVR-950q to avoid intermittent device resets commit 6836796de4019944f4ba4c99a360e8250fd2e735 upstream. The USB core and sysfs will attempt to enumerate certain parameters which are unsupported by the au0828 - causing inconsistent behavior and sometimes causing the chip to reset. Avoid making these calls. This problem manifested as intermittent cases where the au8522 would be reset on analog video startup, in particular when starting up ALSA audio streaming in parallel - the sysfs entries created by snd-usb-audio on streaming startup would result in unsupported control messages being sent during tuning which would put the chip into an unknown state. Signed-off-by: Devin Heitmueller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b378d62f9041a3ce67b185fc30774c2e7ef3d727 Author: Maciej W. Rozycki Date: Fri Jun 16 00:08:29 2017 +0100 MIPS: Send SIGILL for BPOSGE32 in `__compute_return_epc_for_insn' commit 7b82c1058ac1f8f8b9f2b8786b1f710a57a870a8 upstream. Fix commit e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") and send SIGILL rather than SIGBUS whenever an unimplemented BPOSGE32 DSP ASE instruction has been encountered in `__compute_return_epc_for_insn' as our Reserved Instruction exception handler would in response to an attempt to actually execute the instruction. Sending SIGBUS only makes sense for the unaligned PC case, since moved to `__compute_return_epc'. Adjust function documentation accordingly, correct formatting and use `pr_info' rather than `printk' as the other exit path already does. Fixes: e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16396/ Signed-off-by: Ralf Baechle [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 9840bcc871b6dd1c86eedc3a9ad876c8e8a00f2c Author: Maciej W. Rozycki Date: Fri Jun 16 00:07:34 2017 +0100 MIPS: Fix unaligned PC interpretation in `compute_return_epc' commit 11a3799dbeb620bf0400b1fda5cc2c6bea55f20a upstream. Fix a regression introduced with commit fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.") and defer to `__compute_return_epc' if the ISA bit is set in EPC with non-MIPS16, non-microMIPS hardware, which will then arrange for a SIGBUS due to an unaligned instruction reference. Returning EPC here is never correct as the API defines this function's result to be either a negative error code on failure or one of 0 and BRANCH_LIKELY_TAKEN on success. Fixes: fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.") Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16395/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 3897c8807f6992c91cc714ab692d9bbf4a14b272 Author: Maciej W. Rozycki Date: Fri Jun 16 00:06:19 2017 +0100 MIPS: Actually decode JALX in `__compute_return_epc_for_insn' commit a9db101b735a9d49295326ae41f610f6da62b08c upstream. Complement commit fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.") and actually decode the regular MIPS JALX major instruction opcode, the handling of which has been added with the said commit for EPC calculation in `__compute_return_epc_for_insn'. Fixes: fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.") Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16394/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 2302fe858f2c11c42a94cd37b7f523e7fe58752d Author: Maciej W. Rozycki Date: Fri Jun 16 00:05:08 2017 +0100 MIPS: math-emu: Prevent wrong ISA mode instruction emulation commit 13769ebad0c42738831787e27c7c7f982e7da579 upstream. Terminate FPU emulation immediately whenever an ISA mode switch has been observed. This is so that we do not interpret machine code in the wrong mode, for example when a regular MIPS FPU instruction has been placed in a delay slot of a jump that switches into the MIPS16 mode, as with the following code (taken from a GCC test suite case): 00400650 : 400650: 3c020100 lui v0,0x100 400654: 03e00008 jr ra 400658: 44c2f800 ctc1 v0,c1_fcsr 40065c: 00000000 nop [...] 004012d0 <__libc_csu_init>: 4012d0: f000 6a02 li v0,2 4012d4: f150 0b1c la v1,3f9430 <_DYNAMIC-0x6df0> 4012d8: f400 3240 sll v0,16 4012dc: e269 addu v0,v1 4012de: 659a move gp,v0 4012e0: f00c 64f6 save a0-a2,48,ra,s0-s1 4012e4: 673c move s1,gp 4012e6: f010 9978 lw v1,-32744(s1) 4012ea: d204 sw v0,16(sp) 4012ec: eb40 jalr v1 4012ee: 653b move t9,v1 4012f0: f010 997c lw v1,-32740(s1) 4012f4: f030 9920 lw s1,-32736(s1) 4012f8: e32f subu v1,s1 4012fa: 326b sra v0,v1,2 4012fc: d206 sw v0,24(sp) 4012fe: 220c beqz v0,401318 <__libc_csu_init+0x48> 401300: 6800 li s0,0 401302: 99e0 lw a3,0(s1) 401304: 4801 addiu s0,1 401306: 960e lw a2,56(sp) 401308: 4904 addiu s1,4 40130a: 950d lw a1,52(sp) 40130c: 940c lw a0,48(sp) 40130e: ef40 jalr a3 401310: 653f move t9,a3 401312: 9206 lw v0,24(sp) 401314: ea0a cmp v0,s0 401316: 61f5 btnez 401302 <__libc_csu_init+0x32> 401318: 6476 restore 48,ra,s0-s1 40131a: e8a0 jrc ra Here `set_fast_math' is called from `40130e' (`40130f' with the ISA bit) and emulation triggers for the CTC1 instruction. As it is in a jump delay slot emulation continues from `401312' (`401313' with the ISA bit). However we have no path to handle MIPS16 FPU code emulation, because there are no MIPS16 FPU instructions. So the default emulation path is taken, interpreting a 32-bit word fetched by `get_user' from `401313' as a regular MIPS instruction, which is: 401313: f5ea0a92 sdc1 $f10,2706(t7) This makes the FPU emulator proceed with the supposed SDC1 instruction and consequently makes the program considered here terminate with SIGSEGV. A similar although less severe issue exists with pure-microMIPS processors in the case where similarly an FPU instruction is emulated in a delay slot of a register jump that (incorrectly) switches into the regular MIPS mode. A subsequent instruction fetch from the jump's target is supposed to cause an Address Error exception, however instead we proceed with regular MIPS FPU emulation. For simplicity then, always terminate the emulation loop whenever a mode change is detected, denoted by an ISA mode bit flip. As from commit 377cb1b6c16a ("MIPS: Disable MIPS16/microMIPS crap for platforms not supporting these ASEs.") the result of `get_isa16_mode' can be hardcoded to 0, so we need to examine the ISA mode bit by hand. This complements commit 102cedc32a6e ("MIPS: microMIPS: Floating point support.") which added JALX decoding to FPU emulation. Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.") Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16393/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 98000aa66b5efbd3fbef77e0715390182b8c7cc0 Author: Krzysztof Kozlowski Date: Wed Jun 28 16:56:18 2017 +0200 PM / Domains: Fix unsafe iteration over modified list of device links commit c6e83cac3eda5f7dd32ee1453df2f7abb5c6cd46 upstream. pm_genpd_remove_subdomain() iterates over domain's master_links list and removes matching element thus it has to use safe version of list iteration. Fixes: f721889ff65a ("PM / Domains: Support for generic I/O PM domains (v8)") Signed-off-by: Krzysztof Kozlowski Acked-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 19e23fcc5cc6d96b745093038429d5215f5fb86c Author: Bjorn Helgaas Date: Fri Aug 19 16:30:25 2016 +0800 PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11 commit 13cfc732160f7bc7e596128ce34cda361c556966 upstream. Neither soft poweroff (transition to ACPI power state S5) nor suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and 11,5. The problem is related to the [mem 0x7fa00000-0x7fbfffff] space. When we use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work anymore. Linux does a soft poweroff (transition to S5) by writing to PM1_CNT. The theory about why this doesn't work is: - The write to PM1_CNT causes an SMI - The BIOS SMI handler depends on something in [mem 0x7fa00000-0x7fbfffff] - When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it covers up whatever the SMI handler uses, so the SMI handler no longer works correctly Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don't assign it to anything. This is voodoo programming, since we don't know what the real conflict is, but we've failed to find the root cause. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Tested-by: thejoe@gmail.com Signed-off-by: Bjorn Helgaas Cc: Rafael J. Wysocki Cc: Lukas Wunner Cc: Chen Yu Signed-off-by: Ben Hutchings commit eece8b3a36ebcb2a683898a18b3ce4cd29867994 Author: Bjorn Helgaas Date: Thu Sep 1 08:52:29 2016 -0500 PCI: Mark Haswell Power Control Unit as having non-compliant BARs commit 6af7e4f77259ee946103387372cb159f2e99a6d4 upstream. The Haswell Power Control Unit has a non-PCI register (CONFIG_TDP_NOMINAL) where BAR 0 is supposed to be. This is erratum HSE43 in the spec update referenced below: The PCIe* Base Specification indicates that Configuration Space Headers have a base address register at offset 0x10. Due to this erratum, the Power Control Unit's CONFIG_TDP_NOMINAL CSR (Bus 1; Device 30; Function 3; Offset 0x10) is located where a base register is expected. Mark the PCU as having non-compliant BARs so we don't try to probe any of them. There are no other BARs on this device. Rename the quirk so it's not Broadwell-specific. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v3-spec-update.html Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v3-datasheet-vol-2.html (section 5.4, Device 30 Function 3) Link: https://bugzilla.kernel.org/show_bug.cgi?id=153881 Reported-by: Paul Menzel Tested-by: Prarit Bhargava Signed-off-by: Bjorn Helgaas Acked-by: Myron Stowe Signed-off-by: Ben Hutchings commit 50f4bed39bf0d83396db41f9250410468e51534a Author: Alex Williamson Date: Wed Jun 28 13:50:05 2017 -0600 vfio: New external user group/file match commit 5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d upstream. At the point where the kvm-vfio pseudo device wants to release its vfio group reference, we can't always acquire a new reference to make that happen. The group can be in a state where we wouldn't allow a new reference to be added. This new helper function allows a caller to match a file to a group to facilitate this. Given a file and group, report if they match. Thus the caller needs to already have a group reference to match to the file. This allows the deletion of a group without acquiring a new reference. Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Reviewed-by: Paolo Bonzini Tested-by: Eric Auger Signed-off-by: Ben Hutchings commit 61968c5c782a816889bdbebace8469867a149dc3 Author: Alex Williamson Date: Mon Jun 19 09:10:32 2017 -0600 vfio: Fix group release deadlock commit 811642d8d8a82c0cce8dc2debfdaf23c5a144839 upstream. If vfio_iommu_group_notifier() acquires a group reference and that reference becomes the last reference to the group, then vfio_group_put introduces a deadlock code path where we're trying to unregister from the iommu notifier chain from within a callout of that chain. Use a work_struct to release this reference asynchronously. Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Ben Hutchings commit eb1472fe74a9aa9f9de48212976839b473739e95 Author: Dan Carpenter Date: Fri Jun 23 18:17:38 2017 +0300 libertas: Fix lbs_prb_rsp_limit_set() commit 69551f5f370cc20342fab17ca54716b6ec7e332d upstream. The kstrtoul() test was reversed so this always returned -ENOTSUPP. Fixes: 27d7f47756f4 ("net: wireless: replace strict_strtoul() with kstrtoul()") Signed-off-by: Dan Carpenter Reviewed-by: James Cameron Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit a31c633387c9a2adb11fd3e2e2bcf43ef3759067 Author: Jeremie Rapin Date: Wed Jun 28 18:23:25 2017 +0200 USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick commit fd90f73a9925f248d696bde1cfc836d9fda5570d upstream. Added the USB serial device ID for the CEL ZigBee EM3588 radio stick. Signed-off-by: Jeremie Rapin Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e1ccbfb6f415bdc02128e81c43513ab43915adc9 Author: Miaoqing Pan Date: Tue Jun 27 17:31:51 2017 +0300 ath9k: fix tx99 bus error commit bde717ab473668377fc65872398a102d40cb2d58 upstream. The hard coded register 0x9864 and 0x9924 are invalid for ar9300 chips. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit 3757358b308fb0a8a16f0646cc4c64deb1229063 Author: Miaoqing Pan Date: Tue Jun 27 17:31:49 2017 +0300 ath9k: fix tx99 use after free commit cf8ce1ea61b75712a154c93e40f2a5af2e4dd997 upstream. One scenario that could lead to UAF is two threads writing simultaneously to the "tx99" debug file. One of them would set the "start" value to true and follow to ath9k_tx99_init(). Inside the function it would set the sc->tx99_state to true after allocating sc->tx99skb. Then, the other thread would execute write_file_tx99() and call ath9k_tx99_deinit(). sc->tx99_state would be freed. After that, the first thread would continue inside ath9k_tx99_init() and call r = ath9k_tx99_send(sc, sc->tx99_skb, &txctl); that would make use of the freed sc->tx99_skb memory. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit 0210302574d9ec879a3b7b18365f8fd872ec9636 Author: James Hogan Date: Wed May 31 16:19:49 2017 +0100 MIPS: Fix mips_atomic_set() with EVA commit 4915e1b043d6286928207b1f6968197b50407294 upstream. EVA linked loads (LLE) and conditional stores (SCE) should be used on EVA kernels for the MIPS_ATOMIC_SET operation of the sysmips system call, or else the atomic set will apply to the kernel view of the virtual address space (potentially unmapped on EVA kernels) rather than the user view (TLB mapped). Signed-off-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16151/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit d4a279c79daf827b751e532935594227bfd9181d Author: James Hogan Date: Wed May 31 16:19:48 2017 +0100 MIPS: Save static registers before sysmips commit 49955d84cd9ccdca5a16a495e448e1a06fad9e49 upstream. The MIPS sysmips system call handler may return directly from the MIPS_ATOMIC_SET case (mips_atomic_set()) to syscall_exit. This path restores the static (callee saved) registers, however they won't have been saved on entry to the system call. Use the save_static_function() macro to create a __sys_sysmips wrapper function which saves the static registers before calling sys_sysmips, so that the correct static register state is restored by syscall_exit. Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler") Signed-off-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16149/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit b68d69166064d56ea661b22a917408ad57444375 Author: James Hogan Date: Wed May 31 16:19:47 2017 +0100 MIPS: Fix mips_atomic_set() retry condition commit 2ec420b26f7b6ff332393f0bb5a7d245f7ad87f0 upstream. The inline asm retry check in the MIPS_ATOMIC_SET operation of the sysmips system call has been backwards since commit f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler") merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying until the operation was inatomic, before returning the new value that was probably just written multiple times instead of the old value. Invert the branch condition to fix that particular issue. Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler") Signed-off-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16148/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit a7947e5ce90a59b948e61cc67e010dbb87d99983 Author: Paul Burton Date: Thu Mar 30 11:37:44 2017 -0700 MIPS: module: Ensure we always clean up r_mips_hi16_list commit 351b0940d473146923711bc943fc881354a4c1f3 upstream. If we hit an error whilst processing a reloc then we would return early from apply_relocate & potentially not free entries in r_mips_hi16_list, thereby leaking memory. Fix this by ensuring that we always run the code to free r_mipps_hi16_list when errors occur. Signed-off-by: Paul Burton Fixes: 861667dc82f5 ("MIPS: Fix race condition in module relocation code.") Fixes: 04211a574641 ("MIPS: Bail on unsupported module relocs") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15831/ Signed-off-by: Ralf Baechle [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 123a250fd59a2cf1d5ea56ae2399745df696276c Author: Paul Burton Date: Thu Feb 4 13:05:02 2016 +0000 MIPS: Bail on unsupported module relocs commit 04211a574641e29b529dcc84e75c03d7e9e368cf upstream. When an unsupported reloc is encountered in a module, we currently blindly branch to whatever would be at its entry in the reloc handler function pointer arrays. This may be NULL, or if the unsupported reloc has a type greater than that of the supported reloc with the highest type then we'll dereference some value after the function pointer array & branch to that. The result is at best a kernel oops. Fix this by checking that the reloc type has an entry in the function pointer array (ie. is less than the number of items in the array) and that the handler is non-NULL, returning an error code to fail the module load if no handler is found. Signed-off-by: Paul Burton Cc: James Hogan Cc: Steven J. Hill Cc: Andrey Ryabinin Cc: Andrew Morton Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12432/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 8014e2c2bab92b1be8c8172f644986e0bb7d6c83 Author: Johan Hovold Date: Wed Jun 21 11:35:09 2017 +0200 scsi: sun_esp: fix device reference leaks commit f62f9ffdb5ef683ef8cffb43932fa72cc3713e94 upstream. Make sure to drop the reference to the dma device taken by of_find_device_by_node() on probe errors and on driver unbind. Fixes: 334ae614772b ("sparc: Kill SBUS DVMA layer.") Signed-off-by: Johan Hovold Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 1653d793b621418b0796d6c6f4ef15a0b839c975 Author: Jan Kara Date: Mon Jun 26 08:48:18 2017 -0700 xfs: Don't clear SGID when inheriting ACLs commit 8ba358756aa08414fa9e65a1a41d28304ed6fd7f upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when setting up inode in xfs_generic_create(). That prevents SGID bit clearing and mode is properly set by posix_acl_create() anyway. We also reorder arguments of __xfs_set_acl() to match the ordering of xfs_set_acl() to make things consistent. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: Darrick J. Wong CC: linux-xfs@vger.kernel.org Signed-off-by: Jan Kara Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 415b8b3695357f8f672c30b01911ce578ad92913 Author: Dan Carpenter Date: Fri Jun 23 10:02:00 2017 +0300 scsi: bnx2i: missing error code in bnx2i_ep_connect() commit 1d32a62c74b3bcb69822b0f4745af5410cfec3a7 upstream. If bnx2i_map_ep_dbell_regs() then we accidentally return NULL instead of an error pointer. It results in a NULL dereference in iscsi_if_ep_connect(). Fixes: cf4e6363859d ("[SCSI] bnx2i: Add bnx2i iSCSI driver.") Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit ca78cc0370b35e487b8e7884e9032f4c0a0060c8 Author: Paolo Bonzini Date: Wed Jun 21 16:35:46 2017 +0200 scsi: virtio_scsi: let host do exception handling commit e72c9a2a67a6400c8ef3d01d4c461dbbbfa0e1f0 upstream. virtio_scsi tries to do exception handling after the default 30 seconds timeout expires. However, it's better to let the host control the timeout, otherwise with a heavy I/O load it is likely that an abort will also timeout. This leads to fatal errors like filesystems going offline. Disable the 'sd' timeout and allow the host to do exception handling, following the precedent of the storvsc driver. Hannes has a proposal to introduce timeouts in virtio, but this provides an immediate solution for stable kernels too. [mkp: fixed typo] Reported-by: Douglas Miller Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: Hannes Reinecke Cc: linux-scsi@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Martin K. Petersen [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit f0de8681a1f0aa2b27ff373116b0cb72c3ea41a7 Author: Mateusz Jurczyk Date: Fri Jun 23 19:32:28 2017 +0200 af_iucv: Move sockaddr length checks to before accessing sa_family in bind and connect handlers commit e3c42b61ff813921ba58cfc0019e3fd63f651190 upstream. Verify that the caller-provided sockaddr structure is large enough to contain the sa_family field, before accessing it in bind() and connect() handlers of the AF_IUCV socket. Since neither syscall enforces a minimum size of the corresponding memory region, very short sockaddrs (zero or one byte long) result in operating on uninitialized memory while referencing .sa_family. Fixes: 52a82e23b9f2 ("af_iucv: Validate socket address length in iucv_sock_bind()") Signed-off-by: Mateusz Jurczyk [jwi: removed unneeded null-check for addr] Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ab5f31d14d3db0c74d2bd793c90f1feb80fcae88 Author: Matt Weber Date: Thu Jun 22 15:00:33 2017 -0500 i2c: cadance: fix ctrl/addr reg write order commit 8064c616984eaa015f018dba595d78cd24a0cc8c upstream. The driver was clearing the hold bit in the control register before writing to the address register which resulted in a stop condition being generated rather than a repeated start. This issue was only observed when a system was running much slower than a normal processor would execute. The IP data sheet mentions a ordering of writing to the address register before clearing the hold. Fixes: df8eb5691c4 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: John Linn Signed-off-by: Paresh Chaudhary Signed-off-by: Matthew Weber Signed-off-by: Wolfram Sang [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 3baeb4378c862505f4efa22b56e6e464efb40ab7 Author: Ian Abbott Date: Fri Jun 16 19:35:34 2017 +0100 staging: comedi: fix clean-up of comedi_class in comedi_init() commit a9332e9ad09c2644c99058fcf6ae2f355e93ce74 upstream. There is a clean-up bug in the core comedi module initialization functions, `comedi_init()`. If the `comedi_num_legacy_minors` module parameter is non-zero (and valid), it creates that many "legacy" devices and registers them in SysFS. A failure causes the function to clean up and return an error. Unfortunately, it fails to destroy the "comedi" class that was created earlier. Fix it by adding a call to `class_destroy(comedi_class)` at the appropriate place in the clean-up sequence. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e2cfe87316fb114938a1b4206f0c9ec055a9065a Author: Cyrille Pitchen Date: Fri Jun 23 17:39:16 2017 +0200 spi: atmel: fix corrupted data issue on SAM9 family SoCs commit 7094576ccdc3acfe1e06a1e2ab547add375baf7f upstream. This patch disables the use of the DMA for data transfer and forces the use of PIO transfers instead as a quick fixup to solve the cache aliasing issue on ARM9 based cores, which embeds a VIVT data cache. Indeed in the case of VIVT data caches, it is not safe to call dma_map_*() functions to map buffers for DMA transfers when those buffers have been allocated by vmalloc() or from any DMA-unsafe area. Further patches may propose a better solution based on the use of a bounce buffer at the SPI sub-system level but such solution needs more time to be discussed. Then the use of DMA transfers could be enabled again to improve the performances but before that, this patch already solves the issue. Signed-off-by: Cyrille Pitchen Acked-by: Nicolas Ferre Signed-off-by: Mark Brown [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit cc02f1c5187e71f3b2f6a8653025f626b57eafc3 Author: Emmanuel Grumbach Date: Fri May 5 08:51:24 2017 +0300 iwlwifi: mvm: fix the recovery flow while connecting commit 6b28f9784c394f0692e160f81b07c82cb64af160 upstream. In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn't remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 27df06afa10b00ed7629b98e03ed2e620cde1772 Author: Filipe Manana Date: Tue May 30 05:29:09 2017 +0100 Btrfs: fix invalid extent maps due to hole punching commit 609805d809733d0c669f21f710bdac308cc63cba upstream. While punching a hole in a range that is not aligned with the sector size (currently the same as the page size) we can end up leaving an extent map in memory with a length that is smaller then the sector size or with a start offset that is not aligned to the sector size. Both cases are not expected and can lead to problems. This issue is easily detected after the patch from commit a7e3b975a0f9 ("Btrfs: fix reported number of inode blocks"), introduced in kernel 4.12-rc1, in a scenario like the following for example: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -c "pwrite -S 0xaa -b 100K 0 100K" /mnt/foo $ xfs_io -c "fpunch 60K 90K" /mnt/foo $ xfs_io -c "pwrite -S 0xbb -b 100K 50K 100K" /mnt/foo $ xfs_io -c "pwrite -S 0xcc -b 50K 100K 50K" /mnt/foo $ umount /mnt After the unmount operation we can see several warnings emmitted due to underflows related to space reservation counters: [ 2837.443299] ------------[ cut here ]------------ [ 2837.447395] WARNING: CPU: 8 PID: 2474 at fs/btrfs/inode.c:9444 btrfs_destroy_inode+0xe8/0x27e [btrfs] [ 2837.452108] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button se rio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_gene ric raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.458389] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.459754] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.462379] Call Trace: [ 2837.462379] dump_stack+0x68/0x92 [ 2837.462379] __warn+0xc2/0xdd [ 2837.462379] warn_slowpath_null+0x1d/0x1f [ 2837.462379] btrfs_destroy_inode+0xe8/0x27e [btrfs] [ 2837.462379] destroy_inode+0x3d/0x55 [ 2837.462379] evict+0x177/0x17e [ 2837.462379] dispose_list+0x50/0x71 [ 2837.462379] evict_inodes+0x132/0x141 [ 2837.462379] generic_shutdown_super+0x3f/0xeb [ 2837.462379] kill_anon_super+0x12/0x1c [ 2837.462379] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.462379] deactivate_locked_super+0x30/0x68 [ 2837.462379] deactivate_super+0x36/0x39 [ 2837.462379] cleanup_mnt+0x58/0x76 [ 2837.462379] __cleanup_mnt+0x12/0x14 [ 2837.462379] task_work_run+0x77/0x9b [ 2837.462379] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.462379] syscall_return_slowpath+0x196/0x1b9 [ 2837.462379] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.462379] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.462379] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.462379] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.462379] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.462379] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.462379] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.462379] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.519355] ---[ end trace e79345fe24b30b8d ]--- [ 2837.596256] ------------[ cut here ]------------ [ 2837.597625] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:5699 btrfs_free_block_groups+0x246/0x3eb [btrfs] [ 2837.603547] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.659372] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.663359] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.663359] Call Trace: [ 2837.663359] dump_stack+0x68/0x92 [ 2837.663359] __warn+0xc2/0xdd [ 2837.663359] warn_slowpath_null+0x1d/0x1f [ 2837.663359] btrfs_free_block_groups+0x246/0x3eb [btrfs] [ 2837.663359] close_ctree+0x1dd/0x2e1 [btrfs] [ 2837.663359] ? evict_inodes+0x132/0x141 [ 2837.663359] btrfs_put_super+0x15/0x17 [btrfs] [ 2837.663359] generic_shutdown_super+0x6a/0xeb [ 2837.663359] kill_anon_super+0x12/0x1c [ 2837.663359] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.663359] deactivate_locked_super+0x30/0x68 [ 2837.663359] deactivate_super+0x36/0x39 [ 2837.663359] cleanup_mnt+0x58/0x76 [ 2837.663359] __cleanup_mnt+0x12/0x14 [ 2837.663359] task_work_run+0x77/0x9b [ 2837.663359] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.663359] syscall_return_slowpath+0x196/0x1b9 [ 2837.663359] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.663359] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.663359] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.663359] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.663359] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.663359] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.663359] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.663359] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.739445] ---[ end trace e79345fe24b30b8e ]--- [ 2837.745595] ------------[ cut here ]------------ [ 2837.746412] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:5700 btrfs_free_block_groups+0x261/0x3eb [btrfs] [ 2837.747955] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.755395] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.756769] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.758526] Call Trace: [ 2837.758925] dump_stack+0x68/0x92 [ 2837.759383] __warn+0xc2/0xdd [ 2837.759383] warn_slowpath_null+0x1d/0x1f [ 2837.759383] btrfs_free_block_groups+0x261/0x3eb [btrfs] [ 2837.759383] close_ctree+0x1dd/0x2e1 [btrfs] [ 2837.759383] ? evict_inodes+0x132/0x141 [ 2837.759383] btrfs_put_super+0x15/0x17 [btrfs] [ 2837.759383] generic_shutdown_super+0x6a/0xeb [ 2837.759383] kill_anon_super+0x12/0x1c [ 2837.759383] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.759383] deactivate_locked_super+0x30/0x68 [ 2837.759383] deactivate_super+0x36/0x39 [ 2837.759383] cleanup_mnt+0x58/0x76 [ 2837.759383] __cleanup_mnt+0x12/0x14 [ 2837.759383] task_work_run+0x77/0x9b [ 2837.759383] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.759383] syscall_return_slowpath+0x196/0x1b9 [ 2837.759383] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.759383] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.759383] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.759383] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.759383] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.759383] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.759383] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.759383] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.777063] ---[ end trace e79345fe24b30b8f ]--- [ 2837.778235] ------------[ cut here ]------------ [ 2837.778856] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:9825 btrfs_free_block_groups+0x348/0x3eb [btrfs] [ 2837.791385] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.797711] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.798594] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.800118] Call Trace: [ 2837.800515] dump_stack+0x68/0x92 [ 2837.801015] __warn+0xc2/0xdd [ 2837.801471] warn_slowpath_null+0x1d/0x1f [ 2837.801698] btrfs_free_block_groups+0x348/0x3eb [btrfs] [ 2837.801698] close_ctree+0x1dd/0x2e1 [btrfs] [ 2837.801698] ? evict_inodes+0x132/0x141 [ 2837.801698] btrfs_put_super+0x15/0x17 [btrfs] [ 2837.801698] generic_shutdown_super+0x6a/0xeb [ 2837.801698] kill_anon_super+0x12/0x1c [ 2837.801698] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.801698] deactivate_locked_super+0x30/0x68 [ 2837.801698] deactivate_super+0x36/0x39 [ 2837.801698] cleanup_mnt+0x58/0x76 [ 2837.801698] __cleanup_mnt+0x12/0x14 [ 2837.801698] task_work_run+0x77/0x9b [ 2837.801698] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.801698] syscall_return_slowpath+0x196/0x1b9 [ 2837.801698] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.801698] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.801698] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.801698] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.801698] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.801698] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.801698] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.801698] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.818441] ---[ end trace e79345fe24b30b90 ]--- [ 2837.818991] BTRFS info (device sdc): space_info 1 has 7974912 free, is not full [ 2837.819830] BTRFS info (device sdc): space_info total=8388608, used=417792, pinned=0, reserved=0, may_use=18446744073709547520, readonly=0 What happens in the above example is the following: 1) When punching the hole, at btrfs_punch_hole(), the variable tail_len is set to 2048 (as tail_start is 148Kb + 1 and offset + len is 150Kb). This results in the creation of an extent map with a length of 2Kb starting at file offset 148Kb, through find_first_non_hole() -> btrfs_get_extent(). 2) The second write (first write after the hole punch operation), sets the range [50Kb, 152Kb[ to delalloc. 3) The third write, at btrfs_find_new_delalloc_bytes(), sees the extent map covering the range [148Kb, 150Kb[ and ends up calling set_extent_bit() for the same range, which results in splitting an existing extent state record, covering the range [148Kb, 152Kb[ into two 2Kb extent state records, covering the ranges [148Kb, 150Kb[ and [150Kb, 152Kb[. 4) Finally at lock_and_cleanup_extent_if_need(), immediately after calling btrfs_find_new_delalloc_bytes() we clear the delalloc bit from the range [100Kb, 152Kb[ which results in the btrfs_clear_bit_hook() callback being invoked against the two 2Kb extent state records that cover the ranges [148Kb, 150Kb[ and [150Kb, 152Kb[. When called against the first 2Kb extent state, it calls btrfs_delalloc_release_metadata() with a length argument of 2048 bytes. That function rounds up the length to a sector size aligned length, so it ends up considering a length of 4096 bytes, and then calls calc_csum_metadata_size() which results in decrementing the inode's csum_bytes counter by 4096 bytes, so after it stays a value of 0 bytes. Then the same happens when btrfs_clear_bit_hook() is called against the second extent state that has a length of 2Kb, covering the range [150Kb, 152Kb[, the length is rounded up to 4096 and calc_csum_metadata_size() ends up being called to decrement 4096 bytes from the inode's csum_bytes counter, which at that time has a value of 0, leading to an underflow, which is exactly what triggers the first warning, at btrfs_destroy_inode(). All the other warnings relate to several space accounting counters that underflow as well due to similar reasons. A similar case but where the hole punching operation creates an extent map with a start offset not aligned to the sector size is the following: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -f -c "fpunch 695K 820K" $SCRATCH_MNT/bar $ xfs_io -c "pwrite -S 0xaa 1008K 307K" $SCRATCH_MNT/bar $ xfs_io -c "pwrite -S 0xbb -b 630K 1073K 630K" $SCRATCH_MNT/bar $ xfs_io -c "pwrite -S 0xcc -b 459K 1068K 459K" $SCRATCH_MNT/bar $ umount /mnt During the unmount operation we get similar traces for the same reasons as in the first example. So fix the hole punching operation to make sure it never creates extent maps with a length that is not aligned to the sector size nor with a start offset that is not aligned to the sector size, as this breaks all assumptions and it's a land mine. Fixes: d77815461f04 ("btrfs: Avoid trucating page or punching hole in a already existed hole.") Signed-off-by: Filipe Manana Reviewed-by: Liu Bo Signed-off-by: David Sterba [bwh: Backported to 3.16: - sectorsize is a member of btrfs_root not btrfs_fs_info - Adjust context] Signed-off-by: Ben Hutchings commit f958dc1f6078d21a9ef408b6cd483eeaa888ce61 Author: Dan Carpenter Date: Mon Jun 19 13:53:04 2017 +0300 x86/nmi: Fix timeout test in test_nmi_ipi() commit c133c7615751008f6c32ccae7cdfc5ff6e989c35 upstream. We're supposed to exit the loop with "timeout" set to zero. Signed-off-by: Dan Carpenter Acked-by: Don Zickus Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: kernel-janitors@vger.kernel.org Fixes: 99e8b9ca90d6 ("x86, NMI: Add NMI IPI selftest") Link: http://lkml.kernel.org/r/20170619105304.GA23995@elgon.mountain Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit d4c75eaeb9150ad03cdcbb40e7c7fefd89600ee9 Author: Jiahau Chang Date: Mon Jun 19 13:08:30 2017 +0300 xhci: Limit USB2 port wake support for AMD Promontory hosts commit dec08194ffeccfa1cf085906b53d301930eae18f upstream. For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. This will disable wake on connect, disconnect and overcurrent on AMD Promontory USB2 ports [checkpatch cleanup and commit message reword -Mathias] Cc: Tsai Nicholas Signed-off-by: Jiahau Chang Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit db5e30d4fd57a1d540af1fab92939f140c0325e0 Author: Liu Bo Date: Fri May 19 11:39:15 2017 -0600 Btrfs: skip commit transaction if we don't have enough pinned bytes commit 28785f70ef882e4798cd5706066a55dbf7adf80e upstream. We commit transaction in order to reclaim space from pinned bytes because it could process delayed refs, and in may_commit_transaction(), we check first if pinned bytes are enough for the required space, we then check if that plus bytes reserved for delayed insert are enough for the required space. This changes the code to the above logic. Fixes: b150a4f10d87 ("Btrfs: use a percpu to keep track of possibly pinned bytes") Tested-by: Nikolay Borisov Reported-by: Nikolay Borisov Reviewed-by: Nikolay Borisov Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Ben Hutchings commit 02e7a3c4ea94a478da0f976ec636b5edaa2d8f43 Author: Satish Babu Patakokila Date: Fri Jun 16 17:33:40 2017 -0700 ASoC: compress: Derive substream from stream based on direction commit 01b8cedfd0422326caae308641dcadaa85e0ca72 upstream. Currently compress driver hardcodes direction as playback to get substream from the stream. This results in getting the incorrect substream for compressed capture usecase. To fix this, remove the hardcoding and derive substream based on the stream direction. Signed-off-by: Satish Babu Patakokila Signed-off-by: Banajit Goswami Acked-By: Vinod Koul Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 0bf2fa668fa11cd486649fb366e07f009fbe6eb2 Author: Martin Hicks Date: Tue May 2 09:38:35 2017 -0400 crypto: talitos - Extend max key length for SHA384/512-HMAC and AEAD commit 03d2c5114c95797c0aa7d9f463348b171a274fd4 upstream. An updated patch that also handles the additional key length requirements for the AEAD algorithms. The max keysize is not 96. For SHA384/512 it's 128, and for the AEAD algorithms it's longer still. Extend the max keysize for the AEAD size for AES256 + HMAC(SHA512). Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to existing AEAD algorithms") Signed-off-by: Martin Hicks Acked-by: Horia Geantă Signed-off-by: Herbert Xu [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 38af0e73a85a9b3ffa11bbc5dc53e9f6a7c6036a Author: Johan Hovold Date: Thu Mar 30 12:15:35 2017 +0200 NFC: fix broken device allocation commit 20777bc57c346b6994f465e0d8261a7fbf213a09 upstream. Commit 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs") moved device-id allocation and struct-device initialisation from nfc_allocate_device() to nfc_register_device(). This broke just about every nfc-device-registration error path, which continue to call nfc_free_device() that tries to put the device reference of the now uninitialised (but zeroed) struct device: kobject: '(null)' (ce316420): is not initialized, yet kobject_put() is being called. The late struct-device initialisation also meant that various work queues whose names are derived from the nfc device name were also misnamed: 421 root 0 SW< [(null)_nci_cmd_] 422 root 0 SW< [(null)_nci_rx_w] 423 root 0 SW< [(null)_nci_tx_w] Move the id-allocation and struct-device initialisation back to nfc_allocate_device() and fix up the single call site which did not use nfc_free_device() in its error path. Fixes: 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs") Cc: Samuel Ortiz Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz [bwh: Backported to 3.16: drop change in nci_allocate_device()] Signed-off-by: Ben Hutchings commit 6d8c76588c1b03d63c8b76eaabac7a537e2d6714 Author: Liviu Dudau Date: Thu Jun 15 15:13:46 2017 +0100 drm/msm/hdmi: Use bitwise operators when building register values commit ffe8f53f9cc73fb25c8f78d4aed7ddf285503a60 upstream. Commit c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical OR operators to build up a value to be written in the REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it should have used bitwise operators. Signed-off-by: Liviu Dudau Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support") Signed-off-by: Rob Clark Signed-off-by: Ben Hutchings commit cd5c538dcc76c9fa5f67a12af42ed1f972f77a24 Author: Jan Kara Date: Tue Jun 13 16:20:25 2017 +0200 udf: Fix deadlock between writeback and udf_setsize() commit f2e95355891153f66d4156bf3a142c6489cd78c6 upstream. udf_setsize() called truncate_setsize() with i_data_sem held. Thus truncate_pagecache() called from truncate_setsize() could lock a page under i_data_sem which can deadlock as page lock ranks below i_data_sem - e. g. writeback can hold page lock and try to acquire i_data_sem to map a block. Fix the problem by moving truncate_setsize() calls from under i_data_sem. It is safe for us to change i_size without holding i_data_sem as all the places that depend on i_size being stable already hold inode_lock. Fixes: 7e49b6f2480cb9a9e7322a91592e56a5c85361f5 Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit c2952f3f64bc1ca44b131b796a375c09452a40e9 Author: Jan Kara Date: Tue Jun 13 15:54:58 2017 +0200 udf: Fix races with i_size changes during readpage commit 9795e0e8ac0d6a3ee092f1b555b284b57feef99e upstream. __udf_adinicb_readpage() uses i_size several times. When truncate changes i_size while the function is running, it can observe several different values and thus e.g. expose uninitialized parts of page to userspace. Also use i_size_read() in the function since it does not hold inode_lock. Since i_size is guaranteed to be small, this cannot really cause any issues even on 32-bit archs but let's be careful. Fixes: 9c2fc0de1a6e638fe58c354a463f544f42a90a09 Signed-off-by: Jan Kara [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit ecb36cfacaf5e3f4c157b869dc98cc34e28cd7af Author: Bjørn Mork Date: Tue Jun 13 19:11:42 2017 +0200 USB: serial: qcserial: new Sierra Wireless EM7305 device ID commit 996fab55d864ed604158f71724ff52db1c2454a3 upstream. A new Sierra Wireless EM7305 device ID used in a Toshiba laptop. Reported-by: Petr Kloc Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit fe37a6bd54242b2240af422728b7de947550c8ff Author: Johan Hovold Date: Mon Jun 12 16:30:16 2017 +0200 USB: serial: option: add two Longcheer device ids commit 8fb060da715ad10fe956d7c0077b2fb0c12bb9d7 upstream. Add two Longcheer device-id entries which specifically enables a Telewell TW-3G HSPA+ branded modem (0x9801). Reported-by: Teemu Likonen Reported-by: Bjørn Mork Reported-by: Lars Melin Tested-by: Teemu Likonen Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit db5dc64c381a7b2bded63f7d5694c08e5785485b Author: Mikulas Patocka Date: Wed Jun 7 19:05:31 2017 -0400 md: don't use flush_signals in userspace processes commit f9c79bc05a2a91f4fba8bfd653579e066714b1ec upstream. The function flush_signals clears all pending signals for the process. It may be used by kernel threads when we need to prepare a kernel thread for responding to signals. However using this function for an userspaces processes is incorrect - clearing signals without the program expecting it can cause misbehavior. The raid1 and raid5 code uses flush_signals in its request routine because it wants to prepare for an interruptible wait. This patch drops flush_signals and uses sigprocmask instead to block all signals (including SIGKILL) around the schedule() call. The signals are not lost, but the schedule() call won't respond to them. Signed-off-by: Mikulas Patocka Acked-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Ben Hutchings commit 4a4c33aa5053b6480a76ffa7980e1b754181722c Author: Bjorn Helgaas Date: Fri May 19 14:40:50 2017 -0500 PCI: Correct PCI_STD_RESOURCE_END usage commit 2f686f1d9beee135de6d08caea707ec7bfc916d4 upstream. PCI_STD_RESOURCE_END is (confusingly) the index of the last valid BAR, not the *number* of BARs. To iterate through all possible BARs, we need to include PCI_STD_RESOURCE_END. Fixes: 9fe373f9997b ("PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size") Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit 2b386faf9a413d7d024c57bde8eb5e3ca350595c Author: Benjamin Herrenschmidt Date: Tue Jun 13 16:01:13 2017 +1000 usb: Fix typo in the definition of Endpoint[out]Request commit 7cf916bd639bd26db7214f2205bccdb4b9306256 upstream. The current definition is wrong. This breaks my upcoming Aspeed virtual hub driver. Signed-off-by: Benjamin Herrenschmidt Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ff4440b1e2948503b56bb2a674e8e04dfa35f390 Author: Michael Grzeschik Date: Mon May 22 13:02:44 2017 +0200 usb: usbip: set buffer pointers to NULL after free commit b3b51417d0af63fb9a06662dc292200aed9ea53f upstream. The usbip stack dynamically allocates the transfer_buffer and setup_packet of each urb that got generated by the tcp to usb stub code. As these pointers are always used only once we will set them to NULL after use. This is done likewise to the free_urb code in vudc_dev.c. This patch fixes double kfree situations where the usbip remote side added the URB_FREE_BUFFER. Signed-off-by: Michael Grzeschik Acked-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust filenames] Signed-off-by: Ben Hutchings commit 0c4038dace69cf54b3950b9da38632a4c06066ef Author: Roopa Prabhu Date: Sun Jun 11 16:32:50 2017 -0700 vxlan: dont migrate permanent fdb entries during learn commit e0090a9e979de5202c7d16c635dea2f005221073 upstream. This patch fixes vxlan_snoop to not move permanent fdb entries on learn events. This is consistent with the bridge fdb handling of permanent entries. Fixes: 26a41ae60438 ("vxlan: only migrate dynamic FDB entries") Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit feb2dfa916aa428aa174a4ef127a9b96b9ae673f Author: Lorenzo Bianconi Date: Tue Jun 6 22:51:24 2017 +0200 iio: magnetometer: st_magn_spi: fix spi_device_id table commit c83761ff0aac954aa368c623bb0f0d1a3214e834 upstream. Remove LSM303DLHC, LSM303DLM from st_magn_id_table since LSM303DL series does not support spi interface Fixes: 872e79add756 (iio: magn: Add STMicroelectronics magn driver) Signed-off-by: Lorenzo Bianconi Signed-off-by: Jonathan Cameron Signed-off-by: Ben Hutchings commit e1ba68d915ba474681e1356bba1aff4d18459a69 Author: Lorenzo Bianconi Date: Tue Jun 6 22:51:23 2017 +0200 iio: accel: st_accel_spi: fix spi_device_id table commit 93b1b02fae8abff3efe570243e0f11f61e16e973 upstream. Remove LSM303DL, LSM303DLM, LSM303DLH, LSM303DLHC from st_accel_id_table since LSM303DL series does not support spi interface Fixes: d62511689de5 (iio: accel: Add STMicroelectronics accel driver) Signed-off-by: Lorenzo Bianconi Signed-off-by: Jonathan Cameron Signed-off-by: Ben Hutchings commit c0c628ad4b9bd80148130cee7dce4d3b166f7e35 Author: Jason A. Donenfeld Date: Sat Jun 10 04:59:11 2017 +0200 Bluetooth: use constant time memory comparison for secret values commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 upstream. This file is filled with complex cryptography. Thus, the comparisons of MACs and secret keys and curve points and so forth should not add timing attacks, which could either result in a direct forgery, or, given the complexity, some other type of attack. Signed-off-by: Jason A. Donenfeld Signed-off-by: Marcel Holtmann [bwh: Backported to 3.16: - Drop inapplicable changes - Adjust context] Signed-off-by: Ben Hutchings commit f85c50878fc8c38b2c034063cd886b6bdb67ab42 Author: Adam Borowski Date: Sat Jun 3 09:35:06 2017 +0200 vt: fix unchecked __put_user() in tioclinux ioctls commit 6987dc8a70976561d22450b5858fc9767788cc1c upstream. Only read access is checked before this call. Actually, at the moment this is not an issue, as every in-tree arch does the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU to tell them apart, but this wasn't the case in the past and may happen again on some odd arch in the future. If anyone cares about 3.7 and earlier, this is a security hole (untested) on real 80386 CPUs. Signed-off-by: Adam Borowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 19149e9c44c378f272d084a0fe813616370581f2 Author: Arnd Bergmann Date: Thu Jun 8 10:53:10 2017 +0200 xen: avoid type warning in xchg_xen_ulong commit 9cc91f212111cdcbefa02dcdb7dd443f224bf52c upstream. The improved type-checking version of container_of() triggers a warning for xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t contains a signed value: drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events': drivers/xen/events/events_2l.c:187:1020: error: call to '__compiletime_assert_187' declared with attribute error: pointer type mismatch in container_of() This adds a cast to work around the warning. Cc: Ian Abbott Fixes: 85323a991d40 ("xen: arm: mandate EABI and use generic atomic operations.") Fixes: daa2ac80834d ("kernel.h: handle pointers to arrays better in container_of()") Signed-off-by: Arnd Bergmann Signed-off-by: Stefano Stabellini Reviewed-by: Stefano Stabellini Acked-by: Ian Abbott Signed-off-by: Ben Hutchings commit 8bc42618e67ba4909194d5d09c4f013f673e339d Author: Peter Zijlstra Date: Tue May 30 11:45:12 2017 +0200 perf/core: Correct event creation with PERF_FORMAT_GROUP commit ba5213ae6b88fb170c4771fef6553f759c7d8cdd upstream. Andi was asking about PERF_FORMAT_GROUP vs inherited events, which led to the discovery of a bug from commit: 3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff") - PERF_SAMPLE_GROUP = 1U << 4, + PERF_SAMPLE_READ = 1U << 4, - if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP)) + if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP)) is a clear fail :/ While this changes user visible behaviour; it was previously possible to create an inherited event with PERF_SAMPLE_READ; this is deemed acceptible because its results were always incorrect. Reported-by: Andi Kleen Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff") Link: http://lkml.kernel.org/r/20170530094512.dy2nljns2uq7qa3j@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 072983423fe2a5e80bd070d1a43944bb023a0ec3 Author: Chris Wilson Date: Wed May 31 18:50:43 2017 +0300 e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails commit 833521ebc65b1c3092e5c0d8a97092f98eec595d upstream. An error during suspend (e100e_pm_suspend), [ 429.994338] ACPI : EC: event blocked [ 429.994633] e1000e: EEE TX LPI TIMER: 00000011 [ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2 [ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2 [ 430.955458] PM: Device 0000:00:19.0 failed to suspend async: error -2 [ 430.955581] PM: Some devices failed to suspend, or early wake event detected [ 430.957709] ACPI : EC: event unblocked lead to complete failure: [ 432.585002] ------------[ cut here ]------------ [ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 __free_irq+0x9f/0x280 [ 432.585015] Trying to free already-free IRQ 20 [ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci i915 mmc_core e1000e ptp pps_core prime_numbers [ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U 4.10.0-rc8-CI-Patchwork_3870+ #1 [ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012 [ 432.585050] Workqueue: events_unbound async_run_entry_fn [ 432.585051] Call Trace: [ 432.585058] dump_stack+0x67/0x92 [ 432.585062] __warn+0xc6/0xe0 [ 432.585065] warn_slowpath_fmt+0x4a/0x50 [ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60 [ 432.585072] __free_irq+0x9f/0x280 [ 432.585075] free_irq+0x34/0x80 [ 432.585089] e1000_free_irq+0x65/0x70 [e1000e] [ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e] [ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e] [ 432.585113] pci_pm_suspend+0x71/0x140 [ 432.585118] dpm_run_callback+0x6f/0x330 [ 432.585122] ? pci_pm_freeze+0xe0/0xe0 [ 432.585125] __device_suspend+0xea/0x330 [ 432.585128] async_suspend+0x1a/0x90 [ 432.585132] async_run_entry_fn+0x34/0x160 [ 432.585137] process_one_work+0x1f4/0x6d0 [ 432.585140] ? process_one_work+0x16e/0x6d0 [ 432.585143] worker_thread+0x49/0x4a0 [ 432.585145] kthread+0x107/0x140 [ 432.585148] ? process_one_work+0x6d0/0x6d0 [ 432.585150] ? kthread_create_on_node+0x40/0x40 [ 432.585154] ret_from_fork+0x2e/0x40 [ 432.585156] ---[ end trace 6712df7f8c4b9124 ]--- The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM flows"), but it may be a later patch that introduced the non-recoverable behaviour. Fixes: 2800209994f8 ("e1000e: Refactor PM flows") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847 Signed-off-by: Chris Wilson Signed-off-by: Jani Nikula Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Ben Hutchings commit a18c6f1f21f09ca50e4467a484b18b4d6fd87dbb Author: David Ertman Date: Fri Jul 11 06:21:31 2014 +0000 e1000e: Fix Runtime PM blocks EEE link negotiation in S5 commit 2a7e19af94104b270d675c52bba2ca1bc20efa70 upstream. Adding a function, and associated calls, to flush writes to (read) the LPIC MAC register before entering the shutdown flow. This fixes the problem of the PHY never negotiating a 100M link (if both sides of the link support EEE and 100M link) when Runtime PM is enabled. Signed-off-by: Dave Ertman Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Ben Hutchings commit 2e06c6fc5c992a03f1d198aed826614b33d2330d Author: Jim Mattson Date: Tue May 23 11:52:54 2017 -0700 kvm: vmx: Check value written to IA32_BNDCFGS commit 4531662d1abf6c1f0e5c2b86ddb60e61509786c8 upstream. Bits 11:2 must be zero and the linear addess in bits 63:12 must be canonical. Otherwise, WRMSR(BNDCFGS) should raise #GP. Fixes: 0dd376e709975779 ("KVM: x86: add MSR_IA32_BNDCFGS to msrs_to_save") Signed-off-by: Jim Mattson Signed-off-by: Radim Krčmář [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 95ac78eafd026fb38c38a8f312acdd6fd8aee747 Author: Jim Mattson Date: Wed May 24 10:49:25 2017 -0700 kvm: x86: Guest BNDCFGS requires guest MPX support commit 4439af9f911ae0243ffe4e2dfc12bace49605d8b upstream. The BNDCFGS MSR should only be exposed to the guest if the guest supports MPX. (cf. the TSC_AUX MSR and RDTSCP.) Fixes: 0dd376e709975779 ("KVM: x86: add MSR_IA32_BNDCFGS to msrs_to_save") Change-Id: I3ad7c01bda616715137ceac878f3fa7e66b6b387 Signed-off-by: Jim Mattson Signed-off-by: Radim Krčmář [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 2d3ba9eb219ed31ef17b113d36a94315b1945f12 Author: Jim Mattson Date: Tue May 23 11:52:52 2017 -0700 kvm: vmx: Do not disable intercepts for BNDCFGS commit a8b6fda38f80e75afa3b125c9e7f2550b579454b upstream. The MSR permission bitmaps are shared by all VMs. However, some VMs may not be configured to support MPX, even when the host does. If the host supports VMX and the guest does not, we should intercept accesses to the BNDCFGS MSR, so that we can synthesize a #GP fault. Furthermore, if the host does not support MPX and the "ignore_msrs" kvm kernel parameter is set, then we should intercept accesses to the BNDCFGS MSR, so that we can skip over the rdmsr/wrmsr without raising a #GP fault. Fixes: da8999d31818fdc8 ("KVM: x86: Intel MPX vmx and msr handle") Signed-off-by: Jim Mattson Signed-off-by: Radim Krčmář Signed-off-by: Ben Hutchings commit bc3fef98f5cd5f4714c8e5f5250051d639839b7b Author: Johan Hovold Date: Thu Jun 1 04:45:59 2017 -0300 mceusb: fix memory leaks in error path commit 2d5a6ce71c72d98d4f7948672842e3e8c265a8b7 upstream. Fix urb and transfer-buffer leaks in an urb-submission error path which may be hit when a device is disconnected. Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver") Cc: Jarod Wilson Signed-off-by: Johan Hovold Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: - Add check on urb_type, as async_buf and async_urb aren't always allocated - Adjust context] Signed-off-by: Ben Hutchings commit 88db7e7379763a2e6a9923867a76132afa11fd90 Author: Ville Syrjälä Date: Thu Dec 15 19:47:34 2016 +0200 drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail commit ec1b4ee2834e66884e5b0d3d465f347ff212e372 upstream. The scanline counter is bonkers on VLV/CHV DSI. The scanline counter increment is not lined up with the start of vblank like it is on every other platform and output type. This causes problems for both the vblank timestamping and atomic update vblank evasion. On my FFRD8 machine at least, the scanline counter increment happens about 1/3 of a scanline ahead of the start of vblank (which is where all register latching happens still). That means we can't trust the scanline counter to tell us whether we're in vblank or not while we're on that particular line. In order to keep vblank timestamping in working condition when called from the vblank irq, we'll leave scanline_offset at one, which means that the entire line containing the start of vblank is considered to be inside the vblank. For the vblank evasion we'll need to consider that entire line to be bad, since we can't tell whether the registers already got latched or not. And we can't actually use the start of vblank interrupt to get us past that line as the interrupt would fire too soon, and then we'd up waiting for the next start of vblank instead. One way around that would using the frame start interrupt instead since that wouldn't fire until the next scanline, but that would require some bigger changes in the interrupt code. So for simplicity we'll just poll until we get past the bad line. v2: Adjust the comments a bit Cc: Jonas Aaberg Tested-by: Jonas Aaberg Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.com Tested-by: Mika Kahola Reviewed-by: Mika Kahola [bwh: Backported to 3.16: - Pass dev instead of dev_priv to hardware type predicates - Use intel_pipe_has_type() to check output type] Signed-off-by: Ben Hutchings commit d8811a78910658bfc5acf07ad7b1080f2431a86a Author: Wolfram Sang Date: Sat May 27 20:52:43 2017 +0200 Documentation: DMA API: fix a typo in a function name commit 6a08d83e4324fcb23994dfd481acedf49e37cc06 upstream. Correct the typo, the wrongly typed function does not exist. Fixes: 6c9c6d6301287e ("dma-debug: New interfaces to debug dma mapping errors") Signed-off-by: Wolfram Sang Signed-off-by: Jonathan Corbet Signed-off-by: Ben Hutchings commit d0e24a66ea00f2d0e2566609ef3758d607141c0f Author: Ben Hutchings Date: Thu May 25 12:58:33 2017 +0000 tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth commit 98dcea0cfd04e083ac74137ceb9a632604740e2d upstream. liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is within the range of lock_chain::depth and in liblockdep it is much too large. That should have resulted in a compiler error, but didn't because: - the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep so is assumed to be an (undeclared) function - putting a function call inside a BUILD_BUG_ON() expression quietly turns it into some nonsense involving a variable-length array It did produce a compiler warning, but I didn't notice because liblockdep already produces too many warnings if -Wall is enabled (which I'll fix shortly). Even before that commit, which reduced lock_chain::depth from 8 bits to 6, MAX_LOCK_DEPTH was too large. Signed-off-by: Ben Hutchings Signed-off-by: Sasha Levin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: a.p.zijlstra@chello.nl Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com Signed-off-by: Ingo Molnar commit d92cb3f3dc987f2fc1ae2167e4857e8ca8429df8 Author: Thomas Bogendoerfer Date: Wed May 31 22:21:03 2017 +0200 Fix serial console on SNI RM400 machines commit e279e6d98e0cf2c2fe008b3c29042b92f0e17b1d upstream. sccnxp driver doesn't get the correct uart clock rate, if CONFIG_HAVE_CLOCK is disabled. Correct usage of clk API to make it work with/without it. Fixes: 90efa75f7ab0 (serial: sccnxp: Using CLK API for getting UART clock) Suggested-by: Russell King - ARM Linux Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5b7e674de9813b7d6ffd3c2ff8e4711d3e0be1a6 Author: Dong Bo Date: Tue Apr 25 14:11:29 2017 +0800 arm64: Preventing READ_IMPLIES_EXEC propagation commit 48f99c8ec0b25756d0283ab058826ae07d14fad7 upstream. Like arch/arm/, we inherit the READ_IMPLIES_EXEC personality flag across fork(). This is undesirable for a number of reasons: * ELF files that don't require executable stack can end up with it anyway * We end up performing un-necessary I-cache maintenance when mapping what should be non-executable pages * Restricting what is executable is generally desirable when defending against overflow attacks This patch clears the personality flag when setting up the personality for newly spwaned native tasks. Given that semi-recent AArch64 toolchains emit a non-executable PT_GNU_STACK header, userspace applications can already not rely on READ_IMPLIES_EXEC so shouldn't be adversely affected by this change. Reported-by: Peter Maydell Signed-off-by: Dong Bo [will: added comment to compat code, rewrote commit message] Signed-off-by: Will Deacon [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit bafc404f3c70257f81f3f674b78687944ac6e144 Author: Arnd Bergmann Date: Thu May 11 13:52:09 2017 +0200 wlcore: fix 64K page support commit 4a4274bf2dbbd1c7a45be0c89a1687c9d2eef4a0 upstream. In the stable linux-3.16 branch, I ran into a warning in the wlcore driver: drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write': drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Newer kernels no longer show the warning, but the bug is still there, as the allocation is based on the CPU page size rather than the actual capabilities of the hardware. This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes per buffer. Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo [bwh: Backported to 3.16: - Include for definition of SZ_4K - Adjust context] Signed-off-by: Ben Hutchings commit 5b2a097f212ee260663b7d133a3878546aab36b4 Author: Jaegeuk Kim Date: Wed May 17 10:36:58 2017 -0700 f2fs: try to freeze in gc and discard threads commit 1d7be2708277edfef95171d52fb65ee26eaa076b upstream. This allows to freeze gc and discard threads. Signed-off-by: Jaegeuk Kim [bwh: Backported to 3.16: drop changes to discard thread] Signed-off-by: Ben Hutchings commit 54749559969963ea435013122941643a90f1c6b3 Author: Jaegeuk Kim Date: Tue May 16 13:20:16 2017 -0700 f2fs: load inode's flag from disk commit 93607124c5450148e592c3d18ac533b4e5f25b8b upstream. This patch fixes missing inode flag loaded from disk, reported by Tom. [tom@localhost ~]$ sudo mount /dev/loop0 /mnt/ [tom@localhost ~]$ sudo chown tom:tom /mnt/ [tom@localhost ~]$ touch /mnt/testfile [tom@localhost ~]$ sudo chattr +i /mnt/testfile [tom@localhost ~]$ echo test > /mnt/testfile bash: /mnt/testfile: Operation not permitted [tom@localhost ~]$ rm /mnt/testfile rm: cannot remove '/mnt/testfile': Operation not permitted [tom@localhost ~]$ sudo umount /mnt/ [tom@localhost ~]$ sudo mount /dev/loop0 /mnt/ [tom@localhost ~]$ lsattr /mnt/testfile ----i-------------- /mnt/testfile [tom@localhost ~]$ echo test > /mnt/testfile [tom@localhost ~]$ rm /mnt/testfile [tom@localhost ~]$ sudo umount /mnt/ Reported-by: Tom Yan Signed-off-by: Jaegeuk Kim [bwh: Backported to 3.16: mark_inode_dirty() is in the right place, so only f2fs_iget() needs to be changed] Signed-off-by: Ben Hutchings commit 5fb69048bd7b9b02502ea8cef5d808551e538979 Author: Dong Aisheng Date: Fri May 19 15:05:41 2017 +0800 pinctrl: imx: fix debug message for SHARE_MUX_CONF_REG case commit 66b54e3a5a64925d9819eae86b8f36e90e60037f upstream. The original implemented debug message does not work for SHARE_MUX_CONF_REG case. This patch fixes it. Fixes: bf5a530971af ("pinctrl: imx: add VF610 support to imx pinctrl framework") Signed-off-by: Dong Aisheng Acked-by: Shawn Guo Signed-off-by: Linus Walleij [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit a5a1c8fd6c001268438beeae54141ed7eae3352d Author: Brian Norris Date: Fri May 12 09:41:58 2017 -0700 mwifiex: fixup error cases in mwifiex_add_virtual_intf() commit 8535107aa4ef92520cbb9a4739563b389c5f8e2c upstream. If we fail to add an interface in mwifiex_add_virtual_intf(), we might hit a BUG_ON() in the networking code, because we didn't tear things down properly. Among the problems: (a) when failing to allocate workqueues, we fail to unregister the netdev before calling free_netdev() (b) even if we do try to unregister the netdev, we're still holding the rtnl lock, so the device never properly unregistered; we'll be at state NETREG_UNREGISTERING, and then hit free_netdev()'s: BUG_ON(dev->reg_state != NETREG_UNREGISTERED); (c) we're allocating some dependent resources (e.g., DFS workqueues) after we've registered the interface; this may or may not cause problems, but it's good practice to allocate these before registering (d) we're not even trying to unwind anything when mwifiex_send_cmd() or mwifiex_sta_init_cmd() fail To fix these issues, let's: * add a stacked set of error handling labels, to keep error handling consistent and properly ordered (resolving (a) and (d)) * move the workqueue allocations before the registration (to resolve (c); also resolves (b) by avoiding error cases where we have to unregister) [Incidentally, it's pretty easy to interrupt the alloc_workqueue() in, e.g., the following: iw phy phy0 interface add mlan0 type station by sending it SIGTERM.] This bugfix covers commits like commit 7d652034d1a0 ("mwifiex: channel switch support for mwifiex"), but parts of this bug exist all the way back to the introduction of dynamic interface handling in commit 93a1df48d224 ("mwifiex: add cfg80211 handlers add/del_virtual_intf"). Signed-off-by: Brian Norris Signed-off-by: Kalle Valo [bwh: Backported to 3.16: - There is no workqueue allocation or cleanup needed here - Add 'ret' variable - Keep logging errors with wiphy_err() - Adjust filename] Signed-off-by: Ben Hutchings commit 5a7aba3f27f7262cc5fad1b85804ea0ad9f4275c Author: Peter Zijlstra Date: Tue Apr 25 14:31:11 2017 +0200 sched/topology: Fix overlapping sched_group_capacity commit 1676330ecfa840113a37b25a49afda068380d19c upstream. When building the overlapping groups we need to attach a consistent sched_group_capacity structure. That is, all 'identical' sched_group's should have the _same_ sched_group_capacity. This can (once again) be demonstrated with a topology like: node 0 1 2 3 0: 10 20 30 20 1: 20 10 20 30 2: 30 20 10 20 3: 20 30 20 10 But we need at least 2 CPUs per node for this to show up, after all, if there is only one CPU per node, our CPU @i is per definition a unique CPU that reaches this domain (aka balance-cpu). Given the above NUMA topo and 2 CPUs per node: [] CPU0 attaching sched-domain(s): [] domain-0: span=0,4 level=DIE [] groups: 0:{ span=0 }, 4:{ span=4 } [] domain-1: span=0-1,3-5,7 level=NUMA [] groups: 0:{ span=0,4 mask=0,4 cap=2048 }, 1:{ span=1,5 mask=1,5 cap=2048 }, 3:{ span=3,7 mask=3,7 cap=2048 } [] domain-2: span=0-7 level=NUMA [] groups: 0:{ span=0-1,3-5,7 mask=0,4 cap=6144 }, 2:{ span=1-3,5-7 mask=2,6 cap=6144 } [] CPU1 attaching sched-domain(s): [] domain-0: span=1,5 level=DIE [] groups: 1:{ span=1 }, 5:{ span=5 } [] domain-1: span=0-2,4-6 level=NUMA [] groups: 1:{ span=1,5 mask=1,5 cap=2048 }, 2:{ span=2,6 mask=2,6 cap=2048 }, 4:{ span=0,4 mask=0,4 cap=2048 } [] domain-2: span=0-7 level=NUMA [] groups: 1:{ span=0-2,4-6 mask=1,5 cap=6144 }, 3:{ span=0,2-4,6-7 mask=3,7 cap=6144 } Observe how CPU0-domain1-group0 and CPU1-domain1-group4 are the 'same' but have a different id (0 vs 4). To fix this, use the group balance CPU to select the SGC. This means we have to compute the full mask for each CPU and require a second temporary mask to store the group mask in (it otherwise lives in the SGC). The fixed topology looks like: [] CPU0 attaching sched-domain(s): [] domain-0: span=0,4 level=DIE [] groups: 0:{ span=0 }, 4:{ span=4 } [] domain-1: span=0-1,3-5,7 level=NUMA [] groups: 0:{ span=0,4 mask=0,4 cap=2048 }, 1:{ span=1,5 mask=1,5 cap=2048 }, 3:{ span=3,7 mask=3,7 cap=2048 } [] domain-2: span=0-7 level=NUMA [] groups: 0:{ span=0-1,3-5,7 mask=0,4 cap=6144 }, 2:{ span=1-3,5-7 mask=2,6 cap=6144 } [] CPU1 attaching sched-domain(s): [] domain-0: span=1,5 level=DIE [] groups: 1:{ span=1 }, 5:{ span=5 } [] domain-1: span=0-2,4-6 level=NUMA [] groups: 1:{ span=1,5 mask=1,5 cap=2048 }, 2:{ span=2,6 mask=2,6 cap=2048 }, 0:{ span=0,4 mask=0,4 cap=2048 } [] domain-2: span=0-7 level=NUMA [] groups: 1:{ span=0-2,4-6 mask=1,5 cap=6144 }, 3:{ span=0,2-4,6-7 mask=3,7 cap=6144 } Debugged-by: Lauro Ramos Venancio Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans") Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 00c978eada13e2cd1bc7da485e99ab5fb7c3418c Author: Peter Zijlstra Date: Tue Apr 25 14:00:49 2017 +0200 sched/topology: Fix overlapping sched_group_mask commit 73bb059f9b8a00c5e1bf2f7ca83138c05d05e600 upstream. The point of sched_group_mask is to select those CPUs from sched_group_cpus that can actually arrive at this balance domain. The current code gets it wrong, as can be readily demonstrated with a topology like: node 0 1 2 3 0: 10 20 30 20 1: 20 10 20 30 2: 30 20 10 20 3: 20 30 20 10 Where (for example) domain 1 on CPU1 ends up with a mask that includes CPU0: [] CPU1 attaching sched-domain: [] domain 0: span 0-2 level NUMA [] groups: 1 (mask: 1), 2, 0 [] domain 1: span 0-3 level NUMA [] groups: 0-2 (mask: 0-2) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072) This causes sched_balance_cpu() to compute the wrong CPU and consequently should_we_balance() will terminate early resulting in missed load-balance opportunities. The fixed topology looks like: [] CPU1 attaching sched-domain: [] domain 0: span 0-2 level NUMA [] groups: 1 (mask: 1), 2, 0 [] domain 1: span 0-3 level NUMA [] groups: 0-2 (mask: 1) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072) (note: this relies on OVERLAP domains to always have children, this is true because the regular topology domains are still here -- this is before degenerate trimming) Debugged-by: Lauro Ramos Venancio Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans") Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: - Use span, not sg_span - Adjust filename context] Signed-off-by: Ben Hutchings commit 49d4283d847987fccbd7c7ce8f59f0fd765702ff Author: Peter Zijlstra Date: Fri Apr 14 17:24:02 2017 +0200 sched/topology: Fix building of overlapping sched-groups commit 0372dd2736e02672ac6e189c31f7d8c02ad543cd upstream. When building the overlapping groups, we very obviously should start with the previous domain of _this_ @cpu, not CPU-0. This can be readily demonstrated with a topology like: node 0 1 2 3 0: 10 20 30 20 1: 20 10 20 30 2: 30 20 10 20 3: 20 30 20 10 Where (for example) CPU1 ends up generating the following nonsensical groups: [] CPU1 attaching sched-domain: [] domain 0: span 0-2 level NUMA [] groups: 1 2 0 [] domain 1: span 0-3 level NUMA [] groups: 1-3 (cpu_capacity = 3072) 0-1,3 (cpu_capacity = 3072) Where the fact that domain 1 doesn't include a group with span 0-2 is the obvious fail. With patch this looks like: [] CPU1 attaching sched-domain: [] domain 0: span 0-2 level NUMA [] groups: 1 0 2 [] domain 1: span 0-3 level NUMA [] groups: 0-2 (cpu_capacity = 3072) 0,2-3 (cpu_capacity = 3072) Debugged-by: Lauro Ramos Venancio Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans") Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit cbff7ea5d47aa15e1b6d8063bd147cc0a289e452 Author: Peter Zijlstra Date: Fri Apr 14 14:20:05 2017 +0200 sched/fair, cpumask: Export for_each_cpu_wrap() commit c743f0a5c50f2fcbc628526279cfa24f3dabe182 upstream. More users for for_each_cpu_wrap() have appeared. Promote the construct to generic cpumask interface. The implementation is slightly modified to reduce arguments. Signed-off-by: Peter Zijlstra (Intel) Cc: Lauro Ramos Venancio Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: lwang@redhat.com Link: http://lkml.kernel.org/r/20170414122005.o35me2h5nowqkxbv@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: there's no old version of the function to delete] Signed-off-by: Ben Hutchings commit 07a1b64820763f257ba5099bd691c22f1e9a15b4 Author: Lauro Ramos Venancio Date: Thu Apr 13 10:56:07 2017 -0300 sched/topology: Refactor function build_overlap_sched_groups() commit 8c0334697dc37eb3d6d7632304d3a3662248daac upstream. Create functions build_group_from_child_sched_domain() and init_overlap_sched_group(). No functional change. Signed-off-by: Lauro Ramos Venancio Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1492091769-19879-2-git-send-email-lvenanci@redhat.com Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: - Ccode being moved is slightly different - Adjust filename] Signed-off-by: Ben Hutchings commit 7b565013a51c217a648c067d12f7a17186f172f9 Author: Zhihui Zhang Date: Fri Aug 1 21:18:03 2014 -0400 sched: Rename a misleading variable in build_overlap_sched_groups() commit aaecac4ad46b35ad308245384d019633fb9bc21b upstream. The child variable in build_overlap_sched_groups() actually refers to the peer or sibling domain of the given CPU. Rename it to sibling to be consistent with the naming in build_group_mask(). Signed-off-by: Zhihui Zhang Signed-off-by: Peter Zijlstra Cc: Linus Torvalds Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1406942283-18249-1-git-send-email-zzhsuny@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings