commit cdcec6869074d67b3613977517deca1da249e43a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Oct 1 17:36:35 2020 +0200

    Linux 5.8.13
    
    Tested-by: Jeffrin Jose T  <jeffrin@rajagiritech.edu.in>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20200929105929.719230296@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 510c51ff61e3313426f4103dc12766156335a8db
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Aug 17 12:24:28 2020 +0300

    clocksource/drivers/timer-ti-dm: Do reset before enable
    
    commit 164805157f3c6834670afbaff563353c773131f1 upstream.
    
    Commit 6cfcd5563b4f ("clocksource/drivers/timer-ti-dm: Fix suspend and
    resume for am3 and am4") exposed a new issue for type2 dual mode timers
    on at least omap5 where the clockevent will stop when the SoC starts
    entering idle states during the boot.
    
    Turns out we are wrongly first enabling the system timer and then
    resetting it, while we must also re-enable it after reset. The current
    sequence leaves the timer module in a partially initialized state. This
    issue went unnoticed earlier with ti-sysc driver reconfiguring the timer
    module until we fixed the issue of ti-sysc reconfiguring system timers.
    
    Let's fix the issue by calling dmtimer_systimer_enable() from reset for
    both type1 and type2 timers, and switch the order of reset and enable in
    dmtimer_systimer_setup(). Let's also move dmtimer_systimer_enable() and
    dmtimer_systimer_disable() to do this without adding forward declarations.
    
    Fixes: 6cfcd5563b4f ("clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4")
    Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20200817092428.6176-1-tony@atomide.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af56dabe31d1b880390f181a3bb8d42cf022d4a0
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Mon Sep 14 13:04:19 2020 -0400

    dm: fix bio splitting and its bio completion order for regular IO
    
    commit ee1dfad5325ff1cfb2239e564cd411b3bfe8667a upstream.
    
    dm_queue_split() is removed because __split_and_process_bio() _must_
    handle splitting bios to ensure proper bio submission and completion
    ordering as a bio is split.
    
    Otherwise, multiple recursive calls to ->submit_bio will cause multiple
    split bios to be allocated from the same ->bio_split mempool at the same
    time. This would result in deadlock in low memory conditions because no
    progress could be made (only one bio is available in ->bio_split
    mempool).
    
    This fix has been verified to still fix the loss of performance, due
    to excess splitting, that commit 120c9257f5f1 provided.
    
    Fixes: 120c9257f5f1 ("Revert "dm: always call blk_queue_split() in dm_process_bio()"")
    Cc: stable@vger.kernel.org # 5.0+, requires custom backport due to 5.9 changes
    Reported-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b76d62a9986abbc6f7e5dad658ef65ed7e8c9e6
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Sep 15 11:42:17 2020 +0100

    KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch
    
    commit c4ad98e4b72cb5be30ea282fce935248f2300e62 upstream.
    
    KVM currently assumes that an instruction abort can never be a write.
    This is in general true, except when the abort is triggered by
    a S1PTW on instruction fetch that tries to update the S1 page tables
    (to set AF, for example).
    
    This can happen if the page tables have been paged out and brought
    back in without seeing a direct write to them (they are thus marked
    read only), and the fault handling code will make the PT executable(!)
    instead of writable. The guest gets stuck forever.
    
    In these conditions, the permission fault must be considered as
    a write so that the Stage-1 update can take place. This is essentially
    the I-side equivalent of the problem fixed by 60e21a0ef54c ("arm64: KVM:
    Take S1 walks into account when determining S2 write faults").
    
    Update kvm_is_write_fault() to return true on IABT+S1PTW, and introduce
    kvm_vcpu_trap_is_exec_fault() that only return true when no faulting
    on a S1 fault. Additionally, kvm_vcpu_dabt_iss1tw() is renamed to
    kvm_vcpu_abt_iss1tw(), as the above makes it plain that it isn't
    specific to data abort.
    
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Will Deacon <will@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200915104218.1284701-2-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bd50397031b6a7bef33a071eb619dcb1b6d0a26
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Sep 24 14:55:54 2020 -0600

    io_uring: ensure open/openat2 name is cleaned on cancelation
    
    commit f3cd4850504ff612d0ea77a0aaf29b66c98fcefe upstream.
    
    If we cancel these requests, we'll leak the memory associated with the
    filename. Add them to the table of ops that need cleaning, if
    REQ_F_NEED_CLEANUP is set.
    
    Cc: stable@vger.kernel.org
    Fixes: e62753e4e292 ("io_uring: call statx directly")
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4545633b037b935cf3ae227b31102d48eebf324f
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Mon Sep 21 12:48:36 2020 +0200

    s390/zcrypt: Fix ZCRYPT_PERDEV_REQCNT ioctl
    
    commit f7e80983f0cf470bb82036e73bff4d5a7daf8fc2 upstream.
    
    reqcnt is an u32 pointer but we do copy sizeof(reqcnt) which is the
    size of the pointer. This means we only copy 8 byte. Let us copy
    the full monty.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Harald Freudenberger <freude@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Fixes: af4a72276d49 ("s390/zcrypt: Support up to 256 crypto adapters.")
    Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 862f8bb32f4ff2bfab1b45a463483d6822e6d27c
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Fri Sep 25 21:19:31 2020 -0700

    mm: don't rely on system state to detect hot-plug operations
    
    commit f85086f95fa36194eb0db5cd5c12e56801b98523 upstream.
    
    In register_mem_sect_under_node() the system_state's value is checked to
    detect whether the call is made during boot time or during an hot-plug
    operation.  Unfortunately, that check against SYSTEM_BOOTING is wrong
    because regular memory is registered at SYSTEM_SCHEDULING state.  In
    addition, memory hot-plug operation can be triggered at this system
    state by the ACPI [1].  So checking against the system state is not
    enough.
    
    The consequence is that on system with interleaved node's ranges like this:
    
     Early memory node ranges
       node   1: [mem 0x0000000000000000-0x000000011fffffff]
       node   2: [mem 0x0000000120000000-0x000000014fffffff]
       node   1: [mem 0x0000000150000000-0x00000001ffffffff]
       node   0: [mem 0x0000000200000000-0x000000048fffffff]
       node   2: [mem 0x0000000490000000-0x00000007ffffffff]
    
    This can be seen on PowerPC LPAR after multiple memory hot-plug and
    hot-unplug operations are done.  At the next reboot the node's memory
    ranges can be interleaved and since the call to link_mem_sections() is
    made in topology_init() while the system is in the SYSTEM_SCHEDULING
    state, the node's id is not checked, and the sections registered to
    multiple nodes:
    
      $ ls -l /sys/devices/system/memory/memory21/node*
      total 0
      lrwxrwxrwx 1 root root     0 Aug 24 05:27 node1 -> ../../node/node1
      lrwxrwxrwx 1 root root     0 Aug 24 05:27 node2 -> ../../node/node2
    
    In that case, the system is able to boot but if later one of theses
    memory blocks is hot-unplugged and then hot-plugged, the sysfs
    inconsistency is detected and this is triggering a BUG_ON():
    
      kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084!
      Oops: Exception in kernel mode, sig: 5 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto gf128mul binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4
      CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25
      Call Trace:
        add_memory_resource+0x23c/0x340 (unreliable)
        __add_memory+0x5c/0xf0
        dlpar_add_lmb+0x1b4/0x500
        dlpar_memory+0x1f8/0xb80
        handle_dlpar_errorlog+0xc0/0x190
        dlpar_store+0x198/0x4a0
        kobj_attr_store+0x30/0x50
        sysfs_kf_write+0x64/0x90
        kernfs_fop_write+0x1b0/0x290
        vfs_write+0xe8/0x290
        ksys_write+0xdc/0x130
        system_call_exception+0x160/0x270
        system_call_common+0xf0/0x27c
    
    This patch addresses the root cause by not relying on the system_state
    value to detect whether the call is due to a hot-plug operation.  An
    extra parameter is added to link_mem_sections() detailing whether the
    operation is due to a hot-plug operation.
    
    [1] According to Oscar Salvador, using this qemu command line, ACPI
    memory hotplug operations are raised at SYSTEM_SCHEDULING state:
    
      $QEMU -enable-kvm -machine pc -smp 4,sockets=4,cores=1,threads=1 -cpu host -monitor pty \
            -m size=$MEM,slots=255,maxmem=4294967296k  \
            -numa node,nodeid=0,cpus=0-3,mem=512 -numa node,nodeid=1,mem=512 \
            -object memory-backend-ram,id=memdimm0,size=134217728 -device pc-dimm,node=0,memdev=memdimm0,id=dimm0,slot=0 \
            -object memory-backend-ram,id=memdimm1,size=134217728 -device pc-dimm,node=0,memdev=memdimm1,id=dimm1,slot=1 \
            -object memory-backend-ram,id=memdimm2,size=134217728 -device pc-dimm,node=0,memdev=memdimm2,id=dimm2,slot=2 \
            -object memory-backend-ram,id=memdimm3,size=134217728 -device pc-dimm,node=0,memdev=memdimm3,id=dimm3,slot=3 \
            -object memory-backend-ram,id=memdimm4,size=134217728 -device pc-dimm,node=1,memdev=memdimm4,id=dimm4,slot=4 \
            -object memory-backend-ram,id=memdimm5,size=134217728 -device pc-dimm,node=1,memdev=memdimm5,id=dimm5,slot=5 \
            -object memory-backend-ram,id=memdimm6,size=134217728 -device pc-dimm,node=1,memdev=memdimm6,id=dimm6,slot=6 \
    
    Fixes: 4fbce633910e ("mm/memory_hotplug.c: make register_mem_sect_under_node() a callback of walk_memory_range()")
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Nathan Lynch <nathanl@linux.ibm.com>
    Cc: Scott Cheloha <cheloha@linux.ibm.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200915094143.79181-3-ldufour@linux.ibm.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8fdce317826fffea395bcab2dd62198e9aeae0e
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Fri Sep 25 21:19:28 2020 -0700

    mm: replace memmap_context by meminit_context
    
    commit c1d0da83358a2316d9be7f229f26126dbaa07468 upstream.
    
    Patch series "mm: fix memory to node bad links in sysfs", v3.
    
    Sometimes, firmware may expose interleaved memory layout like this:
    
     Early memory node ranges
       node   1: [mem 0x0000000000000000-0x000000011fffffff]
       node   2: [mem 0x0000000120000000-0x000000014fffffff]
       node   1: [mem 0x0000000150000000-0x00000001ffffffff]
       node   0: [mem 0x0000000200000000-0x000000048fffffff]
       node   2: [mem 0x0000000490000000-0x00000007ffffffff]
    
    In that case, we can see memory blocks assigned to multiple nodes in
    sysfs:
    
      $ ls -l /sys/devices/system/memory/memory21
      total 0
      lrwxrwxrwx 1 root root     0 Aug 24 05:27 node1 -> ../../node/node1
      lrwxrwxrwx 1 root root     0 Aug 24 05:27 node2 -> ../../node/node2
      -rw-r--r-- 1 root root 65536 Aug 24 05:27 online
      -r--r--r-- 1 root root 65536 Aug 24 05:27 phys_device
      -r--r--r-- 1 root root 65536 Aug 24 05:27 phys_index
      drwxr-xr-x 2 root root     0 Aug 24 05:27 power
      -r--r--r-- 1 root root 65536 Aug 24 05:27 removable
      -rw-r--r-- 1 root root 65536 Aug 24 05:27 state
      lrwxrwxrwx 1 root root     0 Aug 24 05:25 subsystem -> ../../../../bus/memory
      -rw-r--r-- 1 root root 65536 Aug 24 05:25 uevent
      -r--r--r-- 1 root root 65536 Aug 24 05:27 valid_zones
    
    The same applies in the node's directory with a memory21 link in both
    the node1 and node2's directory.
    
    This is wrong but doesn't prevent the system to run.  However when
    later, one of these memory blocks is hot-unplugged and then hot-plugged,
    the system is detecting an inconsistency in the sysfs layout and a
    BUG_ON() is raised:
    
      kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084!
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto gf128mul binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4
      CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25
      Call Trace:
        add_memory_resource+0x23c/0x340 (unreliable)
        __add_memory+0x5c/0xf0
        dlpar_add_lmb+0x1b4/0x500
        dlpar_memory+0x1f8/0xb80
        handle_dlpar_errorlog+0xc0/0x190
        dlpar_store+0x198/0x4a0
        kobj_attr_store+0x30/0x50
        sysfs_kf_write+0x64/0x90
        kernfs_fop_write+0x1b0/0x290
        vfs_write+0xe8/0x290
        ksys_write+0xdc/0x130
        system_call_exception+0x160/0x270
        system_call_common+0xf0/0x27c
    
    This has been seen on PowerPC LPAR.
    
    The root cause of this issue is that when node's memory is registered,
    the range used can overlap another node's range, thus the memory block
    is registered to multiple nodes in sysfs.
    
    There are two issues here:
    
     (a) The sysfs memory and node's layouts are broken due to these
         multiple links
    
     (b) The link errors in link_mem_sections() should not lead to a system
         panic.
    
    To address (a) register_mem_sect_under_node should not rely on the
    system state to detect whether the link operation is triggered by a hot
    plug operation or not.  This is addressed by the patches 1 and 2 of this
    series.
    
    Issue (b) will be addressed separately.
    
    This patch (of 2):
    
    The memmap_context enum is used to detect whether a memory operation is
    due to a hot-add operation or happening at boot time.
    
    Make it general to the hotplug operation and rename it as
    meminit_context.
    
    There is no functional change introduced by this patch
    
    Suggested-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "Rafael J . Wysocki" <rafael@kernel.org>
    Cc: Nathan Lynch <nathanl@linux.ibm.com>
    Cc: Scott Cheloha <cheloha@linux.ibm.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200915094143.79181-1-ldufour@linux.ibm.com
    Link: https://lkml.kernel.org/r/20200915132624.9723-1-ldufour@linux.ibm.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a4b8662dd4f7a0e448592753cdbb0a6e9fbf46b
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Fri Sep 25 21:19:10 2020 -0700

    mm/gup: fix gup_fast with dynamic page table folding
    
    commit d3f7b1bb204099f2f7306318896223e8599bb6a2 upstream.
    
    Currently to make sure that every page table entry is read just once
    gup_fast walks perform READ_ONCE and pass pXd value down to the next
    gup_pXd_range function by value e.g.:
    
      static int gup_pud_range(p4d_t p4d, unsigned long addr, unsigned long end,
                               unsigned int flags, struct page **pages, int *nr)
      ...
              pudp = pud_offset(&p4d, addr);
    
    This function passes a reference on that local value copy to pXd_offset,
    and might get the very same pointer in return.  This happens when the
    level is folded (on most arches), and that pointer should not be
    iterated.
    
    On s390 due to the fact that each task might have different 5,4 or
    3-level address translation and hence different levels folded the logic
    is more complex and non-iteratable pointer to a local copy leads to
    severe problems.
    
    Here is an example of what happens with gup_fast on s390, for a task
    with 3-level paging, crossing a 2 GB pud boundary:
    
      // addr = 0x1007ffff000, end = 0x10080001000
      static int gup_pud_range(p4d_t p4d, unsigned long addr, unsigned long end,
                               unsigned int flags, struct page **pages, int *nr)
      {
            unsigned long next;
            pud_t *pudp;
    
            // pud_offset returns &p4d itself (a pointer to a value on stack)
            pudp = pud_offset(&p4d, addr);
            do {
                    // on second iteratation reading "random" stack value
                    pud_t pud = READ_ONCE(*pudp);
    
                    // next = 0x10080000000, due to PUD_SIZE/MASK != PGDIR_SIZE/MASK on s390
                    next = pud_addr_end(addr, end);
                    ...
            } while (pudp++, addr = next, addr != end); // pudp++ iterating over stack
    
            return 1;
      }
    
    This happens since s390 moved to common gup code with commit
    d1874a0c2805 ("s390/mm: make the pxd_offset functions more robust") and
    commit 1a42010cdc26 ("s390/mm: convert to the generic
    get_user_pages_fast code").
    
    s390 tried to mimic static level folding by changing pXd_offset
    primitives to always calculate top level page table offset in pgd_offset
    and just return the value passed when pXd_offset has to act as folded.
    
    What is crucial for gup_fast and what has been overlooked is that
    PxD_SIZE/MASK and thus pXd_addr_end should also change correspondingly.
    And the latter is not possible with dynamic folding.
    
    To fix the issue in addition to pXd values pass original pXdp pointers
    down to gup_pXd_range functions.  And introduce pXd_offset_lockless
    helpers, which take an additional pXd entry value parameter.  This has
    already been discussed in
    
      https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1
    
    Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Cc: <stable@vger.kernel.org>    [5.2+]
    Link: https://lkml.kernel.org/r/patch.git-943f1e5dcff2.your-ad-here.call-01599856292-ext-8676@work.hours
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 488b66f91a2df4bce646ded7cbdf40c015d68b4d
Author: Gao Xiang <hsiangkao@redhat.com>
Date:   Fri Sep 25 21:19:01 2020 -0700

    mm, THP, swap: fix allocating cluster for swapfile by mistake
    
    commit 41663430588c737dd735bad5a0d1ba325dcabd59 upstream.
    
    SWP_FS is used to make swap_{read,write}page() go through the
    filesystem, and it's only used for swap files over NFS.  So, !SWP_FS
    means non NFS for now, it could be either file backed or device backed.
    Something similar goes with legacy SWP_FILE.
    
    So in order to achieve the goal of the original patch, SWP_BLKDEV should
    be used instead.
    
    FS corruption can be observed with SSD device + XFS + fragmented
    swapfile due to CONFIG_THP_SWAP=y.
    
    I reproduced the issue with the following details:
    
    Environment:
    
      QEMU + upstream kernel + buildroot + NVMe (2 GB)
    
    Kernel config:
    
      CONFIG_BLK_DEV_NVME=y
      CONFIG_THP_SWAP=y
    
    Some reproducible steps:
    
      mkfs.xfs -f /dev/nvme0n1
      mkdir /tmp/mnt
      mount /dev/nvme0n1 /tmp/mnt
      bs="32k"
      sz="1024m"    # doesn't matter too much, I also tried 16m
      xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
      xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
      xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
      xfs_io -f -c "pwrite -F -S 0 -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw
      xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fsync" /tmp/mnt/sw
    
      mkswap /tmp/mnt/sw
      swapon /tmp/mnt/sw
    
      stress --vm 2 --vm-bytes 600M   # doesn't matter too much as well
    
    Symptoms:
     - FS corruption (e.g. checksum failure)
     - memory corruption at: 0xd2808010
     - segfault
    
    Fixes: f0eea189e8e9 ("mm, THP, swap: Don't allocate huge cluster for file backed swap device")
    Fixes: 38d8b4e6bdc8 ("mm, THP, swap: delay splitting THP during swap out")
    Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
    Reviewed-by: Yang Shi <shy828301@gmail.com>
    Acked-by: Rafael Aquini <aquini@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Carlos Maiolino <cmaiolino@redhat.com>
    Cc: Eric Sandeen <esandeen@redhat.com>
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200820045323.7809-1-hsiangkao@redhat.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3907be9020eef58bf08a8094f1692f2f4b933e26
Author: Charan Teja Reddy <charante@codeaurora.org>
Date:   Fri Sep 18 16:02:31 2020 +0530

    dmabuf: fix NULL pointer dereference in dma_buf_release()
    
    commit 19a508bd1ad8e444de86873bf2f2b2ab8edd6552 upstream.
    
    NULL pointer dereference is observed while exporting the dmabuf but
    failed to allocate the 'struct file' which results into the dropping of
    the allocated dentry corresponding to this file in the dmabuf fs, which
    is ending up in dma_buf_release() and accessing the uninitialzed
    dentry->d_fsdata.
    
    Call stack on 5.4 is below:
     dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
     __dentry_kill+0x294/0x31c fs/dcache.c:584
     dentry_kill fs/dcache.c:673 [inline]
     dput+0x250/0x380 fs/dcache.c:859
     path_put+0x24/0x40 fs/namei.c:485
     alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235
     dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline]
     dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585
    
    Fix this by checking for the valid pointer in the dentry->d_fsdata.
    
    Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops")
    Cc: <stable@vger.kernel.org> [5.7+]
    Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/391319/
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22dd2387ee818980f3afbe2a79011f42c6b0023e
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Wed Sep 23 18:33:12 2020 +0800

    MIPS: Loongson2ef: Disable Loongson MMI instructions
    
    commit b13812ddea615b6507beef24f76540c0c1143c5c upstream.
    
    It was missed when I was forking Loongson2ef from Loongson64 but
    should be applied to Loongson2ef as march=loongson2f
    will also enable Loongson MMI in GCC-9+.
    
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Fixes: 71e2f4dd5a65 ("MIPS: Fork loongson2ef from loongson64")
    Reported-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: stable@vger.kernel.org # v5.8+
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 464b2d4cba99912810f13bdae1dd725140f8b964
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Sep 8 12:02:53 2020 +0200

    media: cec-adap.c: don't use flush_scheduled_work()
    
    commit 288eceb0858323d66bff03cf386630a797b248ad upstream.
    
    For some inexplicable reason I decided to call flush_scheduled_work()
    instead of cancel_delayed_work_sync(). The problem with that is that
    flush_scheduled_work() waits for *all* queued scheduled work to be
    completed instead of just the work itself.
    
    This can cause a deadlock if a CEC driver also schedules work that
    takes the same lock. See the comments for flush_scheduled_work() in
    linux/workqueue.h.
    
    This is exactly what has been observed a few times.
    
    This patch simply replaces flush_scheduled_work() by
    cancel_delayed_work_sync().
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: <stable@vger.kernel.org>      # for v5.8 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d242377a12afb92527db7c0dc519e9c92a06bb72
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Mon Sep 21 16:57:14 2020 +0900

    btrfs: fix overflow when copying corrupt csums for a message
    
    commit 35be8851d172c6e3db836c0f28c19087b10c9e00 upstream.
    
    Syzkaller reported a buffer overflow in btree_readpage_end_io_hook()
    when loop mounting a crafted image:
    
      detected buffer overflow in memcpy
      ------------[ cut here ]------------
      kernel BUG at lib/string.c:1129!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 26 Comm: kworker/u4:2 Not tainted 5.9.0-rc4-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: btrfs-endio-meta btrfs_work_helper
      RIP: 0010:fortify_panic+0xf/0x20 lib/string.c:1129
      RSP: 0018:ffffc90000e27980 EFLAGS: 00010286
      RAX: 0000000000000022 RBX: ffff8880a80dca64 RCX: 0000000000000000
      RDX: ffff8880a90860c0 RSI: ffffffff815dba07 RDI: fffff520001c4f22
      RBP: ffff8880a80dca00 R08: 0000000000000022 R09: ffff8880ae7318e7
      R10: 0000000000000000 R11: 0000000000077578 R12: 00000000ffffff6e
      R13: 0000000000000008 R14: ffffc90000e27a40 R15: 1ffff920001c4f3c
      FS:  0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000557335f440d0 CR3: 000000009647d000 CR4: 00000000001506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       memcpy include/linux/string.h:405 [inline]
       btree_readpage_end_io_hook.cold+0x206/0x221 fs/btrfs/disk-io.c:642
       end_bio_extent_readpage+0x4de/0x10c0 fs/btrfs/extent_io.c:2854
       bio_endio+0x3cf/0x7f0 block/bio.c:1449
       end_workqueue_fn+0x114/0x170 fs/btrfs/disk-io.c:1695
       btrfs_work_helper+0x221/0xe20 fs/btrfs/async-thread.c:318
       process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
       worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
       kthread+0x3b5/0x4a0 kernel/kthread.c:292
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
      Modules linked in:
      ---[ end trace b68924293169feef ]---
      RIP: 0010:fortify_panic+0xf/0x20 lib/string.c:1129
      RSP: 0018:ffffc90000e27980 EFLAGS: 00010286
      RAX: 0000000000000022 RBX: ffff8880a80dca64 RCX: 0000000000000000
      RDX: ffff8880a90860c0 RSI: ffffffff815dba07 RDI: fffff520001c4f22
      RBP: ffff8880a80dca00 R08: 0000000000000022 R09: ffff8880ae7318e7
      R10: 0000000000000000 R11: 0000000000077578 R12: 00000000ffffff6e
      R13: 0000000000000008 R14: ffffc90000e27a40 R15: 1ffff920001c4f3c
      FS:  0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f95b7c4d008 CR3: 000000009647d000 CR4: 00000000001506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    The overflow happens, because in btree_readpage_end_io_hook() we assume
    that we have found a 4 byte checksum instead of the real possible 32
    bytes we have for the checksums.
    
    With the fix applied:
    
    [   35.726623] BTRFS: device fsid 815caf9a-dc43-4d2a-ac54-764b8333d765 devid 1 transid 5 /dev/loop0 scanned by syz-repro (215)
    [   35.738994] BTRFS info (device loop0): disk space caching is enabled
    [   35.738998] BTRFS info (device loop0): has skinny extents
    [   35.743337] BTRFS warning (device loop0): loop0 checksum verify failed on 1052672 wanted 0xf9c035fc8d239a54 found 0x67a25c14b7eabcf9 level 0
    [   35.743420] BTRFS error (device loop0): failed to read chunk root
    [   35.745899] BTRFS error (device loop0): open_ctree failed
    
    Reported-by: syzbot+e864a35d361e1d4e29a5@syzkaller.appspotmail.com
    Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for checksumming")
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22ee6b8fda4193c1ff9ae3d736c882e9f0713080
Author: Anand Jain <anand.jain@oracle.com>
Date:   Sat Sep 5 01:34:21 2020 +0800

    btrfs: fix put of uninitialized kobject after seed device delete
    
    commit b5ddcffa37778244d5e786fe32f778edf2bfc93e upstream.
    
    The following test case leads to NULL kobject free error:
    
      mount seed /mnt
      add sprout to /mnt
      umount /mnt
      mount sprout to /mnt
      delete seed
    
      kobject: '(null)' (00000000dd2b87e4): is not initialized, yet kobject_put() is being called.
      WARNING: CPU: 1 PID: 15784 at lib/kobject.c:736 kobject_put+0x80/0x350
      RIP: 0010:kobject_put+0x80/0x350
      ::
      Call Trace:
      btrfs_sysfs_remove_devices_dir+0x6e/0x160 [btrfs]
      btrfs_rm_device.cold+0xa8/0x298 [btrfs]
      btrfs_ioctl+0x206c/0x22a0 [btrfs]
      ksys_ioctl+0xe2/0x140
      __x64_sys_ioctl+0x1e/0x29
      do_syscall_64+0x96/0x150
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7f4047c6288b
      ::
    
    This is because, at the end of the seed device-delete, we try to remove
    the seed's devid sysfs entry. But for the seed devices under the sprout
    fs, we don't initialize the devid kobject yet. So add a kobject state
    check, which takes care of the bug.
    
    Fixes: 668e48af7a94 ("btrfs: sysfs, add devid/dev_state kobject and device attributes")
    CC: stable@vger.kernel.org # 5.6+
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 913d4c0dcdbaeb892d5d1b6b754598052121d48a
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Sep 10 17:55:05 2020 +0900

    kprobes: tracing/kprobes: Fix to kill kprobes on initmem after boot
    
    commit 82d083ab60c3693201c6f5c7a5f23a6ed422098d upstream.
    
    Since kprobe_event= cmdline option allows user to put kprobes on the
    functions in initmem, kprobe has to make such probes gone after boot.
    Currently the probes on the init functions in modules will be handled
    by module callback, but the kernel init text isn't handled.
    Without this, kprobes may access non-exist text area to disable or
    remove it.
    
    Link: https://lkml.kernel.org/r/159972810544.428528.1839307531600646955.stgit@devnote2
    
    Fixes: 970988e19eb0 ("tracing/kprobe: Add kprobe_event= boot parameter")
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 247c62ebdfae450bb76dd89cd4724df6be07df75
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Tue Sep 1 00:12:07 2020 +0900

    kprobes: Fix to check probe enabled before disarm_kprobe_ftrace()
    
    commit 3031313eb3d549b7ad6f9fbcc52ba04412e3eb9e upstream.
    
    Commit 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at
    kprobe_ftrace_handler") fixed one bug but not completely fixed yet.
    If we run a kprobe_module.tc of ftracetest, kernel showed a warning
    as below.
    
    # ./ftracetest test.d/kprobe/kprobe_module.tc
    === Ftrace unit tests ===
    [1] Kprobe dynamic event - probing module
    ...
    [   22.400215] ------------[ cut here ]------------
    [   22.400962] Failed to disarm kprobe-ftrace at trace_printk_irq_work+0x0/0x7e [trace_printk] (-2)
    [   22.402139] WARNING: CPU: 7 PID: 200 at kernel/kprobes.c:1091 __disarm_kprobe_ftrace.isra.0+0x7e/0xa0
    [   22.403358] Modules linked in: trace_printk(-)
    [   22.404028] CPU: 7 PID: 200 Comm: rmmod Not tainted 5.9.0-rc2+ #66
    [   22.404870] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
    [   22.406139] RIP: 0010:__disarm_kprobe_ftrace.isra.0+0x7e/0xa0
    [   22.406947] Code: 30 8b 03 eb c9 80 3d e5 09 1f 01 00 75 dc 49 8b 34 24 89 c2 48 c7 c7 a0 c2 05 82 89 45 e4 c6 05 cc 09 1f 01 01 e8 a9 c7 f0 ff <0f> 0b 8b 45 e4 eb b9 89 c6 48 c7 c7 70 c2 05 82 89 45 e4 e8 91 c7
    [   22.409544] RSP: 0018:ffffc90000237df0 EFLAGS: 00010286
    [   22.410385] RAX: 0000000000000000 RBX: ffffffff83066024 RCX: 0000000000000000
    [   22.411434] RDX: 0000000000000001 RSI: ffffffff810de8d3 RDI: ffffffff810de8d3
    [   22.412687] RBP: ffffc90000237e10 R08: 0000000000000001 R09: 0000000000000001
    [   22.413762] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88807c478640
    [   22.414852] R13: ffffffff8235ebc0 R14: ffffffffa00060c0 R15: 0000000000000000
    [   22.415941] FS:  00000000019d48c0(0000) GS:ffff88807d7c0000(0000) knlGS:0000000000000000
    [   22.417264] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   22.418176] CR2: 00000000005bb7e3 CR3: 0000000078f7a000 CR4: 00000000000006a0
    [   22.419309] Call Trace:
    [   22.419990]  kill_kprobe+0x94/0x160
    [   22.420652]  kprobes_module_callback+0x64/0x230
    [   22.421470]  notifier_call_chain+0x4f/0x70
    [   22.422184]  blocking_notifier_call_chain+0x49/0x70
    [   22.422979]  __x64_sys_delete_module+0x1ac/0x240
    [   22.423733]  do_syscall_64+0x38/0x50
    [   22.424366]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [   22.425176] RIP: 0033:0x4bb81d
    [   22.425741] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e0 ff ff ff f7 d8 64 89 01 48
    [   22.428726] RSP: 002b:00007ffc70fef008 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
    [   22.430169] RAX: ffffffffffffffda RBX: 00000000019d48a0 RCX: 00000000004bb81d
    [   22.431375] RDX: 0000000000000000 RSI: 0000000000000880 RDI: 00007ffc70fef028
    [   22.432543] RBP: 0000000000000880 R08: 00000000ffffffff R09: 00007ffc70fef320
    [   22.433692] R10: 0000000000656300 R11: 0000000000000246 R12: 00007ffc70fef028
    [   22.434635] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
    [   22.435682] irq event stamp: 1169
    [   22.436240] hardirqs last  enabled at (1179): [<ffffffff810df542>] console_unlock+0x422/0x580
    [   22.437466] hardirqs last disabled at (1188): [<ffffffff810df19b>] console_unlock+0x7b/0x580
    [   22.438608] softirqs last  enabled at (866): [<ffffffff81c0038e>] __do_softirq+0x38e/0x490
    [   22.439637] softirqs last disabled at (859): [<ffffffff81a00f42>] asm_call_on_stack+0x12/0x20
    [   22.440690] ---[ end trace 1e7ce7e1e4567276 ]---
    [   22.472832] trace_kprobe: This probe might be able to register after target module is loaded. Continue.
    
    This is because the kill_kprobe() calls disarm_kprobe_ftrace() even
    if the given probe is not enabled. In that case, ftrace_set_filter_ip()
    fails because the given probe point is not registered to ftrace.
    
    Fix to check the given (going) probe is enabled before invoking
    disarm_kprobe_ftrace().
    
    Link: https://lkml.kernel.org/r/159888672694.1411785.5987998076694782591.stgit@devnote2
    
    Fixes: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com>
    Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
    Cc: David Miller <davem@davemloft.net>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: Chengming Zhou <zhouchengming@bytedance.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1ab267999b887ab59d8f4f22aec43367d7262b3
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Mon Sep 21 18:44:51 2020 +0900

    lib/bootconfig: Fix to remove tailing spaces after value
    
    commit c7af4ecdffe1537ba8aeed0ac12c3326f908df43 upstream.
    
    Fix to remove tailing spaces after value. If there is a space
    after value, the bootconfig failed to remove it because it
    applies strim() before replacing the delimiter with null.
    
    For example,
    
    foo = var    # comment
    
    was parsed as below.
    
    foo="var    "
    
    but user will expect
    
    foo="var"
    
    This fixes it by applying strim() after removing the delimiter.
    
    Link: https://lkml.kernel.org/r/160068149134.1088739.8868306567670058853.stgit@devnote2
    
    Fixes: 76db5a27a827 ("bootconfig: Add Extra Boot Config support")
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dce326c2b35b1c6edaedea7db07149745c52fa22
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Mon Sep 21 18:44:42 2020 +0900

    lib/bootconfig: Fix a bug of breaking existing tree nodes
    
    commit ead1e19ad905b97261f0ad7a98bb64abb9323b2b upstream.
    
    Fix a bug of breaking existing tree nodes by parsing the second
    and subsequent braces. Since the bootconfig parser uses the
    node.next field as a flag of current parent node, but this will
    break the existing tree if the same key node is specified again
    in the bootconfig.
    
    For example, the following bootconfig should be foo.buz and bar.
    
    foo
    bar
    foo { buz }
    
    However, when parsing the brace "{", it breaks foo->bar link
    by marking open-brace node. So the bootconfig unlinks bar
    from the bootconfig internal tree.
    
    This introduces a stack outside of the tree and record the
    last open-brace on the stack instead of using node.next field.
    
    Link: https://lkml.kernel.org/r/160068148267.1088739.8264704338030168660.stgit@devnote2
    
    Fixes: 76db5a27a827 ("bootconfig: Add Extra Boot Config support")
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6540544b78f8973bb16400ce3a90b5ebe0b793f6
Author: Felix Fietkau <nbd@nbd.name>
Date:   Wed Aug 12 12:23:32 2020 +0200

    mt76: mt7615: use v1 MCU API on MT7615 to fix issues with adding/removing stations
    
    commit d1c9da9e4c938e8bbf8b0ef9e5772b97db5639e9 upstream.
    
    The implementation of embedding WTBL update inside the STA_REC update is buggy
    on the MT7615 v2 firmware. This leads to connection issues after a station has
    connected and disconnected again.
    
    Switch to the v1 MCU API ops, since they have received much more testing and
    should be more stable.
    
    On MT7622 and later, the v2 API is more actively used, so we should keep using
    it as well.
    
    Fixes: 6849e29ed92e ("mt76: mt7615: add starec operating flow for firmware v2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200812102332.11812-1-nbd@nbd.name
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f176cd6084b2688b529eaed2b4e3eaa3445f41e4
Author: Jan Höppner <hoeppner@linux.ibm.com>
Date:   Mon Sep 14 13:56:47 2020 +0200

    s390/dasd: Fix zero write for FBA devices
    
    commit 709192d531e5b0a91f20aa14abfe2fc27ddd47af upstream.
    
    A discard request that writes zeros using the global kernel internal
    ZERO_PAGE will fail for machines with more than 2GB of memory due to the
    location of the ZERO_PAGE.
    
    Fix this by using a driver owned global zero page allocated with GFP_DMA
    flag set.
    
    Fixes: 28b841b3a7cb ("s390/dasd: Add discard support for FBA devices")
    Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
    Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
    Cc: <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3a23511638a3dcf0275c1e71a46d1ca2e2e6788
Author: Tom Rix <trix@redhat.com>
Date:   Mon Sep 7 06:58:45 2020 -0700

    tracing: fix double free
    
    commit 46bbe5c671e06f070428b9be142cc4ee5cedebac upstream.
    
    clang static analyzer reports this problem
    
    trace_events_hist.c:3824:3: warning: Attempt to free
      released memory
        kfree(hist_data->attrs->var_defs.name[i]);
    
    In parse_var_defs() if there is a problem allocating
    var_defs.expr, the earlier var_defs.name is freed.
    This free is duplicated by free_var_defs() which frees
    the rest of the list.
    
    Because free_var_defs() has to run anyway, remove the
    second free fom parse_var_defs().
    
    Link: https://lkml.kernel.org/r/20200907135845.15804-1-trix@redhat.com
    
    Cc: stable@vger.kernel.org
    Fixes: 30350d65ac56 ("tracing: Add variable support to hist triggers")
    Reviewed-by: Tom Zanussi <tom.zanussi@linux.intel.com>
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c321af82cae2e2c9e84c4400562386df43906a66
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri Sep 25 21:19:18 2020 -0700

    lib/string.c: implement stpcpy
    
    commit 1e1b6d63d6340764e00356873e5794225a2a03ea upstream.
    
    LLVM implemented a recent "libcall optimization" that lowers calls to
    `sprintf(dest, "%s", str)` where the return value is used to
    `stpcpy(dest, str) - dest`.
    
    This generally avoids the machinery involved in parsing format strings.
    `stpcpy` is just like `strcpy` except it returns the pointer to the new
    tail of `dest`.  This optimization was introduced into clang-12.
    
    Implement this so that we don't observe linkage failures due to missing
    symbol definitions for `stpcpy`.
    
    Similar to last year's fire drill with: commit 5f074f3e192f
    ("lib/string.c: implement a basic bcmp")
    
    The kernel is somewhere between a "freestanding" environment (no full
    libc) and "hosted" environment (many symbols from libc exist with the
    same type, function signature, and semantics).
    
    As Peter Anvin notes, there's not really a great way to inform the
    compiler that you're targeting a freestanding environment but would like
    to opt-in to some libcall optimizations (see pr/47280 below), rather
    than opt-out.
    
    Arvind notes, -fno-builtin-* behaves slightly differently between GCC
    and Clang, and Clang is missing many __builtin_* definitions, which I
    consider a bug in Clang and am working on fixing.
    
    Masahiro summarizes the subtle distinction between compilers justly:
      To prevent transformation from foo() into bar(), there are two ways in
      Clang to do that; -fno-builtin-foo, and -fno-builtin-bar.  There is
      only one in GCC; -fno-buitin-foo.
    
    (Any difference in that behavior in Clang is likely a bug from a missing
    __builtin_* definition.)
    
    Masahiro also notes:
      We want to disable optimization from foo() to bar(),
      but we may still benefit from the optimization from
      foo() into something else. If GCC implements the same transform, we
      would run into a problem because it is not -fno-builtin-bar, but
      -fno-builtin-foo that disables that optimization.
    
      In this regard, -fno-builtin-foo would be more future-proof than
      -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
      may want to prevent calls from foo() being optimized into calls to
      bar(), but we still may want other optimization on calls to foo().
    
    It seems that compilers today don't quite provide the fine grain control
    over which libcall optimizations pseudo-freestanding environments would
    prefer.
    
    Finally, Kees notes that this interface is unsafe, so we should not
    encourage its use.  As such, I've removed the declaration from any
    header, but it still needs to be exported to avoid linkage errors in
    modules.
    
    Reported-by: Sami Tolvanen <samitolvanen@google.com>
    Suggested-by: Andy Lavr <andy.lavr@gmail.com>
    Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
    Suggested-by: Joe Perches <joe@perches.com>
    Suggested-by: Kees Cook <keescook@chromium.org>
    Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
    Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200914161643.938408-1-ndesaulniers@google.com
    Link: https://bugs.llvm.org/show_bug.cgi?id=47162
    Link: https://bugs.llvm.org/show_bug.cgi?id=47280
    Link: https://github.com/ClangBuiltLinux/linux/issues/1126
    Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
    Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
    Link: https://reviews.llvm.org/D85963
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3396e0ad33da8d0734afd331f7dda2f6ced3eeda
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Sep 14 15:02:29 2020 +0800

    ALSA: hda/realtek: Enable front panel headset LED on Lenovo ThinkStation P520
    
    commit f73bbf639b32acb6b409e188fdde5644b301978f upstream.
    
    On Lenovo P520, the front panel headset LED isn't lit up right now.
    
    Realtek states that the LED needs to be enabled by ALC233's GPIO2, so
    let's do it accordingly to light the LED up.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Hui Wang <hui.wang@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200914070231.13192-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad0643252831ede7d6ab7b70a4f03768e032e6b4
Author: Hui Wang <hui.wang@canonical.com>
Date:   Mon Sep 14 14:51:18 2020 +0800

    ALSA: hda/realtek - Couldn't detect Mic if booting with headset plugged
    
    commit 3f74249057827c5f6676c41c18f6be12ce1469ce upstream.
    
    We found a Mic detection issue on many Lenovo laptops, those laptops
    belong to differnt models and they have different audio design like
    internal mic connects to the codec or PCH, they all have this problem,
    the problem is if plugging a headset before powerup/reboot the
    machine, after booting up, the headphone could be detected but Mic
    couldn't. If we plug out and plug in the headset, both headphone and
    Mic could be detected then.
    
    Through debugging we found the codec on those laptops are same, it is
    alc257, and if we don't disable the 3k pulldown in alc256_shutup(),
    the issue will be fixed. So far there is no pop noise or power
    consumption regression on those laptops after this change.
    
    Cc: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20200914065118.19238-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a08dbd8764c69b419483fcecfcd756542571bff
Author: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date:   Thu Sep 10 10:53:28 2020 +0200

    ALSA: usb-audio: Add delay quirk for H570e USB headsets
    
    commit 315c7ad7a701baba28c628c4c5426b3d9617ceed upstream.
    
    Needs the same delay as H650e
    
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200910085328.19188-1-joakim.tjernlund@infinera.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdf44bc9f55d65865087ff733ae80533d0a38a0e
Author: James Smart <james.smart@broadcom.com>
Date:   Fri Sep 11 13:01:47 2020 -0700

    scsi: lpfc: Fix initial FLOGI failure due to BBSCN not supported
    
    commit 7f04839ec4483563f38062b4dd90253e45447198 upstream.
    
    Initial FLOGIs are failing with the following message:
    
     lpfc 0000:13:00.1: 1:(0):0820 FLOGI Failed (x300). BBCredit Not Supported
    
    In a prior patch, the READ_SPARAM command was re-ordered to post after
    CONFIG_LINK as the driver is expected to update the driver's copy of the
    service parameters for the FLOGI payload. If the bb-credit recovery feature
    is enabled, this is fine. But on adapters were bb-credit recovery isn't
    enabled, it would cause the FLOGI to fail.
    
    Fix by restoring the original command order (READ_SPARAM before
    CONFIG_LINK), and after issuing CONFIG_LINK, detect bb-credit recovery
    support and reissuing READ_SPARAM to obtain the updated service parameters
    (effectively adding in the fix command order).
    
    [mkp: corrected SHA]
    
    Link: https://lore.kernel.org/r/20200911200147.110826-1-james.smart@broadcom.com
    Fixes: 835214f5d5f5 ("scsi: lpfc: Fix broken Credit Recovery after driver load")
    CC: <stable@vger.kernel.org> # v5.7+
    Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ade8f2c5ff7a29f7ff01a39d9ca06309460c02b4
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Sep 23 17:46:20 2020 +0200

    x86/ioapic: Unbreak check_timer()
    
    commit 86a82ae0b5095ea24c55898a3f025791e7958b21 upstream.
    
    Several people reported in the kernel bugzilla that between v4.12 and v4.13
    the magic which works around broken hardware and BIOSes to find the proper
    timer interrupt delivery mode stopped working for some older affected
    platforms which need to fall back to ExtINT delivery mode.
    
    The reason is that the core code changed to keep track of the masked and
    disabled state of an interrupt line more accurately to avoid the expensive
    hardware operations.
    
    That broke an assumption in i8259_make_irq() which invokes
    
         disable_irq_nosync();
         irq_set_chip_and_handler();
         enable_irq();
    
    Up to v4.12 this worked because enable_irq() unconditionally unmasked the
    interrupt line, but after the state tracking improvements this is not
    longer the case because the IO/APIC uses lazy disabling. So the line state
    is unmasked which means that enable_irq() does not call into the new irq
    chip to unmask it.
    
    In principle this is a shortcoming of the core code, but it's more than
    unclear whether the core code should try to reset state. At least this
    cannot be done unconditionally as that would break other existing use cases
    where the chip type is changed, e.g. when changing the trigger type, but
    the callers expect the state to be preserved.
    
    As the way how check_timer() is switching the delivery modes is truly
    unique, the obvious fix is to simply unmask the i8259 manually after
    changing the mode to ExtINT delivery and switching the irq chip to the
    legacy PIC.
    
    Note, that the fixes tag is not really precise, but identifies the commit
    which broke the assumptions in the IO/APIC and i8259 code and that's the
    kernel version to which this needs to be backported.
    
    Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls")
    Reported-by: p_c_chan@hotmail.com
    Reported-by: ecm4@mail.com
    Reported-by: perdigao1@yahoo.com
    Reported-by: matzes@users.sourceforge.net
    Reported-by: rvelascog@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: p_c_chan@hotmail.com
    Tested-by: matzes@users.sourceforge.net
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=197769
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e45e8ddf3cfcc7eb756caa35d81c731282b5d0d1
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Sep 22 09:58:52 2020 +0200

    x86/irq: Make run_on_irqstack_cond() typesafe
    
    commit a7b3474cbb2864d5500d5e4f48dd57c903975cab upstream.
    
    Sami reported that run_on_irqstack_cond() requires the caller to cast
    functions to mismatching types, which trips indirect call Control-Flow
    Integrity (CFI) in Clang.
    
    Instead of disabling CFI on that function, provide proper helpers for
    the three call variants. The actual ASM code stays the same as that is
    out of reach.
    
     [ bp: Fix __run_on_irqstack() prototype to match. ]
    
    Fixes: 931b94145981 ("x86/entry: Provide helpers for executing on the irqstack")
    Reported-by: Nathan Chancellor <natechancellor@gmail.com>
    Reported-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by: Sami Tolvanen <samitolvanen@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1052
    Link: https://lkml.kernel.org/r/87pn6eb5tv.fsf@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba1c6085305773ec26f24cdd5e6c3723f27c71c0
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Sep 25 21:19:24 2020 -0700

    arch/x86/lib/usercopy_64.c: fix __copy_user_flushcache() cache writeback
    
    commit a1cd6c2ae47ee10ff21e62475685d5b399e2ed4a upstream.
    
    If we copy less than 8 bytes and if the destination crosses a cache
    line, __copy_user_flushcache would invalidate only the first cache line.
    
    This patch makes it invalidate the second cache line as well.
    
    Fixes: 0aed55af88345b ("x86, uaccess: introduce copy_from_iter_flushcache for pmem / cache-bypass operations")
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Dan Williams <dan.j.wiilliams@intel.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Toshi Kani <toshi.kani@hpe.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/alpine.LRH.2.02.2009161451140.21915@file01.intranet.prod.int.rdu2.redhat.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d6bd4901bbd427d5f0906606942d1a8a094fd11
Author: Minchan Kim <minchan@kernel.org>
Date:   Mon Sep 14 23:32:15 2020 -0700

    mm: validate pmd after splitting
    
    [ Upstream commit ce2684254bd4818ca3995c0d021fb62c4cf10a19 ]
    
    syzbot reported the following KASAN splat:
    
      general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
      CPU: 1 PID: 6826 Comm: syz-executor142 Not tainted 5.9.0-rc4-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__lock_acquire+0x84/0x2ae0 kernel/locking/lockdep.c:4296
      Code: ff df 8a 04 30 84 c0 0f 85 e3 16 00 00 83 3d 56 58 35 08 00 0f 84 0e 17 00 00 83 3d 25 c7 f5 07 00 74 2c 4c 89 e8 48 c1 e8 03 <80> 3c 30 00 74 12 4c 89 ef e8 3e d1 5a 00 48 be 00 00 00 00 00 fc
      RSP: 0018:ffffc90004b9f850 EFLAGS: 00010006
      Call Trace:
        lock_acquire+0x140/0x6f0 kernel/locking/lockdep.c:5006
        __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
        _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
        spin_lock include/linux/spinlock.h:354 [inline]
        madvise_cold_or_pageout_pte_range+0x52f/0x25c0 mm/madvise.c:389
        walk_pmd_range mm/pagewalk.c:89 [inline]
        walk_pud_range mm/pagewalk.c:160 [inline]
        walk_p4d_range mm/pagewalk.c:193 [inline]
        walk_pgd_range mm/pagewalk.c:229 [inline]
        __walk_page_range+0xe7b/0x1da0 mm/pagewalk.c:331
        walk_page_range+0x2c3/0x5c0 mm/pagewalk.c:427
        madvise_pageout_page_range mm/madvise.c:521 [inline]
        madvise_pageout mm/madvise.c:557 [inline]
        madvise_vma mm/madvise.c:946 [inline]
        do_madvise+0x12d0/0x2090 mm/madvise.c:1145
        __do_sys_madvise mm/madvise.c:1171 [inline]
        __se_sys_madvise mm/madvise.c:1169 [inline]
        __x64_sys_madvise+0x76/0x80 mm/madvise.c:1169
        do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The backing vma was shmem.
    
    In case of split page of file-backed THP, madvise zaps the pmd instead
    of remapping of sub-pages.  So we need to check pmd validity after
    split.
    
    Reported-by: syzbot+ecf80462cb7d5d552bc7@syzkaller.appspotmail.com
    Fixes: 1a4e58cce84e ("mm: introduce MADV_PAGEOUT")
    Signed-off-by: Minchan Kim <minchan@kernel.org>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15f6c3869c6c44031337a49879f02a49f7c9a23a
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Thu Sep 24 13:41:57 2020 -0500

    KVM: SVM: Add a dedicated INVD intercept routine
    
    [ Upstream commit 4bb05f30483fd21ea5413eaf1182768f251cf625 ]
    
    The INVD instruction intercept performs emulation. Emulation can't be done
    on an SEV guest because the guest memory is encrypted.
    
    Provide a dedicated intercept routine for the INVD intercept. And since
    the instruction is emulated as a NOP, just skip it instead.
    
    Fixes: 1654efcbc431 ("KVM: SVM: Add KVM_SEV_INIT command")
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Message-Id: <a0b9a19ffa7fef86a3cc700c7ea01cb2731e04e5.1600972918.git.thomas.lendacky@amd.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef4f69a4682462e19375f3d4c4c3448ce0bced1e
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Wed Sep 23 14:53:52 2020 -0700

    KVM: x86: Reset MMU context if guest toggles CR4.SMAP or CR4.PKE
    
    [ Upstream commit 8d214c481611b29458a57913bd786f0ac06f0605 ]
    
    Reset the MMU context during kvm_set_cr4() if SMAP or PKE is toggled.
    Recent commits to (correctly) not reload PDPTRs when SMAP/PKE are
    toggled inadvertantly skipped the MMU context reset due to the mask
    of bits that triggers PDPTR loads also being used to trigger MMU context
    resets.
    
    Fixes: 427890aff855 ("kvm: x86: Toggling CR4.SMAP does not load PDPTEs in PAE mode")
    Fixes: cb957adb4ea4 ("kvm: x86: Toggling CR4.PKE does not load PDPTEs in PAE mode")
    Cc: Jim Mattson <jmattson@google.com>
    Cc: Peter Shier <pshier@google.com>
    Cc: Oliver Upton <oupton@google.com>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Message-Id: <20200923215352.17756-1-sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a8354700cb223c42f36db1e64d2465563c2a4a0
Author: Ray Jui <ray.jui@broadcom.com>
Date:   Thu Sep 10 08:25:38 2020 -0700

    spi: bcm-qspi: Fix probe regression on iProc platforms
    
    [ Upstream commit 00fb259c618ea1198fc51b53a6167aa0d78672a9 ]
    
    iProc chips have QSPI controller that does not have the MSPI_REV
    offset. Reading from that offset will cause a bus error. Fix it by
    having MSPI_REV query disabled in the generic compatible string.
    
    Fixes: 3a01f04d74ef ("spi: bcm-qspi: Handle lack of MSPI_REV offset")
    Link: https://lore.kernel.org/linux-arm-kernel/20200909211857.4144718-1-f.fainelli@gmail.com/T/#u
    Signed-off-by: Ray Jui <ray.jui@broadcom.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20200910152539.45584-3-ray.jui@broadcom.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fce9400de3406b1e92de490db2b366e73413bf5b
Author: Icenowy Zheng <icenowy@aosc.io>
Date:   Wed Sep 23 08:51:42 2020 +0800

    regulator: axp20x: fix LDO2/4 description
    
    [ Upstream commit fbb5a79d2fe7b01c6424fbbc04368373b1672d61 ]
    
    Currently we wrongly set the mask of value of LDO2/4 both to the mask of
    LDO2, and the LDO4 voltage configuration is left untouched. This leads
    to conflict when LDO2/4 are both in use.
    
    Fix this issue by setting different vsel_mask to both regulators.
    
    Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
    Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
    Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.io
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f24ab64b8cc1b039316ae1a6e77c903a8568bdf
Author: Wei Li <liwei391@huawei.com>
Date:   Wed Sep 23 14:53:12 2020 +0800

    MIPS: Add the missing 'CPU_1074K' into __get_cpu_type()
    
    [ Upstream commit e393fbe6fa27af23f78df6e16a8fd2963578a8c4 ]
    
    Commit 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") split
    1074K from the 74K as an unique CPU type, while it missed to add the
    'CPU_1074K' in __get_cpu_type(). So let's add it back.
    
    Fixes: 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.")
    Signed-off-by: Wei Li <liwei391@huawei.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b7b64dda97859b27b075686c5fa9a0c5c50c91c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 8 10:25:57 2020 +0300

    PM / devfreq: tegra30: Disable clock on error in probe
    
    [ Upstream commit 6bf560766a8ef5afe4faa3244220cf5b3a934549 ]
    
    This error path needs to call clk_disable_unprepare().
    
    Fixes: 7296443b900e ("PM / devfreq: tegra30: Handle possible round-rate error")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 324f8ff1e09b74fd8c312aa8f5a0bfbdf3a4a79b
Author: Huacai Chen <chenhc@lemote.com>
Date:   Mon Aug 24 15:44:03 2020 +0800

    MIPS: Loongson-3: Fix fp register access if MSA enabled
    
    [ Upstream commit 01ce6d4d2c8157b076425e3dd8319948652583c5 ]
    
    If MSA is enabled, FPU_REG_WIDTH is 128 rather than 64, then get_fpr64()
    /set_fpr64() in the original unaligned instruction emulation code access
    the wrong fp registers. This is because the current code doesn't specify
    the correct index field, so fix it.
    
    Fixes: f83e4f9896eff614d0f2547a ("MIPS: Loongson-3: Add some unaligned instructions emulation")
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Pei Huang <huangpei@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 482082d22a41545df3203e5ee2fd9c2a1a5e3086
Author: Saeed Mahameed <saeedm@nvidia.com>
Date:   Fri Sep 11 11:00:06 2020 -0700

    net/mlx5e: mlx5e_fec_in_caps() returns a boolean
    
    [ Upstream commit cb39ccc5cbe1011d8d21886b75e2468070ac672c ]
    
    Returning errno is a bug, fix that.
    
    Also fixes smatch warnings:
    drivers/net/ethernet/mellanox/mlx5/core/en/port.c:453
    mlx5e_fec_in_caps() warn: signedness bug returning '(-95)'
    
    Fixes: 2132b71f78d2 ("net/mlx5e: Advertise globaly supported FEC modes")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Aya Levin <ayal@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93e864762dcb718892803f67f824b2646403a436
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Sep 17 18:34:05 2020 +0300

    regmap: fix page selection for noinc writes
    
    [ Upstream commit 05669b63170771d554854c0e465b76dc98fc7c84 ]
    
    Non-incrementing writes can fail if register + length crosses page
    border. However for non-incrementing writes we should not check for page
    border crossing. Fix this by passing additional flag to _regmap_raw_write
    and passing length to _regmap_select_page basing on the flag.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API")
    Link: https://lore.kernel.org/r/20200917153405.3139200-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de74a520081f1bab78ae7e017d59ea30078bc630
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Sep 17 18:34:04 2020 +0300

    regmap: fix page selection for noinc reads
    
    [ Upstream commit 4003324856311faebb46cbd56a1616bd3f3b67c2 ]
    
    Non-incrementing reads can fail if register + length crosses page
    border. However for non-incrementing reads we should not check for page
    border crossing. Fix this by passing additional flag to _regmap_raw_read
    and passing length to _regmap_select_page basing on the flag.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: 74fe7b551f33 ("regmap: Add regmap_noinc_read API")
    Link: https://lore.kernel.org/r/20200917153405.3139200-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e00a8682cb55e0a6a2e475954202e1ce79f85be
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Sun Sep 20 13:46:25 2020 -0400

    SUNRPC: Fix svc_flush_dcache()
    
    [ Upstream commit 13a9a9d74d4d9689ad65938966dbc66386063648 ]
    
    On platforms that implement flush_dcache_page(), a large NFS WRITE
    triggers the WARN_ONCE in bvec_iter_advance():
    
    Sep 20 14:01:05 klimt.1015granger.net kernel: Attempted to advance past end of bvec iter
    Sep 20 14:01:05 klimt.1015granger.net kernel: WARNING: CPU: 0 PID: 1032 at include/linux/bvec.h:101 bvec_iter_advance.isra.0+0xa7/0x158 [sunrpc]
    
    Sep 20 14:01:05 klimt.1015granger.net kernel: Call Trace:
    Sep 20 14:01:05 klimt.1015granger.net kernel:  svc_tcp_recvfrom+0x60c/0x12c7 [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? bvec_iter_advance.isra.0+0x158/0x158 [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? del_timer_sync+0x4b/0x55
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? test_bit+0x1d/0x27 [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  svc_recv+0x1193/0x15e4 [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? try_to_freeze.isra.0+0x6f/0x6f [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? refcount_sub_and_test.constprop.0+0x13/0x40 [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? svc_xprt_put+0x1e/0x29f [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? svc_send+0x39f/0x3c1 [sunrpc]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  nfsd+0x282/0x345 [nfsd]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? __kthread_parkme+0x74/0xba
    Sep 20 14:01:05 klimt.1015granger.net kernel:  kthread+0x2ad/0x2bc
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? nfsd_destroy+0x124/0x124 [nfsd]
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? test_bit+0x1d/0x27
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ? kthread_mod_delayed_work+0x115/0x115
    Sep 20 14:01:05 klimt.1015granger.net kernel:  ret_from_fork+0x22/0x30
    
    Reported-by: He Zhe <zhe.he@windriver.com>
    Fixes: ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96c45a01f4432724ffd6b95688fc5867f6025215
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Sep 18 19:36:24 2020 -0600

    io_uring: fix openat/openat2 unified prep handling
    
    [ Upstream commit 4eb8dded6b82e184c09bb963bea0335fa3f30b55 ]
    
    A previous commit unified how we handle prep for these two functions,
    but this means that we check the allowed context (SQPOLL, specifically)
    later than we should. Move the ring type checking into the two parent
    functions, instead of doing it after we've done some setup work.
    
    Fixes: ec65fea5a8d7 ("io_uring: deduplicate io_openat{,2}_prep()")
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21aaa0fc9b940f7a48912f90ee6dffd62b9decc5
Author: Tom Rix <trix@redhat.com>
Date:   Sun Sep 13 09:52:30 2020 -0700

    ALSA: asihpi: fix iounmap in error handler
    
    [ Upstream commit 472eb39103e885f302fd8fd6eff104fcf5503f1b ]
    
    clang static analysis flags this problem
    hpioctl.c:513:7: warning: Branch condition evaluates to
      a garbage value
                    if (pci.ap_mem_base[idx]) {
                        ^~~~~~~~~~~~~~~~~~~~
    
    If there is a failure in the middle of the memory space loop,
    only some of the memory spaces need to be cleaned up.
    
    At the error handler, idx holds the number of successful
    memory spaces mapped.  So rework the handler loop to use the
    old idx.
    
    There is a second problem, the memory space loop conditionally
    iomaps()/sets the mem_base so it is necessay to initize pci.
    
    Fixes: 719f82d3987a ("ALSA: Add support of AudioScience ASI boards")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Link: https://lore.kernel.org/r/20200913165230.17166-1-trix@redhat.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c9fadf3a3c27b873557a490c0050fbbb8f996d8
Author: John Crispin <john@phrozen.org>
Date:   Fri Sep 18 13:53:04 2020 +0200

    mac80211: fix 80 MHz association to 160/80+80 AP on 6 GHz
    
    [ Upstream commit 75bcbd6913de649601f4e7d3fb6d2b5effc24e9e ]
    
    When trying to associate to an AP support 180 or 80+80 MHz on 6 GHz with a
    STA that only has 80 Mhz support the cf2 field inside the chandef will get
    set causing the association to fail when trying to validate the chandef.
    Fix this by checking the support flags prior to setting cf2.
    
    Fixes: 57fa5e85d53ce ("mac80211: determine chandef from HE 6 GHz operation")
    Signed-off-by: John Crispin <john@phrozen.org>
    Link: https://lore.kernel.org/r/20200918115304.1135693-1-john@phrozen.org
    [reword commit message a bit]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c094f2da8bea8ae089784698005bfefc3f467aa
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Sep 17 11:52:23 2020 +0200

    cfg80211: fix 6 GHz channel conversion
    
    [ Upstream commit c0de8776af6543e10d1a5c8969679fd9f6b66fa9 ]
    
    We shouldn't accept any channels bigger than 233, fix that.
    
    Reported-by: Amar <asinghal@codeaurora.org>
    Fixes: d1a1646c0de7 ("cfg80211: adapt to new channelization of the 6GHz band")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://lore.kernel.org/r/20200917115222.312ba6f1d461.I3a8c8fbcc3cc019814fd9cd0aced7eb591626136@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3414cdb97ce1f89d2ba990241af3e61cfac7eed6
Author: Wen Gong <wgong@codeaurora.org>
Date:   Fri Sep 11 10:29:02 2020 +0000

    mac80211: do not disable HE if HT is missing on 2.4 GHz
    
    [ Upstream commit 780a8c9efc65f6d86acd44794495cedcd32eeb26 ]
    
    VHT is not supported on 2.4 GHz, but HE is; don't disable HE if HT
    is missing there, do that only on 5 GHz (6 GHz is only HE).
    
    Fixes: 57fa5e85d53ce51 ("mac80211: determine chandef from HE 6 GHz operation")
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Link: https://lore.kernel.org/r/010101747cb617f2-593c5410-1648-4a42-97a0-f3646a5a6dd1-000000@us-west-2.amazonses.com
    [rewrite the commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8241c165aea0e5ad41732ff2d5689ca4cc59e5c
Author: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Date:   Wed Sep 9 12:54:53 2020 +0300

    lib80211: fix unmet direct dependendices config warning when !CRYPTO
    
    [ Upstream commit b959ba9f468b1c581f40e92661ad58b093abaa03 ]
    
    When LIB80211_CRYPT_CCMP is enabled and CRYPTO is disabled, it results in unmet
    direct dependencies config warning. The reason is that LIB80211_CRYPT_CCMP
    selects CRYPTO_AES and CRYPTO_CCM, which are subordinate to CRYPTO. This is
    reproducible with CRYPTO disabled and R8188EU enabled, where R8188EU selects
    LIB80211_CRYPT_CCMP but does not select or depend on CRYPTO.
    
    Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
    
    Fixes: a11e2f85481c ("lib80211: use crypto API ccm(aes) transform for CCMP processing")
    Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
    Link: https://lore.kernel.org/r/20200909095452.3080-1-fazilyildiran@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf75119ad09d9a79fb2c0ed440a382c52ad1017b
Author: Yonghong Song <yhs@fb.com>
Date:   Tue Sep 15 17:44:01 2020 -0700

    bpf: Fix a rcu warning for bpffs map pretty-print
    
    [ Upstream commit ce880cb825fcc22d4e39046a6c3a3a7f6603883d ]
    
    Running selftest
      ./btf_btf -p
    the kernel had the following warning:
      [   51.528185] WARNING: CPU: 3 PID: 1756 at kernel/bpf/hashtab.c:717 htab_map_get_next_key+0x2eb/0x300
      [   51.529217] Modules linked in:
      [   51.529583] CPU: 3 PID: 1756 Comm: test_btf Not tainted 5.9.0-rc1+ #878
      [   51.530346] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.el7.centos 04/01/2014
      [   51.531410] RIP: 0010:htab_map_get_next_key+0x2eb/0x300
      ...
      [   51.542826] Call Trace:
      [   51.543119]  map_seq_next+0x53/0x80
      [   51.543528]  seq_read+0x263/0x400
      [   51.543932]  vfs_read+0xad/0x1c0
      [   51.544311]  ksys_read+0x5f/0xe0
      [   51.544689]  do_syscall_64+0x33/0x40
      [   51.545116]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The related source code in kernel/bpf/hashtab.c:
      709 static int htab_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
      710 {
      711         struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
      712         struct hlist_nulls_head *head;
      713         struct htab_elem *l, *next_l;
      714         u32 hash, key_size;
      715         int i = 0;
      716
      717         WARN_ON_ONCE(!rcu_read_lock_held());
    
    In kernel/bpf/inode.c, bpffs map pretty print calls map->ops->map_get_next_key()
    without holding a rcu_read_lock(), hence causing the above warning.
    To fix the issue, just surrounding map->ops->map_get_next_key() with rcu read lock.
    
    Fixes: a26ca7c982cb ("bpf: btf: Add pretty print support to the basic arraymap")
    Reported-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Andrii Nakryiko <andriin@fb.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/bpf/20200916004401.146277-1-yhs@fb.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ed1d040d0cc2c53de5ba4500166514044bb6efe
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Sep 15 09:54:10 2020 +0200

    batman-adv: mcast: fix duplicate mcast packets from BLA backbone to mesh
    
    [ Upstream commit 2369e827046920ef0599e6a36b975ac5c0a359c2 ]
    
    Scenario:
    * Multicast frame send from BLA backbone gateways (multiple nodes
      with their bat0 bridged together, with BLA enabled) sharing the same
      LAN to nodes in the mesh
    
    Issue:
    * Nodes receive the frame multiple times on bat0 from the mesh,
      once from each foreign BLA backbone gateway which shares the same LAN
      with another
    
    For multicast frames via batman-adv broadcast packets coming from the
    same BLA backbone but from different backbone gateways duplicates are
    currently detected via a CRC history of previously received packets.
    
    However this CRC so far was not performed for multicast frames received
    via batman-adv unicast packets. Fixing this by appyling the same check
    for such packets, too.
    
    Room for improvements in the future: Ideally we would introduce the
    possibility to not only claim a client, but a complete originator, too.
    This would allow us to only send a multicast-in-unicast packet from a BLA
    backbone gateway claiming the node and by that avoid potential redundant
    transmissions in the first place.
    
    Fixes: 279e89b2281a ("batman-adv: add broadcast duplicate check")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ae4340c6782e906d93676cd3aa0e71e89401859
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Sep 15 09:54:09 2020 +0200

    batman-adv: mcast: fix duplicate mcast packets in BLA backbone from mesh
    
    [ Upstream commit 74c09b7275126da1b642b90c9cdc3ae8b729ad4b ]
    
    Scenario:
    * Multicast frame send from mesh to a BLA backbone (multiple nodes
      with their bat0 bridged together, with BLA enabled)
    
    Issue:
    * BLA backbone nodes receive the frame multiple times on bat0,
      once from mesh->bat0 and once from each backbone_gw from LAN
    
    For unicast, a node will send only to the best backbone gateway
    according to the TQ. However for multicast we currently cannot determine
    if multiple destination nodes share the same backbone if they don't share
    the same backbone with us. So we need to keep sending the unicasts to
    all backbone gateways and let the backbone gateways decide which one
    will forward the frame. We can use the CLAIM mechanism to make this
    decision.
    
    One catch: The batman-adv gateway feature for DHCP packets potentially
    sends multicast packets in the same batman-adv unicast header as the
    multicast optimizations code. And we are not allowed to drop those even
    if we did not claim the source address of the sender, as for such
    packets there is only this one multicast-in-unicast packet.
    
    How can we distinguish the two cases?
    
    The gateway feature uses a batman-adv unicast 4 address header. While
    the multicast-to-unicasts feature uses a simple, 3 address batman-adv
    unicast header. So let's use this to distinguish.
    
    Fixes: fe2da6ff27c7 ("batman-adv: check incoming packet type for bla")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7f13870d54a50f02c8bf7bf9dcb382a2a526a2e
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Tue Sep 15 09:54:08 2020 +0200

    batman-adv: mcast: fix duplicate mcast packets in BLA backbone from LAN
    
    [ Upstream commit 3236d215ad38a3f5372e65cd1e0a52cf93d3c6a2 ]
    
    Scenario:
    * Multicast frame send from a BLA backbone (multiple nodes with
      their bat0 bridged together, with BLA enabled)
    
    Issue:
    * BLA backbone nodes receive the frame multiple times on bat0
    
    For multicast frames received via batman-adv broadcast packets the
    originator of the broadcast packet is checked before decapsulating and
    forwarding the frame to bat0 (batadv_bla_is_backbone_gw()->
    batadv_recv_bcast_packet()). If it came from a node which shares the
    same BLA backbone with us then it is not forwarded to bat0 to avoid a
    loop.
    
    When sending a multicast frame in a non-4-address batman-adv unicast
    packet we are currently missing this check - and cannot do so because
    the batman-adv unicast packet has no originator address field.
    
    However, we can simply fix this on the sender side by only sending the
    multicast frame via unicasts to interested nodes which do not share the
    same BLA backbone with us. This also nicely avoids some unnecessary
    transmissions on mesh side.
    
    Note that no infinite loop was observed, probably because of dropping
    via batadv_interface_tx()->batadv_bla_tx(). However the duplicates still
    utterly confuse switches/bridges, ICMPv6 duplicate address detection and
    neighbor discovery and therefore leads to long delays before being able
    to establish TCP connections, for instance. And it also leads to the Linux
    bridge printing messages like:
    "br-lan: received packet on eth1 with own address as source address ..."
    
    Fixes: 2d3f6ccc4ea5 ("batman-adv: Modified forwarding behaviour for multicast packets")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06dd1ca3b6376c4fc528f172b8d1b8dd3bf394c2
Author: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Date:   Mon Sep 14 18:01:21 2020 +0300

    nvme-tcp: fix kconfig dependency warning when !CRYPTO
    
    [ Upstream commit af5ad17854f96a6d3c9775e776bd01ab262672a1 ]
    
    When NVME_TCP is enabled and CRYPTO is disabled, it results in the
    following Kbuild warning:
    
    WARNING: unmet direct dependencies detected for CRYPTO_CRC32C
      Depends on [n]: CRYPTO [=n]
      Selected by [y]:
      - NVME_TCP [=y] && INET [=y] && BLK_DEV_NVME [=y]
    
    The reason is that NVME_TCP selects CRYPTO_CRC32C without depending on or
    selecting CRYPTO while CRYPTO_CRC32C is subordinate to CRYPTO.
    
    Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
    
    Fixes: 79fd751d61aa ("nvme: tcp: selects CRYPTO_CRC32C for nvme-tcp")
    Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9bc6ff7d24abdb398461840b1b2821cded7b783
Author: Björn Töpel <bjorn.topel@intel.com>
Date:   Thu Sep 10 09:56:09 2020 +0200

    xsk: Fix number of pinned pages/umem size discrepancy
    
    [ Upstream commit 2b1667e54caf95e1e4249d9068eea7a3089a5229 ]
    
    For AF_XDP sockets, there was a discrepancy between the number of of
    pinned pages and the size of the umem region.
    
    The size of the umem region is used to validate the AF_XDP descriptor
    addresses. The logic that pinned the pages covered by the region only
    took whole pages into consideration, creating a mismatch between the
    size and pinned pages. A user could then pass AF_XDP addresses outside
    the range of pinned pages, but still within the size of the region,
    crashing the kernel.
    
    This change correctly calculates the number of pages to be
    pinned. Further, the size check for the aligned mode is
    simplified. Now the code simply checks if the size is divisible by the
    chunk size.
    
    Fixes: bbff2f321a86 ("xsk: new descriptor addressing scheme")
    Reported-by: Ciara Loftus <ciara.loftus@intel.com>
    Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Tested-by: Ciara Loftus <ciara.loftus@intel.com>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20200910075609.7904-1-bjorn.topel@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4e1b0f1fdea69f6a31f456d6b4f8aa3d4531d4d
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Sep 14 13:58:16 2020 +0200

    batman-adv: Add missing include for in_interrupt()
    
    [ Upstream commit 4bba9dab86b6ac15ca560ef1f2b5aa4529cbf784 ]
    
    The fix for receiving (internally generated) bla packets outside the
    interrupt context introduced the usage of in_interrupt(). But this
    functionality is only defined in linux/preempt.h which was not included
    with the same patch.
    
    Fixes: 279e89b2281a ("batman-adv: bla: use netif_rx_ni when not in interrupt context")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38c2ce54364738b7b3aa0fdbaf588635712bc942
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Sep 14 15:20:18 2020 -0300

    RDMA/core: Fix ordering of CQ pool destruction
    
    [ Upstream commit 4aa1615268a8ac2b20096211d3f9ac53874067d7 ]
    
    rxe will hold a refcount on the IB device as long as CQ objects exist,
    this causes destruction of a rxe device to hang if the CQ pool has any
    cached CQs since they are being destroyed after the refcount must go to
    zero.
    
    Treat the CQ pool like a client and create/destroy it before/after all
    other clients. No users of CQ pool can exist past a client remove call.
    
    Link: https://lore.kernel.org/r/e8a240aa-9e9b-3dca-062f-9130b787f29b@acm.org
    Fixes: c7ff819aefea ("RDMA/core: Introduce shared CQ pool API")
    Tested-by: Bart Van Assche <bvanassche@acm.org>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9003be1fb4d099d6b37f7dd20e7cc15b00755a1e
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Thu Sep 10 15:15:32 2020 +0300

    spi: spi-fsl-dspi: use XSPI mode instead of DMA for DPAA2 SoCs
    
    [ Upstream commit 505623a2be48b36de533951ced130876a76a2d55 ]
    
    The arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi device tree lacks DMA
    channels for DSPI, so naturally, the driver fails to probe:
    
    [ 2.945302] fsl-dspi 2100000.spi: rx dma channel not available
    [ 2.951134] fsl-dspi 2100000.spi: can't get dma channels
    
    In retrospect, this should have been obvious, because LS2080A, LS2085A
    LS2088A and LX2160A don't appear to have an eDMA module at all. Looking
    again at their datasheets, the CTARE register (which is specific to XSPI
    functionality) seems to be documented, so switch them to XSPI mode
    instead.
    
    Fixes: 0feaf8f5afe0 ("spi: spi-fsl-dspi: Convert the instantiations that support it to DMA")
    Reported-by: Qiang Zhao <qiang.zhao@nxp.com>
    Tested-by: Qiang Zhao <qiang.zhao@nxp.com>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Link: https://lore.kernel.org/r/20200910121532.1138596-1-olteanv@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a634ff2bb06a4e3a57ec887f1a3e290c9044aba1
Author: Dexuan Cui <decui@microsoft.com>
Date:   Tue Sep 8 21:07:32 2020 -0700

    hv_netvsc: Switch the data path at the right time during hibernation
    
    [ Upstream commit de214e52de1bba5392b5b7054924a08dbd57c2f6 ]
    
    When netvsc_resume() is called, the mlx5 VF NIC has not been resumed yet,
    so in the future the host might sliently fail the call netvsc_vf_changed()
    -> netvsc_switch_datapath() there, even if the call works now.
    
    Call netvsc_vf_changed() in the NETDEV_CHANGE event handler: at that time
    the mlx5 VF NIC has been resumed.
    
    Fixes: 19162fd4063a ("hv_netvsc: Fix hibernation for mlx5 VF driver")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 086ca81d03c329088ce115fb49cca84736c44988
Author: Martin Cerveny <m.cerveny@computer.org>
Date:   Sun Sep 6 18:21:39 2020 +0200

    drm/sun4i: sun8i-csc: Secondary CSC register correction
    
    [ Upstream commit cab4c03b4ba54c8d9378298cacb8bc0fd74ceece ]
    
    "Allwinner V3s" has secondary video layer (VI).
    Decoded video is displayed in wrong colors until
    secondary CSC registers are programmed correctly.
    
    Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
    Signed-off-by: Martin Cerveny <m.cerveny@computer.org>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200906162140.5584-2-m.cerveny@computer.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fc50966df11e127d353417f5e5fa11bf095129e
Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date:   Tue Aug 18 16:40:02 2020 -0700

    igc: Fix not considering the TX delay for timestamps
    
    [ Upstream commit 4406e977a4a1e997818b6d77c3218ef8d15b2abf ]
    
    When timestamping a packet there's a delay between the start of the
    packet and the point where the hardware actually captures the
    timestamp. This difference needs to be considered if we want accurate
    timestamps.
    
    This was done on the RX side, but not on the TX side.
    
    Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df1aefc648789905b1ccb5791b6d0d39c53b80c4
Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date:   Tue Aug 18 16:40:01 2020 -0700

    igc: Fix wrong timestamp latency numbers
    
    [ Upstream commit f03369b9bfab8e23ac28ca7ab7e6631c374b7cbe ]
    
    The previous timestamping latency numbers were obtained by
    interpolating the i210 numbers with the i225 crystal clock value. That
    calculation was wrong.
    
    Use the correct values from real measurements.
    
    Fixes: 81b055205e8b ("igc: Add support for RX timestamping")
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60b4cd514ca4bdd9d7ac07e7ca543d250cc94c37
Author: Dmitry Bogdanov <dbogdanov@marvell.com>
Date:   Wed Sep 9 20:43:10 2020 +0300

    net: qed: RDMA personality shouldn't fail VF load
    
    [ Upstream commit ce1cf9e5025f4e2d2198728391f1847b3e168bc6 ]
    
    Fix the assert during VF driver installation when the personality is iWARP
    
    Fixes: 1fe614d10f45 ("qed: Relax VF firmware requirements")
    Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
    Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
    Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c89c047143e0fe3f3e53c15d3d012a76e6e13c9
Author: Dmitry Bogdanov <dbogdanov@marvell.com>
Date:   Wed Sep 9 20:43:09 2020 +0300

    net: qede: Disable aRFS for NPAR and 100G
    
    [ Upstream commit 0367f05885b9f21d062447bd2ba1302ba3cc7392 ]
    
    In some configurations ARFS cannot be used, so disable it if device
    is not capable.
    
    Fixes: e4917d46a653 ("qede: Add aRFS support")
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
    Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
    Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f5479c614a400e4d74702689fae62ad3c1d7f53
Author: Dmitry Bogdanov <dbogdanov@marvell.com>
Date:   Wed Sep 9 20:43:08 2020 +0300

    net: qed: Disable aRFS for NPAR and 100G
    
    [ Upstream commit 2d2fe8433796603091ac8ea235b9165ac5a85f9a ]
    
    In CMT and NPAR the PF is unknown when the GFS block processes the
    packet. Therefore cannot use searcher as it has a per PF database,
    and thus ARFS must be disabled.
    
    Fixes: d51e4af5c209 ("qed: aRFS infrastructure support")
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
    Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
    Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0560d7cfa3cb52e5388895d3c568823026ec145
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Wed Jul 1 09:39:49 2020 +0200

    drm/vc4/vc4_hdmi: fill ASoC card owner
    
    [ Upstream commit ec653df2a0cbc306a4bfcb0e3484d318fa779002 ]
    
    card->owner is a required property and since commit 81033c6b584b ("ALSA:
    core: Warn on empty module") a warning is issued if it is empty. Fix lack
    of it. This fixes following warning observed on RaspberryPi 3B board
    with ARM 32bit kernel and multi_v7_defconfig:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 snd_card_new+0x378/0x398 [snd]
    Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine bluetooth snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore ecdh_generic ecc bcm2835_thermal phy_generic
    CPU: 1 PID: 210 Comm: systemd-udevd Not tainted 5.8.0-rc1-00027-g81033c6b584b #1087
    Hardware name: BCM2835
    [<c03113c0>] (unwind_backtrace) from [<c030bcb4>] (show_stack+0x10/0x14)
    [<c030bcb4>] (show_stack) from [<c071cef8>] (dump_stack+0xd4/0xe8)
    [<c071cef8>] (dump_stack) from [<c0345bfc>] (__warn+0xdc/0xf4)
    [<c0345bfc>] (__warn) from [<c0345cc4>] (warn_slowpath_fmt+0xb0/0xb8)
    [<c0345cc4>] (warn_slowpath_fmt) from [<bf02ff74>] (snd_card_new+0x378/0x398 [snd])
    [<bf02ff74>] (snd_card_new [snd]) from [<bf11f0b4>] (snd_soc_bind_card+0x280/0x99c [snd_soc_core])
    [<bf11f0b4>] (snd_soc_bind_card [snd_soc_core]) from [<bf12f000>] (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core])
    [<bf12f000>] (devm_snd_soc_register_card [snd_soc_core]) from [<bf165654>] (vc4_hdmi_bind+0x43c/0x5f4 [vc4])
    [<bf165654>] (vc4_hdmi_bind [vc4]) from [<c09d660c>] (component_bind_all+0xec/0x24c)
    [<c09d660c>] (component_bind_all) from [<bf15c44c>] (vc4_drm_bind+0xd4/0x174 [vc4])
    [<bf15c44c>] (vc4_drm_bind [vc4]) from [<c09d6ac0>] (try_to_bring_up_master+0x160/0x1b0)
    [<c09d6ac0>] (try_to_bring_up_master) from [<c09d6f38>] (component_master_add_with_match+0xd0/0x104)
    [<c09d6f38>] (component_master_add_with_match) from [<bf15c588>] (vc4_platform_drm_probe+0x9c/0xbc [vc4])
    [<bf15c588>] (vc4_platform_drm_probe [vc4]) from [<c09df740>] (platform_drv_probe+0x6c/0xa4)
    [<c09df740>] (platform_drv_probe) from [<c09dd6f0>] (really_probe+0x210/0x350)
    [<c09dd6f0>] (really_probe) from [<c09dd940>] (driver_probe_device+0x5c/0xb4)
    [<c09dd940>] (driver_probe_device) from [<c09ddb38>] (device_driver_attach+0x58/0x60)
    [<c09ddb38>] (device_driver_attach) from [<c09ddbc0>] (__driver_attach+0x80/0xbc)
    [<c09ddbc0>] (__driver_attach) from [<c09db820>] (bus_for_each_dev+0x68/0xb4)
    [<c09db820>] (bus_for_each_dev) from [<c09dc9f8>] (bus_add_driver+0x130/0x1e8)
    [<c09dc9f8>] (bus_add_driver) from [<c09de648>] (driver_register+0x78/0x110)
    [<c09de648>] (driver_register) from [<c0302038>] (do_one_initcall+0x50/0x220)
    [<c0302038>] (do_one_initcall) from [<c03db544>] (do_init_module+0x60/0x210)
    [<c03db544>] (do_init_module) from [<c03da4f8>] (load_module+0x1e34/0x2338)
    [<c03da4f8>] (load_module) from [<c03dac00>] (sys_finit_module+0xac/0xbc)
    [<c03dac00>] (sys_finit_module) from [<c03000c0>] (ret_fast_syscall+0x0/0x54)
    Exception stack(0xeded9fa8 to 0xeded9ff0)
    ...
    ---[ end trace 6414689569c2bc08 ]---
    
    Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
    Suggested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200701073949.28941-1-m.szyprowski@samsung.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3305c8444ee99306ec5095339bf39f5dbc3cb996
Author: Tony Ambardar <tony.ambardar@gmail.com>
Date:   Sat Sep 5 14:48:31 2020 -0700

    tools/libbpf: Avoid counting local symbols in ABI check
    
    [ Upstream commit 746f534a4809e07f427f7d13d10f3a6a9641e5c3 ]
    
    Encountered the following failure building libbpf from kernel 5.8.5 sources
    with GCC 8.4.0 and binutils 2.34: (long paths shortened)
    
      Warning: Num of global symbols in sharedobjs/libbpf-in.o (234) does NOT
      match with num of versioned symbols in libbpf.so (236). Please make sure
      all LIBBPF_API symbols are versioned in libbpf.map.
    #  --- libbpf_global_syms.tmp    2020-09-02 07:30:58.920084380 +0000
    #  +++ libbpf_versioned_syms.tmp 2020-09-02 07:30:58.924084388 +0000
      @@ -1,3 +1,5 @@
      +_fini
      +_init
       bpf_btf_get_fd_by_id
       bpf_btf_get_next_id
       bpf_create_map
      make[4]: *** [Makefile:210: check_abi] Error 1
    
    Investigation shows _fini and _init are actually local symbols counted
    amongst global ones:
    
      $ readelf --dyn-syms --wide libbpf.so|head -10
    
      Symbol table '.dynsym' contains 343 entries:
         Num:    Value  Size Type    Bind   Vis      Ndx Name
           0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
           1: 00004098     0 SECTION LOCAL  DEFAULT   11
           2: 00004098     8 FUNC    LOCAL  DEFAULT   11 _init@@LIBBPF_0.0.1
           3: 00023040     8 FUNC    LOCAL  DEFAULT   14 _fini@@LIBBPF_0.0.1
           4: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS LIBBPF_0.0.4
           5: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS LIBBPF_0.0.1
           6: 0000ffa4     8 FUNC    GLOBAL DEFAULT   12 bpf_object__find_map_by_offset@@LIBBPF_0.0.1
    
    A previous commit filtered global symbols in sharedobjs/libbpf-in.o. Do the
    same with the libbpf.so DSO for consistent comparison.
    
    Fixes: 306b267cb3c4 ("libbpf: Verify versioned symbols")
    Signed-off-by: Tony Ambardar <Tony.Ambardar@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Andrii Nakryiko <andriin@fb.com>
    Link: https://lore.kernel.org/bpf/20200905214831.1565465-1-Tony.Ambardar@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c86dff4cd3923d5561ca9ba06fa890b57866b981
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Sep 8 00:04:10 2020 +0200

    bpf: Fix clobbering of r2 in bpf_gen_ld_abs
    
    [ Upstream commit e6a18d36118bea3bf497c9df4d9988b6df120689 ]
    
    Bryce reported that he saw the following with:
    
      0:  r6 = r1
      1:  r1 = 12
      2:  r0 = *(u16 *)skb[r1]
    
    The xlated sequence was incorrectly clobbering r2 with pointer
    value of r6 ...
    
      0: (bf) r6 = r1
      1: (b7) r1 = 12
      2: (bf) r1 = r6
      3: (bf) r2 = r1
      4: (85) call bpf_skb_load_helper_16_no_cache#7692160
    
    ... and hence call to the load helper never succeeded given the
    offset was too high. Fix it by reordering the load of r6 to r1.
    
    Other than that the insn has similar calling convention than BPF
    helpers, that is, r0 - r5 are scratch regs, so nothing else
    affected after the insn.
    
    Fixes: e0cea7ce988c ("bpf: implement ld_abs/ld_ind in native bpf")
    Reported-by: Bryce Kahle <bryce.kahle@datadoghq.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/cace836e4d07bb63b1a53e49c5dfb238a040c298.1599512096.git.daniel@iogearbox.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36133c2c75f43cbadb9a9e3fa248c969cda8a1b7
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 8 03:40:25 2020 -0700

    mac802154: tx: fix use-after-free
    
    [ Upstream commit 0ff4628f4c6c1ab87eef9f16b25355cadc426d64 ]
    
    syzbot reported a bug in ieee802154_tx() [1]
    
    A similar issue in ieee802154_xmit_worker() is also fixed in this patch.
    
    [1]
    BUG: KASAN: use-after-free in ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
    Read of size 4 at addr ffff8880251a8c70 by task syz-executor.3/928
    
    CPU: 0 PID: 928 Comm: syz-executor.3 Not tainted 5.9.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x198/0x1fd lib/dump_stack.c:118
     print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
     __kasan_report mm/kasan/report.c:513 [inline]
     kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
     ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
     ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
     __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
     netdev_start_xmit include/linux/netdevice.h:4648 [inline]
     dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
     packet_snd net/packet/af_packet.c:2989 [inline]
     packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
     sock_sendmsg_nosec net/socket.c:651 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:671
     ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x45d5b9
    Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fc98e749c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 000000000002ccc0 RCX: 000000000045d5b9
    RDX: 0000000000000000 RSI: 0000000020007780 RDI: 000000000000000b
    RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec
    R13: 00007fff690c720f R14: 00007fc98e74a9c0 R15: 000000000118cfec
    
    Allocated by task 928:
     kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
     kasan_set_track mm/kasan/common.c:56 [inline]
     __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
     slab_post_alloc_hook mm/slab.h:518 [inline]
     slab_alloc_node mm/slab.c:3254 [inline]
     kmem_cache_alloc_node+0x136/0x3e0 mm/slab.c:3574
     __alloc_skb+0x71/0x550 net/core/skbuff.c:198
     alloc_skb include/linux/skbuff.h:1094 [inline]
     alloc_skb_with_frags+0x92/0x570 net/core/skbuff.c:5771
     sock_alloc_send_pskb+0x72a/0x880 net/core/sock.c:2348
     packet_alloc_skb net/packet/af_packet.c:2837 [inline]
     packet_snd net/packet/af_packet.c:2932 [inline]
     packet_sendmsg+0x19fb/0x5290 net/packet/af_packet.c:3014
     sock_sendmsg_nosec net/socket.c:651 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:671
     ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Freed by task 928:
     kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
     kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
     kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
     __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
     __cache_free mm/slab.c:3418 [inline]
     kmem_cache_free.part.0+0x74/0x1e0 mm/slab.c:3693
     kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:622
     __kfree_skb net/core/skbuff.c:679 [inline]
     consume_skb net/core/skbuff.c:838 [inline]
     consume_skb+0xcf/0x160 net/core/skbuff.c:832
     __dev_kfree_skb_any+0x9c/0xc0 net/core/dev.c:3107
     fakelb_hw_xmit+0x20e/0x2a0 drivers/net/ieee802154/fakelb.c:81
     drv_xmit_async net/mac802154/driver-ops.h:16 [inline]
     ieee802154_tx+0x282/0x480 net/mac802154/tx.c:81
     ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
     __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
     netdev_start_xmit include/linux/netdevice.h:4648 [inline]
     dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
     packet_snd net/packet/af_packet.c:2989 [inline]
     packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
     sock_sendmsg_nosec net/socket.c:651 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:671
     ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The buggy address belongs to the object at ffff8880251a8c00
     which belongs to the cache skbuff_head_cache of size 224
    The buggy address is located 112 bytes inside of
     224-byte region [ffff8880251a8c00, ffff8880251a8ce0)
    The buggy address belongs to the page:
    page:0000000062b6a4f1 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x251a8
    flags: 0xfffe0000000200(slab)
    raw: 00fffe0000000200 ffffea0000435c88 ffffea00028b6c08 ffff8880a9055d00
    raw: 0000000000000000 ffff8880251a80c0 000000010000000c 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8880251a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8880251a8b80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff8880251a8c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                 ^
     ffff8880251a8c80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
     ffff8880251a8d00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
    
    Fixes: 409c3b0c5f03 ("mac802154: tx: move stats tx increment")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Alexander Aring <alex.aring@gmail.com>
    Cc: Stefan Schmidt <stefan@datenfreihafen.org>
    Cc: linux-wpan@vger.kernel.org
    Link: https://lore.kernel.org/r/20200908104025.4009085-1-edumazet@google.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5bc41a812eeb05c4c9cc53ffc33e24dabdc321e
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Sep 3 19:00:52 2020 +0200

    netfilter: nft_meta: use socket user_ns to retrieve skuid and skgid
    
    [ Upstream commit 0c92411bb81de9bc516d6924f50289d8d5f880e5 ]
    
    ... instead of using init_user_ns.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Tested-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b47342e6341d706844b9cb2ce436f2eb80601543
Author: Eelco Chaudron <echaudro@redhat.com>
Date:   Tue Sep 1 16:56:02 2020 +0200

    netfilter: conntrack: nf_conncount_init is failing with IPv6 disabled
    
    [ Upstream commit 526e81b990e53e31ba40ba304a2285ffd098721f ]
    
    The openvswitch module fails initialization when used in a kernel
    without IPv6 enabled. nf_conncount_init() fails because the ct code
    unconditionally tries to initialize the netns IPv6 related bit,
    regardless of the build option. The change below ignores the IPv6
    part if not enabled.
    
    Note that the corresponding _put() function already has this IPv6
    configuration check.
    
    Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
    Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
    Reviewed-by: Simon Horman <simon.horman@netronome.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e38f49e00baf15d6eae9377647e15fc0962cf8cb
Author: Martin Willi <martin@strongswan.org>
Date:   Tue Sep 1 08:56:19 2020 +0200

    netfilter: ctnetlink: fix mark based dump filtering regression
    
    [ Upstream commit 6c0d95d1238d944fe54f0bbfc7ec017d78435daa ]
    
    conntrack mark based dump filtering may falsely skip entries if a mask
    is given: If the mask-based check does not filter out the entry, the
    else-if check is always true and compares the mark without considering
    the mask. The if/else-if logic seems wrong.
    
    Given that the mask during filter setup is implicitly set to 0xffffffff
    if not specified explicitly, the mark filtering flags seem to just
    complicate things. Restore the previously used approach by always
    matching against a zero mask is no filter mark is given.
    
    Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump")
    Signed-off-by: Martin Willi <martin@strongswan.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24c4f2ae019bfcd2a82783e07c2894a519eb1050
Author: Will McVicker <willmcvicker@google.com>
Date:   Mon Aug 24 19:38:32 2020 +0000

    netfilter: ctnetlink: add a range check for l3/l4 protonum
    
    [ Upstream commit 1cc5ef91d2ff94d2bf2de3b3585423e8a1051cb6 ]
    
    The indexes to the nf_nat_l[34]protos arrays come from userspace. So
    check the tuple's family, e.g. l3num, when creating the conntrack in
    order to prevent an OOB memory access during setup.  Here is an example
    kernel panic on 4.14.180 when userspace passes in an index greater than
    NFPROTO_NUMPROTO.
    
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:...
    Process poc (pid: 5614, stack limit = 0x00000000a3933121)
    CPU: 4 PID: 5614 Comm: poc Tainted: G S      W  O    4.14.180-g051355490483
    Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM
    task: 000000002a3dfffe task.stack: 00000000a3933121
    pc : __cfi_check_fail+0x1c/0x24
    lr : __cfi_check_fail+0x1c/0x24
    ...
    Call trace:
    __cfi_check_fail+0x1c/0x24
    name_to_dev_t+0x0/0x468
    nfnetlink_parse_nat_setup+0x234/0x258
    ctnetlink_parse_nat_setup+0x4c/0x228
    ctnetlink_new_conntrack+0x590/0xc40
    nfnetlink_rcv_msg+0x31c/0x4d4
    netlink_rcv_skb+0x100/0x184
    nfnetlink_rcv+0xf4/0x180
    netlink_unicast+0x360/0x770
    netlink_sendmsg+0x5a0/0x6a4
    ___sys_sendmsg+0x314/0x46c
    SyS_sendmsg+0xb4/0x108
    el0_svc_naked+0x34/0x38
    
    This crash is not happening since 5.4+, however, ctnetlink still
    allows for creating entries with unsupported layer 3 protocol number.
    
    Fixes: c1d10adb4a521 ("[NETFILTER]: Add ctnetlink port for nf_conntrack")
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    [pablo@netfilter.org: rebased original patch on top of nf.git]
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e49aff08701ca044a67d0293fd7a7393cc93709d
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Fri Sep 4 20:28:00 2020 +0200

    batman-adv: mcast/TT: fix wrongly dropped or rerouted packets
    
    [ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
    
    The unicast packet rerouting code makes several assumptions. For
    instance it assumes that there is always exactly one destination in the
    TT. This breaks for multicast frames in a unicast packets in several ways:
    
    For one thing if there is actually no TT entry and the destination node
    was selected due to the multicast tvlv flags it announced. Then an
    intermediate node will wrongly drop the packet.
    
    For another thing if there is a TT entry but the TTVN of this entry is
    newer than the originally addressed destination node: Then the
    intermediate node will wrongly redirect the packet, leading to
    duplicated multicast packets at a multicast listener and missing
    packets at other multicast listeners or multicast routers.
    
    Fixing this by not applying the unicast packet rerouting to batman-adv
    unicast packets with a multicast payload. We are not able to detect a
    roaming multicast listener at the moment and will just continue to send
    the multicast frame to both the new and old destination for a while in
    case of such a roaming multicast listener.
    
    Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27f214ea565b6b76af499ad4b0c038e1cb324b70
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Fri Sep 4 10:51:03 2020 +0800

    atm: eni: fix the missed pci_disable_device() for eni_init_one()
    
    [ Upstream commit c2b947879ca320ac5505c6c29a731ff17da5e805 ]
    
    eni_init_one() misses to call pci_disable_device() in an error path.
    Jump to err_disable to fix it.
    
    Fixes: ede58ef28e10 ("atm: remove deprecated use of pci api")
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c50fd3ecb3f77f5040b206661287a44dae41a8a6
Author: Tony Ambardar <tony.ambardar@gmail.com>
Date:   Sun Aug 30 17:03:04 2020 -0700

    libbpf: Fix build failure from uninitialized variable warning
    
    [ Upstream commit 3168c158ad3535af1cd7423c9f8cd5ac549f2f9c ]
    
    While compiling libbpf, some GCC versions (at least 8.4.0) have difficulty
    determining control flow and a emit warning for potentially uninitialized
    usage of 'map', which results in a build error if using "-Werror":
    
    In file included from libbpf.c:56:
    libbpf.c: In function '__bpf_object__open':
    libbpf_internal.h:59:2: warning: 'map' may be used uninitialized in this function [-Wmaybe-uninitialized]
      libbpf_print(level, "libbpf: " fmt, ##__VA_ARGS__); \
      ^~~~~~~~~~~~
    libbpf.c:5032:18: note: 'map' was declared here
      struct bpf_map *map, *targ_map;
                      ^~~
    
    The warning/error is false based on code inspection, so silence it with a
    NULL initialization.
    
    Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support")
    Reference: 063e68813391 ("libbpf: Fix false uninitialized variable warning")
    Signed-off-by: Tony Ambardar <Tony.Ambardar@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20200831000304.1696435-1-Tony.Ambardar@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5307da48a93258c5abb3a0367414d3a946fee19
Author: Linus Lüssing <ll@simonwunderlich.de>
Date:   Thu Aug 27 17:34:48 2020 +0200

    batman-adv: bla: fix type misuse for backbone_gw hash indexing
    
    [ Upstream commit 097930e85f90f252c44dc0d084598265dd44ca48 ]
    
    It seems that due to a copy & paste error the void pointer
    in batadv_choose_backbone_gw() is cast to the wrong type.
    
    Fixing this by using "struct batadv_bla_backbone_gw" instead of "struct
    batadv_bla_claim" which better matches the caller's side.
    
    For now it seems that we were lucky because the two structs both have
    their orig/vid and addr/vid in the beginning. However I stumbled over
    this issue when I was trying to add some debug variables in front of
    "orig" in batadv_backbone_gw, which caused hash lookups to fail.
    
    Fixes: 07568d0369f9 ("batman-adv: don't rely on positions in struct for hashing")
    Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 120333e77b209049836bddc009c2e156fc263673
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Tue Aug 25 17:38:29 2020 +0200

    mwifiex: Increase AES key storage size to 256 bits
    
    [ Upstream commit 4afc850e2e9e781976fb2c7852ce7bac374af938 ]
    
    Following commit e18696786548 ("mwifiex: Prevent memory corruption
    handling keys") the mwifiex driver fails to authenticate with certain
    networks, specifically networks with 256 bit keys, and repeatedly asks
    for the password. The kernel log repeats the following lines (id and
    bssid redacted):
    
        mwifiex_pcie 0000:01:00.0: info: trying to associate to '<id>' bssid <bssid>
        mwifiex_pcie 0000:01:00.0: info: associated to bssid <bssid> successfully
        mwifiex_pcie 0000:01:00.0: crypto keys added
        mwifiex_pcie 0000:01:00.0: info: successfully disconnected from <bssid>: reason code 3
    
    Tracking down this problem lead to the overflow check introduced by the
    aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This
    check fails on networks with 256 bit keys due to the current storage
    size for AES keys in struct mwifiex_aes_param being only 128 bit.
    
    To fix this issue, increase the storage size for AES keys to 256 bit.
    
    Fixes: e18696786548 ("mwifiex: Prevent memory corruption handling keys")
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Reported-by: Kaloyan Nikolov <konik98@gmail.com>
    Tested-by: Kaloyan Nikolov <konik98@gmail.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Brian Norris <briannorris@chromium.org>
    Tested-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab7eeefd46b5bf1d7d2b9be15fe306a19e0bc569
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Sun Aug 2 19:15:41 2020 +0800

    clocksource/drivers/h8300_timer8: Fix wrong return value in h8300_8timer_init()
    
    [ Upstream commit 400d033f5a599120089b5f0c54d14d198499af5a ]
    
    In the init function, if the call to of_iomap() fails, the return
    value is ENXIO instead of -ENXIO.
    
    Change to the right negative errno.
    
    Fixes: 691f8f878290f ("clocksource/drivers/h8300_timer8: Convert init function to return error")
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20200802111541.5429-1-tianjia.zhang@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bdcc262d50da7bc93c7766063802987311317ad7
Author: Tom Rix <trix@redhat.com>
Date:   Sun Aug 2 07:23:39 2020 -0700

    ieee802154/adf7242: check status of adf7242_read_reg
    
    [ Upstream commit e3914ed6cf44bfe1f169e26241f8314556fd1ac1 ]
    
    Clang static analysis reports this error
    
    adf7242.c:887:6: warning: Assigned value is garbage or undefined
            len = len_u8;
                ^ ~~~~~~
    
    len_u8 is set in
           adf7242_read_reg(lp, 0, &len_u8);
    
    When this call fails, len_u8 is not set.
    
    So check the return code.
    
    Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
    
    Signed-off-by: Tom Rix <trix@redhat.com>
    Acked-by: Michael Hennerich <michael.hennerich@analog.com>
    Link: https://lore.kernel.org/r/20200802142339.21091-1-trix@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59a84157c5a516c8d6e8c511ce09ecd50b7026d5
Author: Liu Jian <liujian56@huawei.com>
Date:   Mon Jul 20 22:33:15 2020 +0800

    ieee802154: fix one possible memleak in ca8210_dev_com_init
    
    [ Upstream commit 88f46b3fe2ac41c381770ebad9f2ee49346b57a2 ]
    
    We should call destroy_workqueue to destroy mlme_workqueue in error branch.
    
    Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Link: https://lore.kernel.org/r/20200720143315.40523-1-liujian56@huawei.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a04354bdb3a57cd70734dcdc849ab90e2a1fb47
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Wed Sep 16 16:59:41 2020 +0900

    riscv: Fix Kendryte K210 device tree
    
    [ Upstream commit f025d9d9934b84cd03b7796072d10686029c408e ]
    
    The Kendryte K210 SoC CLINT is compatible with Sifive clint v0
    (sifive,clint0). Fix the Kendryte K210 device tree clint entry to be
    inline with the sifive timer definition documented in
    Documentation/devicetree/bindings/timer/sifive,clint.yaml.
    The device tree clint entry is renamed similarly to u-boot device tree
    definition to improve compatibility with u-boot defined device tree.
    To ensure correct initialization, the interrup-cells attribute is added
    and the interrupt-extended attribute definition fixed.
    
    This fixes boot failures with Kendryte K210 SoC boards.
    
    Note that the clock referenced is kept as K210_CLK_ACLK, which does not
    necessarilly match the clint MTIME increment rate. This however does not
    seem to cause any problem for now.
    
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b05a20baaa2f2f24d5d10d6684bee7ad7124cc76
Author: Qii Wang <qii.wang@mediatek.com>
Date:   Thu Sep 17 19:55:42 2020 +0800

    i2c: mediatek: Send i2c master code at more than 1MHz
    
    [ Upstream commit b44658e755b5a733e9df04449facbc738df09170 ]
    
    The master code needs to being sent when the speed is more than
    I2C_MAX_FAST_MODE_PLUS_FREQ, not I2C_MAX_FAST_MODE_FREQ in the
    latest I2C-bus specification and user manual.
    
    Signed-off-by: Qii Wang <qii.wang@mediatek.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 337e96e14843d06e69c53858e86d4f97f4cb7274
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Sep 10 10:24:57 2020 -0500

    objtool: Fix noreturn detection for ignored functions
    
    [ Upstream commit db6c6a0df840e3f52c84cc302cc1a08ba11a4416 ]
    
    When a function is annotated with STACK_FRAME_NON_STANDARD, objtool
    doesn't validate its code paths.  It also skips sibling call detection
    within the function.
    
    But sibling call detection is actually needed for the case where the
    ignored function doesn't have any return instructions.  Otherwise
    objtool naively marks the function as implicit static noreturn, which
    affects the reachability of its callers, resulting in "unreachable
    instruction" warnings.
    
    Fix it by just enabling sibling call detection for ignored functions.
    The 'insn->ignore' check in add_jump_destinations() is no longer needed
    after
    
      e6da9567959e ("objtool: Don't use ignore flag for fake jumps").
    
    Fixes the following warning:
    
      arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction
    
    which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset.
    
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 953fc770d069b167266d9d9ccfef0455fcfdc070
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Sep 9 12:32:33 2020 +0200

    i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()
    
    [ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ]
    
    Some ACPI i2c-devices _STA method (which is used to detect if the device
    is present) use autodetection code which probes which device is present
    over i2c. This requires the I2C ACPI OpRegion handler to be registered
    before we enumerate i2c-clients under the i2c-adapter.
    
    This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and
    ThinkBook 15 IIL not getting an i2c-client instantiated and thus not
    working.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55e8cc72415c92df8aa52c528d73bfe9685671c1
Author: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Date:   Tue Sep 15 17:26:29 2020 -0400

    drm/amd/display: Don't log hdcp module warnings in dmesg
    
    [ Upstream commit 875d369d8f75275d30e59421602d9366426abff7 ]
    
    [Why]
    DTM topology updates happens by default now. This results in DTM
    warnings when hdcp is not even being enabled. This spams the dmesg
    and doesn't effect normal display functionality so it is better to log it
    using DRM_DEBUG_KMS()
    
    [How]
    Change the DRM_WARN() to DRM_DEBUG_KMS()
    
    Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a42f8e6ba427ac8bf6094dc1eba556bbc6f304d0
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Sep 4 12:43:04 2020 +0200

    drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
    
    [ Upstream commit 2f228aab21bbc74e90e267a721215ec8be51daf7 ]
    
    Don't check drm_crtc_state::active for this either, per its
    documentation in include/drm/drm_crtc.h:
    
     * Hence drivers must not consult @active in their various
     * &drm_mode_config_funcs.atomic_check callback to reject an atomic
     * commit.
    
    atomic_remove_fb disables the CRTC as needed for disabling the primary
    plane.
    
    This prevents at least the following problems if the primary plane gets
    disabled (e.g. due to destroying the FB assigned to the primary plane,
    as happens e.g. with mutter in Wayland mode):
    
    * The legacy cursor ioctl returned EINVAL for a non-0 cursor FB ID
      (which enables the cursor plane).
    * If the cursor plane was enabled, changing the legacy DPMS property
      value from off to on returned EINVAL.
    
    v2:
    * Minor changes to code comment and commit log, per review feedback.
    
    GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1108
    GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1165
    GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1344
    Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5535013c64fb18c9f7b6e12eafb7624f0fe1adb6
Author: Jun Lei <jun.lei@amd.com>
Date:   Thu Sep 3 16:17:46 2020 -0400

    drm/amd/display: update nv1x stutter latencies
    
    [ Upstream commit c4790a8894232f39c25c7c546c06efe074e63384 ]
    
    [why]
    Recent characterization shows increased stutter latencies on some SKUs,
    leading to underflow.
    
    [how]
    Update SOC params to account for this worst case latency.
    
    Signed-off-by: Jun Lei <jun.lei@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3adac3cfbdb522f5498220e1ea4a1b233b10276
Author: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Date:   Fri Aug 28 11:09:38 2020 -0400

    drm/amd/display: Don't use DRM_ERROR() for DTM add topology
    
    [ Upstream commit 4cdd7b332ed139b1e37faeb82409a14490adb644 ]
    
    [Why]
    Previously we were only calling add_topology when hdcp was being enabled.
    Now we call add_topology by default so the ERROR messages are printed if
    the firmware is not loaded.
    
    This error message is not relevant for normal display functionality so
    no need to print a ERROR message.
    
    [How]
    Change DRM_ERROR to DRM_INFO
    
    Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f85ebcc0e9d612a801b3b56e3af291aff36146f
Author: Dennis Li <Dennis.Li@amd.com>
Date:   Wed Sep 2 17:11:09 2020 +0800

    drm/amdkfd: fix a memory leak issue
    
    [ Upstream commit 087d764159996ae378b08c0fdd557537adfd6899 ]
    
    In the resume stage of GPU recovery, start_cpsch will call pm_init
    which set pm->allocated as false, cause the next pm_release_ib has
    no chance to release ib memory.
    
    Add pm_release_ib in stop_cpsch which will be called in the suspend
    stage of GPU recovery.
    
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Dennis Li <Dennis.Li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f9f1a29290ca2daa60c8f84e2afc1c4e4b86a9e
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Sep 11 18:17:30 2020 +0200

    EDAC/ghes: Check whether the driver is on the safe list correctly
    
    [ Upstream commit 251c54ea26fa6029b01a76161a37a12fde5124e4 ]
    
    With CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, a system would try to probe,
    unregister and probe again a driver.
    
    When ghes_edac is attempted to be loaded on a system which is not on
    the safe platforms list, ghes_edac_register() would return early. The
    unregister counterpart ghes_edac_unregister() would still attempt to
    unregister and exit early at the refcount test, leading to the refcount
    underflow below.
    
    In order to not do *anything* on the unregister path too, reuse the
    force_load parameter and check it on that path too, before fumbling with
    the refcount.
    
      ghes_edac: ghes_edac_register: entry
      ghes_edac: ghes_edac_register: return -ENODEV
      ------------[ cut here ]------------
      refcount_t: underflow; use-after-free.
      WARNING: CPU: 10 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xb9/0x100
      Modules linked in:
      CPU: 10 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #12
      Hardware name: GIGABYTE MZ01-CE1-00/MZ01-CE1-00, BIOS F02 08/29/2018
      RIP: 0010:refcount_warn_saturate+0xb9/0x100
      Code: 82 e8 fb 8f 4d 00 90 0f 0b 90 90 c3 80 3d 55 4c f5 00 00 75 88 c6 05 4c 4c f5 00 01 90 48 c7 c7 d0 8a 10 82 e8 d8 8f 4d 00 90 <0f> 0b 90 90 c3 80 3d 30 4c f5 00 00 0f 85 61 ff ff ff c6 05 23 4c
      RSP: 0018:ffffc90000037d58 EFLAGS: 00010292
      RAX: 0000000000000026 RBX: ffff88840b8da000 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: ffffffff8216b24f RDI: 00000000ffffffff
      RBP: ffff88840c662e00 R08: 0000000000000001 R09: 0000000000000001
      R10: 0000000000000001 R11: 0000000000000046 R12: 0000000000000000
      R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88840ee80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000800002211000 CR4: 00000000003506e0
      Call Trace:
       ghes_edac_unregister
       ghes_remove
       platform_drv_remove
       really_probe
       driver_probe_device
       device_driver_attach
       __driver_attach
       ? device_driver_attach
       ? device_driver_attach
       bus_for_each_dev
       bus_add_driver
       driver_register
       ? bert_init
       ghes_init
       do_one_initcall
       ? rcu_read_lock_sched_held
       kernel_init_freeable
       ? rest_init
       kernel_init
       ret_from_fork
       ...
      ghes_edac: ghes_edac_unregister: FALSE, refcount: -1073741824
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20200911164950.GB19320@zn.tnic
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c98a2f74a07dcfcd6deaf92074a6f3e3852469b
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Sep 10 12:24:53 2020 +0200

    lockdep: fix order in trace_hardirqs_off_caller()
    
    [ Upstream commit 73ac74c7d489756d2313219a108809921dbfaea1 ]
    
    Switch order so that locking state is consistent even
    if the IRQ tracer calls into lockdep again.
    
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cf6f7188ad2466a37c53947acc6031c6674eff5
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Wed Sep 9 14:27:25 2020 +0200

    s390/init: add missing __init annotations
    
    [ Upstream commit fcb2b70cdb194157678fb1a75f9ff499aeba3d2a ]
    
    Add __init to reserve_memory_end, reserve_oldmem and remove_oldmem.
    Sometimes these functions are not inlined, and then the build
    complains about section mismatch.
    
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7b5742eb70b2a168b43d5a2cbaf90bff18ae636
Author: Eddie James <eajames@linux.ibm.com>
Date:   Wed Sep 9 15:30:57 2020 -0500

    i2c: aspeed: Mask IRQ status to relevant bits
    
    [ Upstream commit 1a1d6db23ddacde0b15ea589e9103373e05af8de ]
    
    Mask the IRQ status to only the bits that the driver checks. This
    prevents excessive driver warnings when operating in slave mode
    when additional bits are set that the driver doesn't handle.
    
    Signed-off-by: Eddie James <eajames@linux.ibm.com>
    Reviewed-by: Tao Ren <rentao.bupt@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af5681dfa0aaf4fc96f1bd1dfb00a39270107053
Author: Palmer Dabbelt <palmerdabbelt@google.com>
Date:   Mon Aug 24 17:21:22 2020 -0700

    RISC-V: Take text_mutex in ftrace_init_nop()
    
    [ Upstream commit 66d18dbda8469a944dfec6c49d26d5946efba218 ]
    
    Without this we get lockdep failures.  They're spurious failures as SMP isn't
    up when ftrace_init_nop() is called.  As far as I can tell the easiest fix is
    to just take the lock, which also seems like the safest fix.
    
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Acked-by: Guo Ren <guoren@kernel.org>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a73735ee5b2d24372bcb9627083577c31763d3c
Author: Sumera Priyadarsini <sylphrenadin@gmail.com>
Date:   Sat Aug 29 23:27:04 2020 +0530

    clk: versatile: Add of_node_put() before return statement
    
    [ Upstream commit da9c43dc0e2ec5c42a3d414e389feb30467000e2 ]
    
    Every iteration of for_each_available_child_of_node() decrements
    the reference count of the previous node, however when control is
    transferred from the middle of the loop, as in the case of a return
    or break or goto, there is no decrement thus ultimately resulting in
    a memory leak.
    
    Fix a potential memory leak in clk-impd1.c by inserting
    of_node_put() before a return statement.
    
    Issue found with Coccinelle.
    
    Signed-off-by: Sumera Priyadarsini <sylphrenadin@gmail.com>
    Link: https://lore.kernel.org/r/20200829175704.GA10998@Kaladin
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39f785132eee9871cb67e340454073d20014b2c9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Sep 1 10:06:23 2020 +0200

    ASoC: Intel: bytcr_rt5640: Add quirk for MPMAN Converter9 2-in-1
    
    [ Upstream commit 6a0137101f47301fff2da6ba4b9048383d569909 ]
    
    The MPMAN Converter9 2-in-1 almost fully works with out default settings.
    The only problem is that it has only 1 speaker so any sounds only playing
    on the right channel get lost.
    
    Add a quirk for this model using the default settings + MONO_SPEAKER.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20200901080623.4987-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 700fefbe8c672795b1d4bf8328682bc91cbf3e51
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Thu Aug 27 19:33:57 2020 +0200

    ASoC: wm8994: Ensure the device is resumed in wm89xx_mic_detect functions
    
    [ Upstream commit f5a2cda4f1db89776b64c4f0f2c2ac609527ac70 ]
    
    When the wm8958_mic_detect, wm8994_mic_detect functions get called from
    the machine driver, e.g. from the card's late_probe() callback, the CODEC
    device may be PM runtime suspended and any regmap writes have no effect.
    Add PM runtime calls to these functions to ensure the device registers
    are updated as expected.
    This suppresses an error during boot
    "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
    caused by the regmap access error due to the cache_only flag being set.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20200827173357.31891-2-s.nawrocki@samsung.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e1e2b748af2a1b76ae5e9fd2abf2bcd701fc4f4
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Thu Aug 27 19:33:56 2020 +0200

    ASoC: wm8994: Skip setting of the WM8994_MICBIAS register for WM1811
    
    [ Upstream commit 811c5494436789e7149487c06e0602b507ce274b ]
    
    The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip
    initialization of that register for that device.
    This suppresses an error during boot:
    "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20200827173357.31891-1-s.nawrocki@samsung.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad22ff03adc6182c98ff0b406f90f3afd6329d91
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Aug 25 08:39:24 2020 +0900

    ASoC: pcm3168a: ignore 0 Hz settings
    
    [ Upstream commit 7ad26d6671db758c959d7e1d100b138a38483612 ]
    
    Some sound card try to set 0 Hz as reset, but it is impossible.
    This patch ignores it to avoid error return.
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/87a6yjy5sy.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b2f403ff302a81feee54e30762601646bc2caea
Author: Amol Grover <frextrite@gmail.com>
Date:   Mon Apr 6 16:29:50 2020 +0530

    device_cgroup: Fix RCU list debugging warning
    
    [ Upstream commit bc62d68e2a0a69fcdcf28aca8edb01abf306b698 ]
    
    exceptions may be traversed using list_for_each_entry_rcu()
    outside of an RCU read side critical section BUT under the
    protection of decgroup_mutex. Hence add the corresponding
    lockdep expression to fix the following false-positive
    warning:
    
    [    2.304417] =============================
    [    2.304418] WARNING: suspicious RCU usage
    [    2.304420] 5.5.4-stable #17 Tainted: G            E
    [    2.304422] -----------------------------
    [    2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader section!!
    
    Signed-off-by: Amol Grover <frextrite@gmail.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>