aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-19Merge branch 'for-linus' of ↵Linus Torvalds5-8/+50
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input updates from Dmitry Torokhov: - several new key mappings for HID - a host of new ACPI IDs used to identify Elan touchpads in Lenovo laptops * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ HID: input: add mapping for "Toggle Display" key HID: input: add mapping for "Full Screen" key HID: input: add mapping for keyboard Brightness Up/Down/Toggle keys HID: input: add mapping for Expose/Overview key HID: input: fix mapping of aspect ratio key [media] doc-rst: switch to new names for Full Screen/Aspect keys Input: document meanings of KEY_SCREEN and KEY_ZOOM Input: elan_i2c - add hardware ID for multiple Lenovo laptops
2019-04-19x86/cpu/intel: Lower the "ENERGY_PERF_BIAS: Set to normal" message's log ↵Hans de Goede1-2/+2
priority The "ENERGY_PERF_BIAS: Set to 'normal', was 'performance'" message triggers on pretty much every Intel machine. The purpose of log messages with a warning level is to notify the user of something which potentially is a problem, or at least somewhat unexpected. This message clearly does not match those criteria, so lower its log priority from warning to info. Signed-off-by: Hans de Goede <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-04-19Merge tag 'perf-urgent-for-mingo-5.1-20190419' of ↵Ingo Molnar6-11/+37
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: perf top: Jiri Olsa: - Fix 'perf top --pid', it needs PERF_SAMPLE_TIME since we switched to using a different thread to sort the events and then even for just a single thread we now need timestamps. BPF: Jiri Olsa: - Fix bpf_prog and btf lookup functions failure path to to properly return NULL. - Fix side band thread draining, used to process PERF_RECORD_BPF_EVENT metadata records. core: Jiri Olsa: - Fix map lookup by name to get a refcount when the name is already in the tree. Found Song Liu: - Fix __map__is_kmodule() by taking into account recently added BPF maps. UAPI: Arnaldo Carvalho de Melo: - Sync sound/asound.h copy Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2019-04-19coredump: fix race condition between mmget_not_zero()/get_task_mm() and core ↵Andrea Arcangeli5-1/+57
dumping The core dumping code has always run without holding the mmap_sem for writing, despite that is the only way to ensure that the entire vma layout will not change from under it. Only using some signal serialization on the processes belonging to the mm is not nearly enough. This was pointed out earlier. For example in Hugh's post from Jul 2017: https://lkml.kernel.org/r/[email protected] "Not strictly relevant here, but a related note: I was very surprised to discover, only quite recently, how handle_mm_fault() may be called without down_read(mmap_sem) - when core dumping. That seems a misguided optimization to me, which would also be nice to correct" In particular because the growsdown and growsup can move the vm_start/vm_end the various loops the core dump does around the vma will not be consistent if page faults can happen concurrently. Pretty much all users calling mmget_not_zero()/get_task_mm() and then taking the mmap_sem had the potential to introduce unexpected side effects in the core dumping code. Adding mmap_sem for writing around the ->core_dump invocation is a viable long term fix, but it requires removing all copy user and page faults and to replace them with get_dump_page() for all binary formats which is not suitable as a short term fix. For the time being this solution manually covers the places that can confuse the core dump either by altering the vma layout or the vma flags while it runs. Once ->core_dump runs under mmap_sem for writing the function mmget_still_valid() can be dropped. Allowing mmap_sem protected sections to run in parallel with the coredump provides some minor parallelism advantage to the swapoff code (which seems to be safe enough by never mangling any vma field and can keep doing swapins in parallel to the core dumping) and to some other corner case. In order to facilitate the backporting I added "Fixes: 86039bd3b4e6" however the side effect of this same race condition in /proc/pid/mem should be reproducible since before 2.6.12-rc2 so I couldn't add any other "Fixes:" because there's no hash beyond the git genesis commit. Because find_extend_vma() is the only location outside of the process context that could modify the "mm" structures under mmap_sem for reading, by adding the mmget_still_valid() check to it, all other cases that take the mmap_sem for reading don't need the new check after mmget_not_zero()/get_task_mm(). The expand_stack() in page fault context also doesn't need the new check, because all tasks under core dumping are frozen. Link: http://lkml.kernel.org/r/[email protected] Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by: Andrea Arcangeli <[email protected]> Reported-by: Jann Horn <[email protected]> Suggested-by: Oleg Nesterov <[email protected]> Acked-by: Peter Xu <[email protected]> Reviewed-by: Mike Rapoport <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Reviewed-by: Jann Horn <[email protected]> Acked-by: Jason Gunthorpe <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm/kmemleak.c: fix unused-function warningArnd Bergmann1-0/+2
The only references outside of the #ifdef have been removed, so now we get a warning in non-SMP configurations: mm/kmemleak.c:1404:13: error: unused function 'scan_large_block' [-Werror,-Wunused-function] Add a new #ifdef around it. Link: http://lkml.kernel.org/r/[email protected] Fixes: 298a32b13208 ("kmemleak: powerpc: skip scanning holes in the .bss section") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: Vincent Whitchurch <[email protected]> Cc: Michael Ellerman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19init: initialize jump labels before command line option parsingDan Williams1-2/+2
When a module option, or core kernel argument, toggles a static-key it requires jump labels to be initialized early. While x86, PowerPC, and ARM64 arrange for jump_label_init() to be called before parse_args(), ARM does not. Kernel command line: rdinit=/sbin/init page_alloc.shuffle=1 panic=-1 console=ttyAMA0,115200 page_alloc.shuffle=1 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:303 page_alloc_shuffle+0x12c/0x1ac static_key_enable(): static key 'page_alloc_shuffle_key+0x0/0x4' used before call to jump_label_init() Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-next-20190410-00003-g3367c36ce744 #1 Hardware name: ARM Integrator/CP (Device Tree) [<c0011c68>] (unwind_backtrace) from [<c000ec48>] (show_stack+0x10/0x18) [<c000ec48>] (show_stack) from [<c07e9710>] (dump_stack+0x18/0x24) [<c07e9710>] (dump_stack) from [<c001bb1c>] (__warn+0xe0/0x108) [<c001bb1c>] (__warn) from [<c001bb88>] (warn_slowpath_fmt+0x44/0x6c) [<c001bb88>] (warn_slowpath_fmt) from [<c0b0c4a8>] (page_alloc_shuffle+0x12c/0x1ac) [<c0b0c4a8>] (page_alloc_shuffle) from [<c0b0c550>] (shuffle_store+0x28/0x48) [<c0b0c550>] (shuffle_store) from [<c003e6a0>] (parse_args+0x1f4/0x350) [<c003e6a0>] (parse_args) from [<c0ac3c00>] (start_kernel+0x1c0/0x488) Move the fallback call to jump_label_init() to occur before parse_args(). The redundant calls to jump_label_init() in other archs are left intact in case they have static key toggling use cases that are even earlier than option parsing. Link: http://lkml.kernel.org/r/155544804466.1032396.13418949511615676665.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <[email protected]> Reported-by: Guenter Roeck <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19kernel/watchdog_hld.c: hard lockup message should end with a newlineSergey Senozhatsky1-1/+2
Separate print_modules() and hard lockup error message. Before the patch: NMI watchdog: Watchdog detected hard LOCKUP on cpu 1Modules linked in: nls_cp437 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Sergey Senozhatsky <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19kcov: improve CONFIG_ARCH_HAS_KCOV help textMark Rutland1-3/+3
The help text for CONFIG_ARCH_HAS_KCOV is stale, and describes the feature as being enabled only for x86_64, when it is now enabled for several architectures, including arm, arm64, powerpc, and s390. Let's remove that stale help text, and update it along the lines of hat for ARCH_HAS_FORTIFY_SOURCE, better describing when an architecture should select CONFIG_ARCH_HAS_KCOV. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mark Rutland <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm: fix inactive list balancing between NUMA nodes and cgroupsJohannes Weiner1-20/+9
During !CONFIG_CGROUP reclaim, we expand the inactive list size if it's thrashing on the node that is about to be reclaimed. But when cgroups are enabled, we suddenly ignore the node scope and use the cgroup scope only. The result is that pressure bleeds between NUMA nodes depending on whether cgroups are merely compiled into Linux. This behavioral difference is unexpected and undesirable. When the refault adaptivity of the inactive list was first introduced, there were no statistics at the lruvec level - the intersection of node and memcg - so it was better than nothing. But now that we have that infrastructure, use lruvec_page_state() to make the list balancing decision always NUMA aware. [[email protected]: fix bisection hole] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Fixes: 2a2e48854d70 ("mm: vmscan: fix IO/refault regression in cache workingset transition") Signed-off-by: Johannes Weiner <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm/hotplug: treat CMA pages as unmovableQian Cai1-12/+18
has_unmovable_pages() is used by allocating CMA and gigantic pages as well as the memory hotplug. The later doesn't know how to offline CMA pool properly now, but if an unused (free) CMA page is encountered, then has_unmovable_pages() happily considers it as a free memory and propagates this up the call chain. Memory offlining code then frees the page without a proper CMA tear down which leads to an accounting issues. Moreover if the same memory range is onlined again then the memory never gets back to the CMA pool. State after memory offline: # grep cma /proc/vmstat nr_free_cma 205824 # cat /sys/kernel/debug/cma/cma-kvm_cma/count 209920 Also, kmemleak still think those memory address are reserved below but have already been used by the buddy allocator after onlining. This patch fixes the situation by treating CMA pageblocks as unmovable except when has_unmovable_pages() is called as part of CMA allocation. Offlined Pages 4096 kmemleak: Cannot insert 0xc000201f7d040008 into the object search tree (overlaps existing) Call Trace: dump_stack+0xb0/0xf4 (unreliable) create_object+0x344/0x380 __kmalloc_node+0x3ec/0x860 kvmalloc_node+0x58/0x110 seq_read+0x41c/0x620 __vfs_read+0x3c/0x70 vfs_read+0xbc/0x1a0 ksys_read+0x7c/0x140 system_call+0x5c/0x70 kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xc000201cc8000000 (size 13757317120): kmemleak: comm "swapper/0", pid 0, jiffies 4294937297 kmemleak: min_count = -1 kmemleak: count = 0 kmemleak: flags = 0x5 kmemleak: checksum = 0 kmemleak: backtrace: cma_declare_contiguous+0x2a4/0x3b0 kvm_cma_reserve+0x11c/0x134 setup_arch+0x300/0x3f8 start_kernel+0x9c/0x6e8 start_here_common+0x1c/0x4b0 kmemleak: Automatic memory scanning thread ended [[email protected]: use is_migrate_cma_page() and update commit log] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Qian Cai <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19proc: fixup proc-pid-vm testAlexey Dobriyan1-2/+2
Silly sizeof(pointer) vs sizeof(uint8_t[]) bug. Link: http://lkml.kernel.org/r/20190414123009.GA12971@avx2 Fixes: e483b0208784 ("proc: test /proc/*/maps, smaps, smaps_rollup, statm") Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19proc: fix map_files test on F29Alexey Dobriyan1-10/+10
F29 bans mapping first 64KB even for root making test fail. Iterate from address 0 until mmap() works. Gentoo (root): openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3 mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0 Gentoo (non-root): openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3 mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EPERM (Operation not permitted) mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x1000 F29 (root): openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3 mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x2000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x3000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x4000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x5000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x6000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x7000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x8000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x9000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0xa000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0xb000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0xc000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0xd000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0xe000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0xf000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied) mmap(0x10000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x10000 Now all proc tests succeed on F29 if run as root, at last! Link: http://lkml.kernel.org/r/20190414123612.GB12971@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm/vmstat.c: fix /proc/vmstat format for CONFIG_DEBUG_TLBFLUSH=y CONFIG_SMP=nKonstantin Khlebnikov1-5/+0
Commit 58bc4c34d249 ("mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly") depends on skipping vmstat entries with empty name introduced in 7aaf77272358 ("mm: don't show nr_indirectly_reclaimable in /proc/vmstat") but reverted in b29940c1abd7 ("mm: rename and change semantics of nr_indirectly_reclaimable_bytes"). So skipping no longer works and /proc/vmstat has misformatted lines " 0". This patch simply shows debug counters "nr_tlb_remote_*" for UP. Link: http://lkml.kernel.org/r/155481488468.467.4295519102880913454.stgit@buzz Fixes: 58bc4c34d249 ("mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly") Signed-off-by: Konstantin Khlebnikov <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Jann Horn <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm/memory_hotplug: do not unlock after failing to take the device_hotplug_lockzhong jiang1-1/+1
When adding memory by probing a memory block in the sysfs interface, there is an obvious issue where we will unlock the device_hotplug_lock when we failed to takes it. That issue was introduced in 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock"). We should drop out in time when failing to take the device_hotplug_lock. Link: http://lkml.kernel.org/r/[email protected] Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock") Signed-off-by: zhong jiang <[email protected]> Reported-by: Yang yingliang <[email protected]> Acked-by: Michal Hocko <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm: swapoff: shmem_unuse() stop eviction without igrab()Hugh Dickins3-28/+24
The igrab() in shmem_unuse() looks good, but we forgot that it gives no protection against concurrent unmounting: a point made by Konstantin Khlebnikov eight years ago, and then fixed in 2.6.39 by 778dd893ae78 ("tmpfs: fix race between umount and swapoff"). The current 5.1-rc swapoff is liable to hit "VFS: Busy inodes after unmount of tmpfs. Self-destruct in 5 seconds. Have a nice day..." followed by GPF. Once again, give up on using igrab(); but don't go back to making such heavy-handed use of shmem_swaplist_mutex as last time: that would spoil the new design, and I expect could deadlock inside shmem_swapin_page(). Instead, shmem_unuse() just raise a "stop_eviction" count in the shmem- specific inode, and shmem_evict_inode() wait for that to go down to 0. Call it "stop_eviction" rather than "swapoff_busy" because it can be put to use for others later (huge tmpfs patches expect to use it). That simplifies shmem_unuse(), protecting it from both unlink and unmount; and in practice lets it locate all the swap in its first try. But do not rely on that: there's still a theoretical case, when shmem_writepage() might have been preempted after its get_swap_page(), before making the swap entry visible to swapoff. [[email protected]: remove incorrect list_del()] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity") Signed-off-by: Hugh Dickins <[email protected]> Cc: "Alex Xu (Hello71)" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Kelley Nielsen <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Vineeth Pillai <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm: swapoff: take notice of completion soonerHugh Dickins1-8/+11
The old try_to_unuse() implementation was driven by find_next_to_unuse(), which terminated as soon as all the swap had been freed. Add inuse_pages checks now (alongside signal_pending()) to stop scanning mms and swap_map once finished. The same ought to be done in shmem_unuse() too, but never was before, and needs a different interface: so leave it as is for now. Link: http://lkml.kernel.org/r/[email protected] Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity") Signed-off-by: Hugh Dickins <[email protected]> Cc: "Alex Xu (Hello71)" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Kelley Nielsen <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Vineeth Pillai <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm: swapoff: remove too limiting SWAP_UNUSE_MAX_TRIESHugh Dickins1-8/+8
SWAP_UNUSE_MAX_TRIES 3 appeared to work well in earlier testing, but further testing has proved it to be a source of unnecessary swapoff EBUSY failures (which can then be followed by unmount EBUSY failures). When mmget_not_zero() or shmem's igrab() fails, there is an mm exiting or inode being evicted, freeing up swap independent of try_to_unuse(). Those typically completed much sooner than the old quadratic swapoff, but now it's more common that swapoff may need to wait for them. It's possible to move those cases from init_mm.mmlist and shmem_swaplist to separate "exiting" swaplists, and try_to_unuse() then wait for those lists to be emptied; but we've not bothered with that in the past, and don't want to risk missing some other forgotten case. So just revert to cycling around until the swap is gone, without any retries limit. Link: http://lkml.kernel.org/r/[email protected] Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity") Signed-off-by: Hugh Dickins <[email protected]> Cc: "Alex Xu (Hello71)" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Kelley Nielsen <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Vineeth Pillai <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19mm: swapoff: shmem_find_swap_entries() filter out other typesHugh Dickins1-9/+9
Swapfile "type" was passed all the way down to shmem_unuse_inode(), but then forgotten from shmem_find_swap_entries(): with the result that removing one swapfile would try to free up all the swap from shmem - no problem when only one swapfile anyway, but counter-productive when more, causing swapoff to be unnecessarily OOM-killed when it should succeed. Link: http://lkml.kernel.org/r/[email protected] Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity") Signed-off-by: Hugh Dickins <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: "Alex Xu (Hello71)" <[email protected]> Cc: Vineeth Pillai <[email protected]> Cc: Kelley Nielsen <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Huang Ying <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19slab: store tagged freelist for off-slab slabmgmtQian Cai1-1/+0
Commit 51dedad06b5f ("kasan, slab: make freelist stored without tags") calls kasan_reset_tag() for off-slab slab management object leading to freelist being stored non-tagged. However, cache_grow_begin() calls alloc_slabmgmt() which calls kmem_cache_alloc_node() assigns a tag for the address and stores it in the shadow address. As the result, it causes endless errors below during boot due to drain_freelist() -> slab_destroy() -> kasan_slab_free() which compares already untagged freelist against the stored tag in the shadow address. Since off-slab slab management object freelist is such a special case, just store it tagged. Non-off-slab management object freelist is still stored untagged which has not been assigned a tag and should not cause any other troubles with this inconsistency. BUG: KASAN: double-free or invalid-free in slab_destroy+0x84/0x88 Pointer tag: [ff], memory tag: [99] CPU: 0 PID: 1376 Comm: kworker/0:4 Tainted: G W 5.1.0-rc3+ #8 Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.0.6 07/10/2018 Workqueue: cgroup_destroy css_killed_work_fn Call trace: print_address_description+0x74/0x2a4 kasan_report_invalid_free+0x80/0xc0 __kasan_slab_free+0x204/0x208 kasan_slab_free+0xc/0x18 kmem_cache_free+0xe4/0x254 slab_destroy+0x84/0x88 drain_freelist+0xd0/0x104 __kmem_cache_shrink+0x1ac/0x224 __kmemcg_cache_deactivate+0x1c/0x28 memcg_deactivate_kmem_caches+0xa0/0xe8 memcg_offline_kmem+0x8c/0x3d4 mem_cgroup_css_offline+0x24c/0x290 css_killed_work_fn+0x154/0x618 process_one_work+0x9cc/0x183c worker_thread+0x9b0/0xe38 kthread+0x374/0x390 ret_from_fork+0x10/0x18 Allocated by task 1625: __kasan_kmalloc+0x168/0x240 kasan_slab_alloc+0x18/0x20 kmem_cache_alloc_node+0x1f8/0x3a0 cache_grow_begin+0x4fc/0xa24 cache_alloc_refill+0x2f8/0x3e8 kmem_cache_alloc+0x1bc/0x3bc sock_alloc_inode+0x58/0x334 alloc_inode+0xb8/0x164 new_inode_pseudo+0x20/0xec sock_alloc+0x74/0x284 __sock_create+0xb0/0x58c sock_create+0x98/0xb8 __sys_socket+0x60/0x138 __arm64_sys_socket+0xa4/0x110 el0_svc_handler+0x2c0/0x47c el0_svc+0x8/0xc Freed by task 1625: __kasan_slab_free+0x114/0x208 kasan_slab_free+0xc/0x18 kfree+0x1a8/0x1e0 single_release+0x7c/0x9c close_pdeo+0x13c/0x43c proc_reg_release+0xec/0x108 __fput+0x2f8/0x784 ____fput+0x1c/0x28 task_work_run+0xc0/0x1b0 do_notify_resume+0xb44/0x1278 work_pending+0x8/0x10 The buggy address belongs to the object at ffff809681b89e00 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 0 bytes inside of 128-byte region [ffff809681b89e00, ffff809681b89e80) The buggy address belongs to the page: page:ffff7fe025a06e00 count:1 mapcount:0 mapping:01ff80082000fb00 index:0xffff809681b8fe04 flags: 0x17ffffffc000200(slab) raw: 017ffffffc000200 ffff7fe025a06d08 ffff7fe022ef7b88 01ff80082000fb00 raw: ffff809681b8fe04 ffff809681b80000 00000001000000e0 0000000000000000 page dumped because: kasan: bad access detected page allocated via order 0, migratetype Unmovable, gfp_mask 0x2420c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_COMP|__GFP_THISNODE) prep_new_page+0x4e0/0x5e0 get_page_from_freelist+0x4ce8/0x50d4 __alloc_pages_nodemask+0x738/0x38b8 cache_grow_begin+0xd8/0xa24 ____cache_alloc_node+0x14c/0x268 __kmalloc+0x1c8/0x3fc ftrace_free_mem+0x408/0x1284 ftrace_free_init_mem+0x20/0x28 kernel_init+0x24/0x548 ret_from_fork+0x10/0x18 Memory state around the buggy address: ffff809681b89c00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ffff809681b89d00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe >ffff809681b89e00: 99 99 99 99 99 99 99 99 fe fe fe fe fe fe fe fe ^ ffff809681b89f00: 43 43 43 43 43 fe fe fe fe fe fe fe fe fe fe fe ffff809681b8a000: 6d fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe Link: http://lkml.kernel.org/r/[email protected] Fixes: 51dedad06b5f ("kasan, slab: make freelist stored without tags") Signed-off-by: Qian Cai <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-19x86/cpu/bugs: Use __initconst for 'const' init dataAndi Kleen1-3/+3
Some of the recently added const tables use __initdata which causes section attribute conflicts. Use __initconst instead. Fixes: fa1202ef2243 ("x86/speculation: Add command line control") Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-04-19staging: speakup: refactor to use existing code in vtOkash Khawaja3-126/+88
This patch replaces speakup's implementations with calls to functions in tty/vt/selection.c. Those functions are: cancel_selection() set_selection_kernel() paste_selection() Currently setting selection is done in interrupt context. However, set_selection_kernel() can sleep - for instance, it requires console_lock which can sleep. Therefore we offload that work to a work_struct thread, following the same pattern which was already set for paste_selection(). When setting selection, we also get a reference to tty and make sure to release the reference before returning. struct speakup_paste_work has been renamed to the more generic speakup_selection_work because it is now used for both pasting as well as setting selection. When paste work is cancelled, the code wasn't setting tty to NULL. This patch also fixes that by setting tty to NULL so that in case of failure we don't get EBUSY forever. Signed-off-by: Okash Khawaja <[email protected]> Reviewed-by: Samuel Thibault <[email protected]> Tested-by: Gregory Nowak <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19vt: selection: allow functions to be called from inside kernelOkash Khawaja3-22/+38
This patch breaks set_selection() into two functions so that when called from kernel, copy_from_user() can be avoided. The two functions are called set_selection_user() and set_selection_kernel() in order to be explicit about their purposes. This also means updating any references to set_selection() and fixing for name change. It also exports set_selection_kernel() and paste_selection(). These changes are used the following patch where speakup's selection functionality calls into the above functions, thereby doing away with parallel implementation. Signed-off-by: Okash Khawaja <[email protected]> Reviewed-by: Samuel Thibault <[email protected]> Tested-by: Gregory Nowak <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: greybus: power_supply: use struct_size() helperGustavo A. R. Silva1-2/+2
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace code of the following form: sizeof(*resp) + props_count * sizeof(struct gb_power_supply_props_desc) with: struct_size(resp, props, props_count) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Rui Miguel Silva <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: use help instead of ---help--- in KconfigMoses Christopher1-127/+127
- Resolve the following warning from the Kconfig, "WARNING: prefer 'help' over '---help---' for new help texts" Signed-off-by: Moses Christopher <[email protected]> Reviewed-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19Staging: rtl8723bs: Avoid typedefs for structureBhanusree Pola2-7/+7
Avoid typedefs for structure types to maintain kernel coding style. Remove typedefs for _ODM_Phy_Dbg_Info and _ODM_Mac_Status_Info_. This part is done by the following semantic patch: <smpl> @r1@ identifier i; type t; @@ typedef struct i { ... }t; @r2@ type r1.t; identifier v; @@ t v; @script:python match@ i << r1.i; x; @@ coccinelle.x = i; @r4@ identifier match.x; type r1.t; @@ - typedef struct x + struct x { ... } - t ; @r5@ type r1.t; identifier r2.v, match.x; @@ - t v; + struct x v; </smpl> Change Structure name _ODM_Phy_Dbg_Info and _ODM_Mac_Status_Info_ to maintain Linux kernel Coding Style. Replace occurences of ODM_PHY_DBG_INFO_T to odm_phy_dbg_info and ODM_MAC_INFO to odm_mac_status_info. Signed-off-by: Bhanusree Pola <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: mt7621-pci-phy: convert driver to use kernel regmap API'sSergio Paracuellos1-34/+54
Instead of using writel and readl use regmap API which makes the driver maintainability easier. Signed-off-by: Sergio Paracuellos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: mt7621-pci-phy: add quirks for 'E2' revision using ↵Sergio Paracuellos1-3/+14
'soc_device_attribute' Depending on revision of the chip, 'mt7621_bypass_pipe_rst' function must be executed. Add better support for this using 'soc_device_match' in driver probe function. Signed-off-by: Sergio Paracuellos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: mt7621-pci-phy: remove some unnecessary local variablesSergio Paracuellos1-12/+4
Device tree is not using child nodes anymore so the 'child_np' variable can safely removed. This also simplifies the error path to be able to directly return errors removing also the 'ret' variable. Signed-off-by: Sergio Paracuellos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: mt7621-pci-phy: use 'platform_get_resource'Sergio Paracuellos1-6/+5
Driver is using 'of_address_to_resource' to get memory resources. Make use of 'platform_get_resource' instead which is more accurate for a platform driver. This also makes possible to delete a local variable which is not needed anymore. Signed-off-by: Sergio Paracuellos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: rtl8723bs: fix spelling mistake: "nonprintabl" -> "non-printable"Colin Ian King1-1/+1
There is a spelling mistake in an RT_TRACE message, fix it. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: rtlwifi: fix spelling mistake "notity" -> "notify"Colin Ian King1-2/+2
There are two spelling mistake in RT_TRACE messages. Fix them. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: dt9812: Call mutex_destroy() on private mutexIan Abbott1-4/+1
`dt9812_detach()` is the Comedi "detach" handler for the dt9812 driver. When it is called, the private data for the device is about to be freed. The private data contains a mutex `devpriv->mut` that was initialized when the private data was allocated. Call `mutex_destroy()` to mark it as invalid. Also remove the calls to `mutex_lock()` and `mutex_unlock()` from `dt9812_detach()` as the mutex is only being used around a call to `usb_set_intfdata()` to clear the USB interface's driver data pointer. The mutex lock seems redundant here, especially as it is about to be destroyed. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: ni_usb6501: Call mutex_destroy() on private mutexIan Abbott1-3/+1
`ni6501_detach()` is the Comedi "detach" handler for the ni_usb6501 driver. It is called when the private data for the device is about to be freed. The private data contains a mutex `devpriv->mut` that was initialized when the private data was allocated. Call `mutex_destroy()` to mark it as invalid. Also remove the calls to `mutex_lock()` and `mutex_unlock()` from `ni6501_detach()`. The only other locks of the mutex are by some of the Comedi instruction handlers that cannot contend with the "detach" handler for this mutex. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: usbdux: Call mutex_destroy() on private mutexIan Abbott1-0/+2
`usbdux_detach()` is the Comedi "detach" handler for the usbdux driver. When it is called, the private data for the device is about to be freed. The private date contains a mutex `devpriv->mut` that was initialized when the private data was allocated. Call `mutex_destroy()` to mark it as invalid. The calls to `mutex_lock()` and `mutex_unlock()` are probably not required, especially as the mutex is about to be destroyed, but leave them alone for now. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: usbduxfast: Call mutex_destroy() on private mutexIan Abbott1-0/+2
`usbduxfast_detach()` is the Comedi "detach" handler for the usbduxfast driver. When it is called, the private data for the device is about to be freed. The private date contains a mutex `devpriv->mut` that was initialized when the private data was allocated. Call `mutex_destroy()` to mark it as invalid. The calls to `mutex_lock()` and `mutex_unlock()` in `usbduxfast_detach()` are probably not required, especially as the mutex is about to be destroyed, but leave them alone for now. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: usbduxsigma: Call mutex_destroy() on private mutexIan Abbott1-0/+2
`usbduxsigma_detach()` is the Comedi "detach" handler for the usbduxsigma driver. When it is called, the private data for the device is about to be freed. The private date contains a mutex `devpriv->mut` that was initialized when the private data was allocated. Call `mutex_destroy()` to mark it as invalid. The calls to `mutex_lock()` and `mutex_unlock()` in `usbduxsigma_detach()` are probably not required, especially as the mutex is about to be destroyed, but leave them alone for now. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: most: configfs: Make mdev_link_list staticYueHaibing1-1/+1
Fix sparse warning: drivers/staging/most/configfs.c:34:18: warning: symbol 'mdev_link_list' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: rtl8723bs: hal: fix spelling mistake "singal" -> "signal"Colin Ian King2-11/+11
There are multiple spelling mistakes in variable names, fix these. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: vc04_services: handle kzalloc failureNicholas Mc Guire2-0/+5
The kzalloc here was being used without checking the return - if the kzalloc fails return VCHIQ_ERROR. The call-site of vchiq_platform_init_state() vchiq_init_state() was not responding to an allocation failure so checks for != VCHIQ_SUCCESS and pass VCHIQ_ERROR up to vchiq_platform_init() which then will fail with -EINVAL. Signed-off-by: Nicholas Mc Guire <[email protected]> Reported-by: kbuild test robot <[email protected]> Acked-By: Stefan Wahren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: Add lockdep_assert_held() calls for dev->attach_lockIan Abbott1-0/+1
There are not a lot of functions in the core comedi module that require the R/W semaphore `attach_lock` in `struct comedi_device` to be locked (although there are a few functions that require at least one of `attach_lock` and `mutex` to be locked). One function that requires the caller to lock `attach_lock` is `comedi_device_detach_cleanup()` so add a call to `lockdep_assert_held()` to check and document that. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: Add lockdep_assert_held() calls for dev->mutexIan Abbott3-0/+41
Lots of functions in the core comedi module expect the mutex in `struct comedi_device` to be held, so add calls to `lockdep_assert_held()` to check and document that. An unusual case is the calls to `lockdep_assert_held()` after successful return from `comedi_alloc_board_minor()` which allocates a `struct comedi_device` and returns with its mutex locked. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19staging: comedi: don't release mutex too early in comedi_auto_config()Ian Abbott1-1/+2
`comedi_auto_config()` uses `dev->class_dev` for logging a kernel message after releasing `dev->mutex`. There is an unlikely possibility that the Comedi device `dev` will have been removed by the `COMEDI_DEVCONFIG` ioctl() command. Keep hold of the mutex until the kernel message has been sent to prevent that. The function can call `comedi_release_hardware_device()` on error. In that case, the mutex must be unlocked before that. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-19x86/kprobes: Avoid kretprobe recursion bugMasami Hiramatsu1-2/+20
Avoid kretprobe recursion loop bg by setting a dummy kprobes to current_kprobe per-CPU variable. This bug has been introduced with the asm-coded trampoline code, since previously it used another kprobe for hooking the function return placeholder (which only has a nop) and trampoline handler was called from that kprobe. This revives the old lost kprobe again. With this fix, we don't see deadlock anymore. And you can see that all inner-called kretprobe are skipped. event_1 235 0 event_2 19375 19612 The 1st column is recorded count and the 2nd is missed count. Above shows (event_1 rec) + (event_2 rec) ~= (event_2 missed) (some difference are here because the counter is racy) Reported-by: Andrea Righi <[email protected]> Tested-by: Andrea Righi <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Acked-by: Steven Rostedt <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: c9becf58d935 ("[PATCH] kretprobe: kretprobe-booster") Link: http://lkml.kernel.org/r/155094064889.6137.972160690963039.stgit@devbox Signed-off-by: Ingo Molnar <[email protected]>
2019-04-19kprobes: Mark ftrace mcount handler functions nokprobeMasami Hiramatsu1-1/+5
Mark ftrace mcount handler functions nokprobe since probing on these functions with kretprobe pushes return address incorrectly on kretprobe shadow stack. Reported-by: Francis Deslauriers <[email protected]> Tested-by: Andrea Righi <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Acked-by: Steven Rostedt <[email protected]> Acked-by: Steven Rostedt (VMware) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/155094062044.6137.6419622920568680640.stgit@devbox Signed-off-by: Ingo Molnar <[email protected]>
2019-04-19x86/kprobes: Verify stack frame on kretprobeMasami Hiramatsu2-0/+27
Verify the stack frame pointer on kretprobe trampoline handler, If the stack frame pointer does not match, it skips the wrong entry and tries to find correct one. This can happen if user puts the kretprobe on the function which can be used in the path of ftrace user-function call. Such functions should not be probed, so this adds a warning message that reports which function should be blacklisted. Tested-by: Andrea Righi <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Acked-by: Steven Rostedt <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/155094059185.6137.15527904013362842072.stgit@devbox Signed-off-by: Ingo Molnar <[email protected]>
2019-04-19locking/atomics: Don't assume that scripts are executableAndrew Morton1-1/+1
patch(1) doesn't set the x bit on files. So if someone downloads and applies patch-4.21.xz, their kernel won't build. Fix that by executing /bin/sh. Signed-off-by: Andrew Morton <[email protected]> Acked-by: Mark Rutland <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra (Intel) <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2019-04-19sc16is7xx: put err_spi and err_i2c into correct #ifdefGuoqing Jiang1-2/+2
err_spi is only called within SERIAL_SC16IS7XX_SPI while err_i2c is called inside SERIAL_SC16IS7XX_I2C. So we need to put err_spi and err_i2c into each #ifdef accordingly. This change fixes ("sc16is7xx: move label 'err_spi' to correct section"). Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-18scsi: aic7xxx: fix EISA supportChristoph Hellwig4-6/+7
Instead of relying on the now removed NULL argument to pci_alloc_consistent, switch to the generic DMA API, and store the struct device so that we can pass it. Fixes: 4167b2ad5182 ("PCI: Remove NULL device handling from PCI DMA API") Reported-by: Matthew Whitehead <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Tested-by: Matthew Whitehead <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-18Revert "scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO"Saurav Kashyap1-1/+0
This patch clears FC_RP_STARTED flag during logoff, because of this re-login(flogi) didn't happen to the switch. This reverts commit 1550ec458e0cf1a40a170ab1f4c46e3f52860f65. Fixes: 1550ec458e0c ("scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO") Cc: <[email protected]> # v4.18+ Signed-off-by: Saurav Kashyap <[email protected]> Reviewed-by: Hannes Reinecke <hare@#suse.com> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-18Merge tag 'arm64-fixes' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Avoid compiler uninitialised warning introduced by recent arm64 futex fix" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: futex: Restore oldval initialization to work around buggy compilers