commit 0da74753f7f9a7adf3b4dfa309ba95386daa2098 Author: Greg Kroah-Hartman Date: Wed Nov 8 10:17:19 2017 +0100 Linux 4.13.12 commit ebe22ac83eb61c2162fa9ff97b9648ee1cfb8c3d Author: Antoine Tenart Date: Wed Oct 25 09:23:26 2017 +0200 irqchip/irq-mvebu-gicp: Add missing spin_lock init commit c9bb86338a6bb91e4d32db04feb6b8d423e04d06 upstream. A spin lock is used in the irq-mvebu-gicp driver, but it is never initialized. This patch adds the missing spin_lock_init() call in the driver's probe function. Fixes: a68a63cb4dfc ("irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP") Signed-off-by: Antoine Tenart Signed-off-by: Thomas Gleixner Reviewed-by: gregory.clement@free-electrons.com Acked-by: marc.zyngier@arm.com Cc: thomas.petazzoni@free-electrons.com Cc: andrew@lunn.ch Cc: jason@lakedaemon.net Cc: nadavh@marvell.com Cc: miquel.raynal@free-electrons.com Cc: linux-arm-kernel@lists.infradead.org Cc: sebastian.hesselbarth@gmail.com Link: https://lkml.kernel.org/r/20171025072326.21030-1-antoine.tenart@free-electrons.com Signed-off-by: Greg Kroah-Hartman commit 55da524bdf0340ccbe73c7ab77f2a1ec1732bad6 Author: Borislav Petkov Date: Wed Nov 1 17:47:54 2017 +0100 x86/mcelog: Get rid of RCU remnants commit 7298f08ea8870d44d36c7d6cd07dd0303faef6c2 upstream. Jeremy reported a suspicious RCU usage warning in mcelog. /dev/mcelog is called in process context now as part of the notifier chain and doesn't need any of the fancy RCU and lockless accesses which it did in atomic context. Axe it all in favor of a simple mutex synchronization which cures the problem reported. Fixes: 5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver") Reported-by: Jeremy Cline Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-and-tested-by: Tony Luck Cc: Andi Kleen Cc: linux-edac@vger.kernel.org Cc: Laura Abbott Link: https://lkml.kernel.org/r/20171101164754.xzzmskl4ngrqc5br@pd.tnic Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969 Signed-off-by: Greg Kroah-Hartman commit 88f41b61b6bd55d01cd2c04f911b2d0dae997287 Author: Tejun Heo Date: Sat Oct 28 09:49:37 2017 -0700 perf/cgroup: Fix perf cgroup hierarchy support commit be96b316deff35e119760982c43af74e606fa143 upstream. The following commit: 864c2357ca89 ("perf/core: Do not set cpuctx->cgrp for unscheduled cgroups") made list_update_cgroup_event() skip setting cpuctx->cgrp if no cgroup event targets %current's cgroup. This breaks perf_event's hierarchical support because events which target one of the ancestors get ignored. Fix it by using cgroup_is_descendant() test instead of equality. Signed-off-by: Tejun Heo Acked-by: Thomas Gleixner Cc: Arnaldo Carvalho de Melo Cc: David Carrillo-Cisneros Cc: Linus Torvalds Cc: Peter Zijlstra Cc: kernel-team@fb.com Fixes: 864c2357ca89 ("perf/core: Do not set cpuctx->cgrp for unscheduled cgroups") Link: http://lkml.kernel.org/r/20171028164237.GA972780@devbig577.frc2.facebook.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ce0eadf4b1bdeabecb9e31dfe39d292767f9febc Author: Peter Zijlstra Date: Tue Oct 31 11:18:53 2017 +0100 futex: Fix more put_pi_state() vs. exit_pi_state_list() races commit 153fbd1226fb30b8630802aa5047b8af5ef53c9f upstream. Dmitry (through syzbot) reported being able to trigger the WARN in get_pi_state() and a use-after-free on: raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock); Both are due to this race: exit_pi_state_list() put_pi_state() lock(&curr->pi_lock) while() { pi_state = list_first_entry(head); hb = hash_futex(&pi_state->key); unlock(&curr->pi_lock); dec_and_test(&pi_state->refcount); lock(&hb->lock) lock(&pi_state->pi_mutex.wait_lock) // uaf if pi_state free'd lock(&curr->pi_lock); .... unlock(&curr->pi_lock); get_pi_state(); // WARN; refcount==0 The problem is we take the reference count too late, and don't allow it being 0. Fix it by using inc_not_zero() and simply retrying the loop when we fail to get a refcount. In that case put_pi_state() should remove the entry from the list. Reported-by: Dmitry Vyukov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Gleixner Cc: Gratian Crisan Cc: Linus Torvalds Cc: Peter Zijlstra Cc: dvhart@infradead.org Cc: syzbot Cc: syzkaller-bugs@googlegroups.com Fixes: c74aef2d06a9 ("futex: Fix pi_state->owner serialization") Link: http://lkml.kernel.org/r/20171031101853.xpfh72y643kdfhjs@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a351eccfb5354b409d01c213910be85429e244c4 Author: Naveen N. Rao Date: Mon Oct 30 20:42:09 2017 +0530 powerpc/kprobes: Dereference function pointers only if the address does not belong to kernel text commit e6c4dcb308160115287afd87afb63b5684d75a5b upstream. This makes the changes introduced in commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") to be specific to the kprobe subsystem. We previously changed ppc_function_entry() to always check the provided address to confirm if it needed to be dereferenced. This is actually only an issue for kprobe blacklisted asm labels (through use of _ASM_NOKPROBE_SYMBOL) and can cause other issues with ftrace. Also, the additional checks are not really necessary for our other uses. As such, move this check to the kprobes subsystem. Fixes: 83e840c770f2 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bcef2ac5fefcd273db50d4bad47f69266d3aba0b Author: Rafael J. Wysocki Date: Fri Nov 3 16:35:49 2017 +0100 x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo commit 941f5f0f6ef5338814145cf2b813cf1f98873e2f upstream. Commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes made after the commit it has reverted. To address this, make the code in question use arch_freq_get_on_cpu() which also is used by cpufreq for reporting the current frequency of CPUs and since that function doesn't really depend on cpufreq in any way, drop the CONFIG_CPU_FREQ dependency for the object file containing it. Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and return cached values right away if it is called very often over a short time (to prevent user space from triggering IPI storms through it). Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"") Signed-off-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cce587de30c755abe0187c2639ac6154d38eef0e Author: Linus Torvalds Date: Thu Nov 2 14:06:32 2017 -0700 Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"" commit 890da9cf098364b11a7f7f5c22fa652531624d03 upstream. This reverts commit 51204e0639c49ada02fd823782ad673b6326d748. There wasn't really any good reason for it, and people are complaining (rightly) that it broke existing practice. Cc: Len Brown Cc: Thomas Gleixner Cc: Rafael J. Wysocki Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 539954a756f7749bae8775bdaae3ff4d477fa1e7 Author: Matt Redfearn Date: Wed Sep 27 10:13:25 2017 +0100 MIPS: SMP: Fix deadlock & online race commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream. Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock. The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation. As noted in the commit message, upstream differs in this area. Commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing. To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised. This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up"). Signed-off-by: Matt Redfearn Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") CC: Matija Glavinic Pecotic Patchwork: https://patchwork.linux-mips.org/patch/17376/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit dac72696c96b9e109a3a7b04fafa276a7343fb9a Author: Gustavo A. R. Silva Date: Tue Oct 31 00:35:03 2017 -0500 MIPS: microMIPS: Fix incorrect mask in insn_table_MM commit 77238e76b9156d28d86c1e31c00ed2960df0e4de upstream. It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction") Reported-by: Julia Lawall Signed-off-by: Gustavo A. R. Silva Reviewed-by: James Hogan Patchwork: https://patchwork.linux-mips.org/patch/17551/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit f7db1164658a70da1fbdfa1599a15b3cb82b1b0b Author: Jason A. Donenfeld Date: Mon Oct 23 19:20:56 2017 +0200 MIPS: smp-cmp: Use right include for task_struct commit f677b77050c144bd4c515b91ea48bd0efe82355e upstream. When task_struct was moved, this MIPS code was neglected. Evidently nobody is using it anymore. This fixes this build error: In file included from ./arch/mips/include/asm/thread_info.h:15:0, from ./include/linux/thread_info.h:37, from ./include/asm-generic/current.h:4, from ./arch/mips/include/generated/asm/current.h:1, from ./include/linux/sched.h:11, from arch/mips/kernel/smp-cmp.c:22: arch/mips/kernel/smp-cmp.c: In function ‘cmp_boot_secondary’: ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration of function ‘task_stack_page’ [-Werror=implicit-function-declaration] #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \ ^ arch/mips/kernel/smp-cmp.c:84:21: note: in expansion of macro ‘__KSTK_TOS’ unsigned long sp = __KSTK_TOS(idle); ^~~~~~~~~~ Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs from to ") Signed-off-by: Jason A. Donenfeld Patchwork: https://patchwork.linux-mips.org/patch/17522/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 6208dab1193995b5d327cfe71e301295340d3342 Author: Wei Yongjun Date: Fri Oct 13 09:25:17 2017 +0000 MIPS: bpf: Fix a typo in build_one_insn() commit 6a2932a463d526e362a6b4e112be226f1d18d088 upstream. Fix a typo in build_one_insn(). Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.") Signed-off-by: Wei Yongjun Patchwork: https://patchwork.linux-mips.org/patch/17491/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 9a0422b63d96a15aa253b3aae55a21e1b418468b Author: Naveen N. Rao Date: Mon Oct 30 20:42:08 2017 +0530 Revert "powerpc64/elfv1: Only dereference function descriptor for non-text symbols" commit 63be1a81e40733ecd175713b6a7558dc43f00851 upstream. This reverts commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols"). Chandan reported that on newer kernels, trying to enable function_graph tracer on ppc64 (BE) locks up the system with the following trace: Unable to handle kernel paging request for data at address 0x600000002fa30010 Faulting instruction address: 0xc0000000001f1300 Thread overran stack, or stack corrupted Oops: Kernel access of bad area, sig: 11 [#1] BE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries Modules linked in: CPU: 1 PID: 6586 Comm: bash Not tainted 4.14.0-rc3-00162-g6e51f1f-dirty #20 task: c000000625c07200 task.stack: c000000625c07310 NIP: c0000000001f1300 LR: c000000000121cac CTR: c000000000061af8 REGS: c000000625c088c0 TRAP: 0380 Not tainted (4.14.0-rc3-00162-g6e51f1f-dirty) MSR: 8000000000001032 CR: 28002848 XER: 00000000 CFAR: c0000000001f1320 SOFTE: 0 ... NIP [c0000000001f1300] .__is_insn_slot_addr+0x30/0x90 LR [c000000000121cac] .kernel_text_address+0x18c/0x1c0 Call Trace: [c000000625c08b40] [c0000000001bd040] .is_module_text_address+0x20/0x40 (unreliable) [c000000625c08bc0] [c000000000121cac] .kernel_text_address+0x18c/0x1c0 [c000000625c08c50] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c08cf0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c08d60] [c000000000121b40] .kernel_text_address+0x20/0x1c0 [c000000625c08df0] [c000000000061960] .prepare_ftrace_return+0x50/0x130 ... [c000000625c0ab30] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c0abd0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c0ac40] [c000000000121b40] .kernel_text_address+0x20/0x1c0 [c000000625c0acd0] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c0ad70] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c0ade0] [c000000000121b40] .kernel_text_address+0x20/0x1c0 This is because ftrace is using ppc_function_entry() for obtaining the address of return_to_handler() in prepare_ftrace_return(). The call to kernel_text_address() itself gets traced and we end up in a recursive loop. Fixes: 83e840c770f2 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") Reported-by: Chandan Rajendra Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 105a9eaea219a4febf3a722b592d7896d8ce86f7 Author: Jani Nikula Date: Thu Oct 26 17:29:31 2017 +0300 drm/i915/edp: read edp display control registers unconditionally commit 7c838e2a9be5ab79b11c7f1520813bfdf0f45462 upstream. Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in DP_EDP_CONFIGURATION_CAP should be set if the eDP display control registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we check the bit before reading the registers, and DP_EDP_DPCD_REV is the only way to detect eDP revision. Turns out there are (likely buggy) displays that require eDP 1.4+ features, such as supported link rates and link rate select, but do not have the bit set. Read the display control registers unconditionally. They are supposed to read zero anyway if they are not supported, so there should be no harm in this. This fixes the referenced bug by enabling the eDP version check, and thus reading of the supported link rates. The panel in question has 0 in DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the supported link rates method we default to RBR which is insufficient for the panel native mode. As a curiosity, the panel also has a bogus value of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14 (which is 0x03). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400 Reported-and-tested-by: Nicolas P. Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20171026142932.17737-1-jani.nikula@intel.com (cherry picked from commit 0501a3b0eb01ac2209ef6fce76153e5d6b07034e) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit b2f619861327dc3332df750b4983e100448e7539 Author: Maarten Lankhorst Date: Thu Oct 19 17:13:40 2017 +0200 drm/i915: Do not rely on wm preservation for ILK watermarks commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 upstream. The original intent was to preserve watermarks as much as possible in intel_pipe_wm.raw_wm, and put the validated ones in intel_pipe_wm.wm. It seems this approach is insufficient and we don't always preserve the raw watermarks, so just use the atomic iterator we're already using to get a const pointer to all bound planes on the crtc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 Signed-off-by: Maarten Lankhorst Acked-by: Ville Syrjälä Reviewed-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-1-maarten.lankhorst@linux.intel.com (cherry picked from commit 28283f4f359cd7cfa9e65457bb98c507a2cd0cd0) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit d549cb65b7982ddec3ef17d398e7d893a9d3705f Author: Huang Ying Date: Thu Nov 2 15:59:50 2017 -0700 mm, swap: fix race between swap count continuation operations commit 2628bd6fc052bd85e9864dae4de494d8a6313391 upstream. One page may store a set of entries of the sis->swap_map (swap_info_struct->swap_map) in multiple swap clusters. If some of the entries has sis->swap_map[offset] > SWAP_MAP_MAX, multiple pages will be used to store the set of entries of the sis->swap_map. And the pages are linked with page->lru. This is called swap count continuation. To access the pages which store the set of entries of the sis->swap_map simultaneously, previously, sis->lock is used. But to improve the scalability of __swap_duplicate(), swap cluster lock may be used in swap_count_continued() now. This may race with add_swap_count_continuation() which operates on a nearby swap cluster, in which the sis->swap_map entries are stored in the same page. The race can cause wrong swap count in practice, thus cause unfreeable swap entries or software lockup, etc. To fix the race, a new spin lock called cont_lock is added to struct swap_info_struct to protect the swap count continuation page list. This is a lock at the swap device level, so the scalability isn't very well. But it is still much better than the original sis->lock, because it is only acquired/released when swap count continuation is used. Which is considered rare in practice. If it turns out that the scalability becomes an issue for some workloads, we can split the lock into some more fine grained locks. Link: http://lkml.kernel.org/r/20171017081320.28133-1-ying.huang@intel.com Fixes: 235b62176712 ("mm/swap: add cluster lock") Signed-off-by: "Huang, Ying" Cc: Johannes Weiner Cc: Shaohua Li Cc: Tim Chen Cc: Michal Hocko Cc: Aaron Lu Cc: Dave Hansen Cc: Andi Kleen Cc: Minchan Kim Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8cc334b76a24231c2a76d58cb1c9f3889315c009 Author: Mike Kravetz Date: Thu Nov 2 15:59:41 2017 -0700 fs/hugetlbfs/inode.c: fix hwpoison reserve accounting commit ab615a5b879292e83653be60aa82113f7c6f462d upstream. Calling madvise(MADV_HWPOISON) on a hugetlbfs page will result in bad (negative) reserved huge page counts. This may not happen immediately, but may happen later when the underlying file is removed or filesystem unmounted. For example: AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 1 HugePages_Free: 0 HugePages_Rsvd: 18446744073709551615 HugePages_Surp: 0 Hugepagesize: 2048 kB In routine hugetlbfs_error_remove_page(), hugetlb_fix_reserve_counts is called after remove_huge_page. hugetlb_fix_reserve_counts is designed to only be called/used only if a failure is returned from hugetlb_unreserve_pages. Therefore, call hugetlb_unreserve_pages as required and only call hugetlb_fix_reserve_counts in the unlikely event that hugetlb_unreserve_pages returns an error. Link: http://lkml.kernel.org/r/20171019230007.17043-2-mike.kravetz@oracle.com Fixes: 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory error") Signed-off-by: Mike Kravetz Acked-by: Naoya Horiguchi Cc: Michal Hocko Cc: Aneesh Kumar Cc: Anshuman Khandual Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 90d3078dfd76a872d96a555c846fe588f596bdb8 Author: Ashish Samant Date: Thu Nov 2 15:59:37 2017 -0700 ocfs2: fstrim: Fix start offset of first cluster group during fstrim commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream. The first cluster group descriptor is not stored at the start of the group but at an offset from the start. We need to take this into account while doing fstrim on the first cluster group. Otherwise we will wrongly start fstrim a few blocks after the desired start block and the range can cross over into the next cluster group and zero out the group descriptor there. This can cause filesytem corruption that cannot be fixed by fsck. Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com Signed-off-by: Ashish Samant Reviewed-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c14ee6986103f9232c99de035a996547faba6371 Author: Andrea Arcangeli Date: Thu Nov 2 15:59:29 2017 -0700 userfaultfd: hugetlbfs: prevent UFFDIO_COPY to fill beyond the end of i_size commit 1e3921471354244f70fe268586ff94a97a6dd4df upstream. This oops: kernel BUG at fs/hugetlbfs/inode.c:484! RIP: remove_inode_hugepages+0x3d0/0x410 Call Trace: hugetlbfs_setattr+0xd9/0x130 notify_change+0x292/0x410 do_truncate+0x65/0xa0 do_sys_ftruncate.constprop.3+0x11a/0x180 SyS_ftruncate+0xe/0x10 tracesys+0xd9/0xde was caused by the lack of i_size check in hugetlb_mcopy_atomic_pte. mmap() can still succeed beyond the end of the i_size after vmtruncate zapped vmas in those ranges, but the faults must not succeed, and that includes UFFDIO_COPY. We could differentiate the retval to userland to represent a SIGBUS like a page fault would do (vs SIGSEGV), but it doesn't seem very useful and we'd need to pick a random retval as there's no meaningful syscall retval that would differentiate from SIGSEGV and SIGBUS, there's just -EFAULT. Link: http://lkml.kernel.org/r/20171016223914.2421-2-aarcange@redhat.com Signed-off-by: Andrea Arcangeli Reviewed-by: Mike Kravetz Cc: Mike Rapoport Cc: "Dr. David Alan Gilbert" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3434b0117daee0715869f14820055fd3049d0d8b Author: Leo Liu Date: Tue Oct 31 21:12:35 2017 -0400 drm/amdgpu: allow harvesting check for Polaris VCE commit 32bec2afa525149288e6696079bc85f747fa2138 upstream. Fixes init failures on Polaris cards with harvested VCE blocks. Signed-off-by: Leo Liu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 54321757bf833ff26ead68c62871c9b44f8efa5b Author: Leo Liu Date: Tue Oct 31 21:03:39 2017 -0400 drm/amdgpu: return -ENOENT from uvd 6.0 early init for harvesting commit cb4b02d7cac56a69d8137d8d843507cca9182aed upstream. Fixes init failures on polaris cards with harvested UVD. Signed-off-by: Leo Liu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 85fc63d11ba390797df9a0a52c0964c4328b3b3e Author: Arnd Bergmann Date: Fri Oct 20 21:17:05 2017 +0100 ARM: 8715/1: add a private asm/unaligned.h commit 1cce91dfc8f7990ca3aea896bfb148f240b12860 upstream. The asm-generic/unaligned.h header provides two different implementations for accessing unaligned variables: the access_ok.h version used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers are in fact aligned, while the le_struct.h version convinces gcc that the alignment of a pointer is '1', to make it issue the correct load/store instructions depending on the architecture flags. On ARMv5 and older, we always use the second version, to let the compiler use byte accesses. On ARMv6 and newer, we currently use the access_ok.h version, so the compiler can use any instruction including stm/ldm and ldrd/strd that will cause an alignment trap. This trap can significantly impact performance when we have to do a lot of fixups and, worse, has led to crashes in the LZ4 decompressor code that does not have a trap handler. This adds an ARM specific version of asm/unaligned.h that uses the le_struct.h/be_struct.h implementation unconditionally. This should lead to essentially the same code on ARMv6+ as before, with the exception of using regular load/store instructions instead of the trapping instructions multi-register variants. The crash in the LZ4 decompressor code was probably introduced by the patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update LZ4 compressor module"), so linux-4.11 and higher would be affected most. However, we probably want to have this backported to all older stable kernels as well, to help with the performance issues. There are two follow-ups that I think we should also work on, but not backport to stable kernels, first to change the asm-generic version of the header to remove the ARM special case, and second to review all other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they might be affected by the same problem on ARM. Signed-off-by: Arnd Bergmann Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 1ac353495acd90072a9e33f38fafb5cf07390593 Author: Yan Markman Date: Sun Oct 16 00:22:32 2016 +0300 ARM: dts: mvebu: pl310-cache disable double-linefill commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream. Under heavy system stress mvebu SoC using Cortex A9 sporadically encountered instability issues. The "double linefill" feature of L2 cache was identified as causing dependency between read and write which lead to the deadlock. Especially, it was the cause of deadlock seen under heavy PCIe traffic, as this dependency violates PCIE overtaking rule. Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration") Signed-off-by: Yan Markman Signed-off-by: Igal Liberman Signed-off-by: Nadav Haklai [gregory.clement@free-electrons.com: reformulate commit log, add Armada 375 and add Fixes tag] Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 7a598f936b4b748ab1287c5d76ae203153ff5bd6 Author: Julien Thierry Date: Fri Oct 20 12:34:17 2017 +0100 arm/arm64: kvm: Disable branch profiling in HYP code commit f9b269f3098121b5d54aaf822e0898c8ed1d3fec upstream. When HYP code runs into branch profiling code, it attempts to jump to unmapped memory, causing a HYP Panic. Disable the branch profiling for code designed to run at HYP mode. Signed-off-by: Julien Thierry Acked-by: Marc Zyngier Cc: Christoffer Dall Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit f82ec727d7f29868c69bb382024f6c6bb31dcbbd Author: Dongjiu Geng Date: Tue Oct 17 22:23:49 2017 +0800 arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort commit fd6c8c206fc5d0717b0433b191de0715122f33bb upstream. When a exception is trapped to EL2, hardware uses ELR_ELx to hold the current fault instruction address. If KVM wants to inject a abort to 32 bit guest, it needs to set the LR register for the guest to emulate this abort happened in the guest. Because ARM32 architecture is pipelined execution, so the LR value has an offset to the fault instruction address. The offsets applied to Link value for exceptions as shown below, which should be added for the ARM32 link register(LR). Table taken from ARMv8 ARM DDI0487B-B, table G1-10: Exception Offset, for PE state of: A32 T32 Undefined Instruction +4 +2 Prefetch Abort +4 +4 Data Abort +8 +8 IRQ or FIQ +4 +4 [ Removed unused variables in inject_abt to avoid compile warnings. -- Christoffer ] Signed-off-by: Dongjiu Geng Tested-by: Haibin Zhang Reviewed-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit d5ccf4125420a4b1d36f2ff4f0554ae75827db16 Author: Christoffer Dall Date: Fri Oct 13 11:40:11 2017 +0200 KVM: arm64: its: Fix missing dynamic allocation check in scan_its_table commit 8c1a8a32438b95792bbd8719d1cd4fe36e9eba03 upstream. We currently allocate an entry dynamically, but we never check if the allocation actually succeeded. We actually don't need a dynamic allocation, because we know the maximum size of an ITS table entry, so we can simply use an allocation on the stack. Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit eafa1e5b1dd5f09fd99aba2a5af00282fad6e089 Author: Mark Rutland Date: Thu Nov 2 16:12:03 2017 +0000 arm64: ensure __dump_instr() checks addr_limit commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream. It's possible for a user to deliberately trigger __dump_instr with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. Where we use __dump_instr() on kernel text, we already switch to KERNEL_DS, so this shouldn't adversely affect those cases. Fixes: 60ffc30d5652810d ("arm64: Exception handling") Acked-by: Will Deacon Signed-off-by: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f2f9b8ff24cf2d1fa2640f273b9a9592005b01f0 Author: Bart Van Assche Date: Fri Oct 27 08:23:21 2017 -0600 virtio_blk: Fix an SG_IO regression commit efea2abcb03215f2efadfe994ff7f652aaff196b upstream. Avoid that submitting an SG_IO ioctl triggers a kernel oops that is preceded by: usercopy: kernel memory overwrite attempt detected to (null) () (6 bytes) kernel BUG at mm/usercopy.c:72! Reported-by: Dann Frazier Fixes: commit ca18d6f769d2 ("block: Make most scsi_req_init() calls implicit") Signed-off-by: Bart Van Assche Cc: Michael S. Tsirkin Cc: Dann Frazier Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman Moved virtblk_initialize_rq() inside CONFIG_VIRTIO_BLK_SCSI. Signed-off-by: Jens Axboe commit 38f0712c10f1fd2318bf96306c7cebbb6cf4467b Author: Ricard Wanderlof Date: Thu Sep 7 15:31:38 2017 +0200 ASoC: adau17x1: Workaround for noise bug in ADC commit 1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 upstream. The ADC in the ADAU1361 (and possibly other Analog Devices codecs) exhibits a cyclic variation in the noise floor (in our test setup between -87 and -93 dB), a new value being attained within this range whenever a new capture stream is started. The cycle repeats after about 10 or 11 restarts. The workaround recommended by the manufacturer is to toggle the ADOSR bit in the Converter Control 0 register each time a new capture stream is started. I have verified that the patch fixes this problem on the ADAU1361, and according to the manufacturer toggling the bit in question in this manner will at least have no detrimental effect on other chips served by this driver. Signed-off-by: Ricard Wanderlof Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5148d5b12d2aa505dd622b79caae40b8886adaab Author: Eric Biggers Date: Thu Nov 2 00:47:19 2017 +0000 KEYS: fix out-of-bounds read during ASN.1 parsing commit 2eb9eabf1e868fda15808954fb29b0f105ed65f1 upstream. syzkaller with KASAN reported an out-of-bounds read in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y: keyctl add asymmetric desc $'\x30\x30' @s The bug is that the length of an ASN.1 data value isn't validated in the case where it is encoded using the short form, causing the decoder to read past the end of the input buffer. Fix it by validating the length. The bug report was: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233 Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818 CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447d983 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xb3/0x10b lib/dump_stack.c:52 print_address_description+0x79/0x2a0 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x236/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427 asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233 x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89 x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174 asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388 key_create_or_update+0x347/0xb20 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x447c89 RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89 RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5 RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000 R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 83e9bfea12107b2b8d4838b37b31d5061c549aca Author: Eric Biggers Date: Thu Nov 2 00:47:12 2017 +0000 KEYS: trusted: fix writing past end of buffer in trusted_read() commit a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream. When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Reported-by: Ben Hutchings Signed-off-by: Eric Biggers Signed-off-by: David Howells Reviewed-by: Mimi Zohar Reviewed-by: James Morris Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 4988317d1fc062e2b75195a25c24352b2f6e59ee Author: Eric Biggers Date: Thu Nov 2 00:47:03 2017 +0000 KEYS: return full count in keyring_read() if buffer is too small commit 3239b6f29bdfb4b0a2ba59df995fc9e6f4df7f1f upstream. Commit e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()") made keyring_read() stop corrupting userspace memory when the user-supplied buffer is too small. However it also made the return value in that case be the short buffer size rather than the size required, yet keyctl_read() is actually documented to return the size required. Therefore, switch it over to the documented behavior. Note that for now we continue to have it fill the short buffer, since it did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably relies on it. Fixes: e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()") Reported-by: Ben Hutchings Signed-off-by: Eric Biggers Signed-off-by: David Howells Reviewed-by: James Morris Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 7d64e01cf2b626a76c4c465fc64f1107dded8441 Author: Ronnie Sahlberg Date: Mon Oct 30 13:28:03 2017 +1100 cifs: check MaxPathNameComponentLength != 0 before using it commit f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 upstream. And fix tcon leak in error path. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Reviewed-by: David Disseldorp Signed-off-by: Greg Kroah-Hartman commit 75b5bdbeb2a7093cd131818d5d4b39349f11b124 Author: Takashi Iwai Date: Sun Oct 29 11:10:43 2017 +0100 ALSA: seq: Fix nested rwsem annotation for lockdep splat commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream. syzkaller reported the lockdep splat due to the possible deadlock of grp->list_mutex of each sequencer client object. Actually this is rather a false-positive report due to the missing nested lock annotations. The sequencer client may deliver the event directly to another client which takes another own lock. For addressing this issue, this patch replaces the simple down_read() with down_read_nested(). As a lock subclass, the already existing "hop" can be re-used, which indicates the depth of the call. Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com Reported-by: syzbot Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7fcb232d281879dd3d76d4cfb521d3216d848865 Author: Takashi Iwai Date: Sun Oct 29 11:02:04 2017 +0100 ALSA: timer: Add missing mutex lock for compat ioctls commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream. The races among ioctl and other operations were protected by the commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and later fixes, but one code path was forgotten in the scenario: the 32bit compat ioctl. As syzkaller recently spotted, a very similar use-after-free may happen with the combination of compat ioctls. The fix is simply to apply the same ioctl_lock to the compat_ioctl callback, too. Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls") Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com Reported-by: syzbot Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman