commit 506355630487f6d21c79aa1636d0f4feb1c65b6f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 9 10:20:08 2020 +0100

    Linux 5.4.9

commit 3a43ea27478705a5b877b5069be95ce2cd644a27
Author: Waiman Long <longman@redhat.com>
Date:   Sat Jan 4 13:00:15 2020 -0800

    mm/hugetlb: defer freeing of huge pages if in non-task context
    
    [ Upstream commit c77c0a8ac4c522638a8242fcb9de9496e3cdbb2d ]
    
    The following lockdep splat was observed when a certain hugetlbfs test
    was run:
    
      ================================
      WARNING: inconsistent lock state
      4.18.0-159.el8.x86_64+debug #1 Tainted: G        W --------- -  -
      --------------------------------
      inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      swapper/30/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      ffffffff9acdc038 (hugetlb_lock){+.?.}, at: free_huge_page+0x36f/0xaa0
      {SOFTIRQ-ON-W} state was registered at:
        lock_acquire+0x14f/0x3b0
        _raw_spin_lock+0x30/0x70
        __nr_hugepages_store_common+0x11b/0xb30
        hugetlb_sysctl_handler_common+0x209/0x2d0
        proc_sys_call_handler+0x37f/0x450
        vfs_write+0x157/0x460
        ksys_write+0xb8/0x170
        do_syscall_64+0xa5/0x4d0
        entry_SYSCALL_64_after_hwframe+0x6a/0xdf
      irq event stamp: 691296
      hardirqs last  enabled at (691296): [<ffffffff99bb034b>] _raw_spin_unlock_irqrestore+0x4b/0x60
      hardirqs last disabled at (691295): [<ffffffff99bb0ad2>] _raw_spin_lock_irqsave+0x22/0x81
      softirqs last  enabled at (691284): [<ffffffff97ff0c63>] irq_enter+0xc3/0xe0
      softirqs last disabled at (691285): [<ffffffff97ff0ebe>] irq_exit+0x23e/0x2b0
    
      other info that might help us debug this:
       Possible unsafe locking scenario:
    
             CPU0
             ----
        lock(hugetlb_lock);
        <Interrupt>
          lock(hugetlb_lock);
    
       *** DEADLOCK ***
          :
      Call Trace:
       <IRQ>
       __lock_acquire+0x146b/0x48c0
       lock_acquire+0x14f/0x3b0
       _raw_spin_lock+0x30/0x70
       free_huge_page+0x36f/0xaa0
       bio_check_pages_dirty+0x2fc/0x5c0
       clone_endio+0x17f/0x670 [dm_mod]
       blk_update_request+0x276/0xe50
       scsi_end_request+0x7b/0x6a0
       scsi_io_completion+0x1c6/0x1570
       blk_done_softirq+0x22e/0x350
       __do_softirq+0x23d/0xad8
       irq_exit+0x23e/0x2b0
       do_IRQ+0x11a/0x200
       common_interrupt+0xf/0xf
       </IRQ>
    
    Both the hugetbl_lock and the subpool lock can be acquired in
    free_huge_page().  One way to solve the problem is to make both locks
    irq-safe.  However, Mike Kravetz had learned that the hugetlb_lock is
    held for a linear scan of ALL hugetlb pages during a cgroup reparentling
    operation.  So it is just too long to have irq disabled unless we can
    break hugetbl_lock down into finer-grained locks with shorter lock hold
    times.
    
    Another alternative is to defer the freeing to a workqueue job.  This
    patch implements the deferred freeing by adding a free_hpage_workfn()
    work function to do the actual freeing.  The free_huge_page() call in a
    non-task context saves the page to be freed in the hpage_freelist linked
    list in a lockless manner using the llist APIs.
    
    The generic workqueue is used to process the work, but a dedicated
    workqueue can be used instead if it is desirable to have the huge page
    freed ASAP.
    
    Thanks to Kirill Tkhai <ktkhai@virtuozzo.com> for suggesting the use of
    llist APIs which simplfy the code.
    
    Link: http://lkml.kernel.org/r/20191217170331.30893-1-longman@redhat.com
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Davidlohr Bueso <dbueso@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fc906e60301f79c5e49243e81754691d4170f02
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun Dec 22 11:26:54 2019 +0000

    hsr: fix a race condition in node list insertion and deletion
    
    [ Upstream commit 92a35678ec075100ce666a2fb6969151affb0e5d ]
    
    hsr nodes are protected by RCU and there is no write side lock.
    But node insertions and deletions could be being operated concurrently.
    So write side locking is needed.
    
    Test commands:
        ip netns add nst
        ip link add veth0 type veth peer name veth1
        ip link add veth2 type veth peer name veth3
        ip link set veth1 netns nst
        ip link set veth3 netns nst
        ip link set veth0 up
        ip link set veth2 up
        ip link add hsr0 type hsr slave1 veth0 slave2 veth2
        ip a a 192.168.100.1/24 dev hsr0
        ip link set hsr0 up
        ip netns exec nst ip link set veth1 up
        ip netns exec nst ip link set veth3 up
        ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3
        ip netns exec nst ip a a 192.168.100.2/24 dev hsr1
        ip netns exec nst ip link set hsr1 up
    
        for i in {0..9}
        do
            for j in {0..9}
            do
                for k in {0..9}
                do
                    for l in {0..9}
                    do
                    arping 192.168.100.2 -I hsr0 -s 00:01:3$i:4$j:5$k:6$l -c1 &
                    done
                done
            done
        done
    
    Splat looks like:
    [  236.066091][ T3286] list_add corruption. next->prev should be prev (ffff8880a5940300), but was ffff8880a5940d0.
    [  236.069617][ T3286] ------------[ cut here ]------------
    [  236.070545][ T3286] kernel BUG at lib/list_debug.c:25!
    [  236.071391][ T3286] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
    [  236.072343][ T3286] CPU: 0 PID: 3286 Comm: arping Tainted: G        W         5.5.0-rc1+ #209
    [  236.073463][ T3286] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    [  236.074695][ T3286] RIP: 0010:__list_add_valid+0x74/0xd0
    [  236.075499][ T3286] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 b
    [  236.078277][ T3286] RSP: 0018:ffff8880aaa97648 EFLAGS: 00010286
    [  236.086991][ T3286] RAX: 0000000000000075 RBX: ffff8880d4624c20 RCX: 0000000000000000
    [  236.088000][ T3286] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed1015552ebf
    [  236.098897][ T3286] RBP: ffff88809b53d200 R08: ffffed101b3c04f9 R09: ffffed101b3c04f9
    [  236.099960][ T3286] R10: 00000000308769a1 R11: ffffed101b3c04f8 R12: ffff8880d4624c28
    [  236.100974][ T3286] R13: ffff8880d4624c20 R14: 0000000040310100 R15: ffff8880ce17ee02
    [  236.138967][ T3286] FS:  00007f23479fa680(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
    [  236.144852][ T3286] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  236.145720][ T3286] CR2: 00007f4a14bab210 CR3: 00000000a61c6001 CR4: 00000000000606f0
    [  236.146776][ T3286] Call Trace:
    [  236.147222][ T3286]  hsr_add_node+0x314/0x490 [hsr]
    [  236.153633][ T3286]  hsr_forward_skb+0x2b6/0x1bc0 [hsr]
    [  236.154362][ T3286]  ? rcu_read_lock_sched_held+0x90/0xc0
    [  236.155091][ T3286]  ? rcu_read_lock_bh_held+0xa0/0xa0
    [  236.156607][ T3286]  hsr_dev_xmit+0x70/0xd0 [hsr]
    [  236.157254][ T3286]  dev_hard_start_xmit+0x160/0x740
    [  236.157941][ T3286]  __dev_queue_xmit+0x1961/0x2e10
    [  236.158565][ T3286]  ? netdev_core_pick_tx+0x2e0/0x2e0
    [ ... ]
    
    Reported-by: syzbot+3924327f9ad5f4d2b343@syzkaller.appspotmail.com
    Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe974fba4ee5da900e30d2d5b9e80b4a4e137186
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun Dec 22 11:26:15 2019 +0000

    hsr: fix error handling routine in hsr_dev_finalize()
    
    [ Upstream commit 1d19e2d53e8ed9e4c98fc95e0067492cda7288b0 ]
    
    hsr_dev_finalize() is called to create new hsr interface.
    There are some wrong error handling codes.
    
    1. wrong checking return value of debugfs_create_{dir/file}.
    These function doesn't return NULL. If error occurs in there,
    it returns error pointer.
    So, it should check error pointer instead of NULL.
    
    2. It doesn't unregister interface if it fails to setup hsr interface.
    If it fails to initialize hsr interface after register_netdevice(),
    it should call unregister_netdevice().
    
    3. Ignore failure of creation of debugfs
    If creating of debugfs dir and file is failed, creating hsr interface
    will be failed. But debugfs doesn't affect actual logic of hsr module.
    So, ignoring this is more correct and this behavior is more general.
    
    Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fa51bbdf7c241f969d3895e07ab45657fb5cc10
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun Dec 22 11:25:27 2019 +0000

    hsr: avoid debugfs warning message when module is remove
    
    [ Upstream commit 84bb59d773853bc2dda2ac1ef8474c40eb33a3c6 ]
    
    When hsr module is being removed, debugfs_remove() is called to remove
    both debugfs directory and file.
    
    When module is being removed, module state is changed to
    MODULE_STATE_GOING then exit() is called.
    At this moment, module couldn't be held so try_module_get()
    will be failed.
    
    debugfs's open() callback tries to hold the module if .owner is existing.
    If it fails, warning message is printed.
    
    CPU0                            CPU1
    delete_module()
        try_stop_module()
        hsr_exit()                  open() <-- WARNING
            debugfs_remove()
    
    In order to avoid the warning message, this patch makes hsr module does
    not set .owner. Unsetting .owner is safe because these are protected by
    inode_lock().
    
    Test commands:
        #SHELL1
        ip link add dummy0 type dummy
        ip link add dummy1 type dummy
        while :
        do
            ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1
            modprobe -rv hsr
        done
    
        #SHELL2
        while :
        do
            cat /sys/kernel/debug/hsr0/node_table
        done
    
    Splat looks like:
    [  101.223783][ T1271] ------------[ cut here ]------------
    [  101.230309][ T1271] debugfs file owner did not clean up at exit: node_table
    [  101.230380][ T1271] WARNING: CPU: 3 PID: 1271 at fs/debugfs/file.c:309 full_proxy_open+0x10f/0x650
    [  101.233153][ T1271] Modules linked in: hsr(-) dummy veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_d]
    [  101.237112][ T1271] CPU: 3 PID: 1271 Comm: cat Tainted: G        W         5.5.0-rc1+ #204
    [  101.238270][ T1271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    [  101.240379][ T1271] RIP: 0010:full_proxy_open+0x10f/0x650
    [  101.241166][ T1271] Code: 48 c1 ea 03 80 3c 02 00 0f 85 c1 04 00 00 49 8b 3c 24 e8 04 86 7e ff 84 c0 75 2d 4c 8
    [  101.251985][ T1271] RSP: 0018:ffff8880ca22fa38 EFLAGS: 00010286
    [  101.273355][ T1271] RAX: dffffc0000000008 RBX: ffff8880cc6e6200 RCX: 0000000000000000
    [  101.274466][ T1271] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8880c4dd5c14
    [  101.275581][ T1271] RBP: 0000000000000000 R08: fffffbfff2922f5d R09: 0000000000000000
    [  101.276733][ T1271] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc0551bc0
    [  101.277853][ T1271] R13: ffff8880c4059a48 R14: ffff8880be50a5e0 R15: ffffffff941adaa0
    [  101.278956][ T1271] FS:  00007f8871cda540(0000) GS:ffff8880da800000(0000) knlGS:0000000000000000
    [  101.280216][ T1271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  101.282832][ T1271] CR2: 00007f88717cfd10 CR3: 00000000b9440005 CR4: 00000000000606e0
    [  101.283974][ T1271] Call Trace:
    [  101.285328][ T1271]  do_dentry_open+0x63c/0xf50
    [  101.286077][ T1271]  ? open_proxy_open+0x270/0x270
    [  101.288271][ T1271]  ? __x64_sys_fchdir+0x180/0x180
    [  101.288987][ T1271]  ? inode_permission+0x65/0x390
    [  101.289682][ T1271]  path_openat+0x701/0x2810
    [  101.290294][ T1271]  ? path_lookupat+0x880/0x880
    [  101.290957][ T1271]  ? check_chain_key+0x236/0x5d0
    [  101.291676][ T1271]  ? __lock_acquire+0xdfe/0x3de0
    [  101.292358][ T1271]  ? sched_clock+0x5/0x10
    [  101.292962][ T1271]  ? sched_clock_cpu+0x18/0x170
    [  101.293644][ T1271]  ? find_held_lock+0x39/0x1d0
    [  101.305616][ T1271]  do_filp_open+0x17a/0x270
    [  101.306061][ T1271]  ? may_open_dev+0xc0/0xc0
    [ ... ]
    
    Fixes: fc4ecaeebd26 ("net: hsr: add debugfs support for display node list")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f8e806c51925abae56007ad2560a3356a6de52e
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Dec 16 18:51:03 2019 -0800

    net: annotate lockless accesses to sk->sk_pacing_shift
    
    [ Upstream commit 7c68fa2bddda6d942bd387c9ba5b4300737fd991 ]
    
    sk->sk_pacing_shift can be read and written without lock
    synchronization. This patch adds annotations to
    document this fact and avoid future syzbot complains.
    
    This might also avoid unexpected false sharing
    in sk_pacing_shift_update(), as the compiler
    could remove the conditional check and always
    write over sk->sk_pacing_shift :
    
    if (sk->sk_pacing_shift != val)
            sk->sk_pacing_shift = val;
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c446b34afb071add598c3a8acff53b13c9e5df9
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Thu Dec 5 17:28:52 2019 +0300

    perf/x86/intel/bts: Fix the use of page_private()
    
    [ Upstream commit ff61541cc6c1962957758ba433c574b76f588d23 ]
    
    Commit
    
      8062382c8dbe2 ("perf/x86/intel/bts: Add BTS PMU driver")
    
    brought in a warning with the BTS buffer initialization
    that is easily tripped with (assuming KPTI is disabled):
    
    instantly throwing:
    
    > ------------[ cut here ]------------
    > WARNING: CPU: 2 PID: 326 at arch/x86/events/intel/bts.c:86 bts_buffer_setup_aux+0x117/0x3d0
    > Modules linked in:
    > CPU: 2 PID: 326 Comm: perf Not tainted 5.4.0-rc8-00291-gceb9e77324fa #904
    > RIP: 0010:bts_buffer_setup_aux+0x117/0x3d0
    > Call Trace:
    >  rb_alloc_aux+0x339/0x550
    >  perf_mmap+0x607/0xc70
    >  mmap_region+0x76b/0xbd0
    ...
    
    It appears to assume (for lost raisins) that PagePrivate() is set,
    while later it actually tests for PagePrivate() before using
    page_private().
    
    Make it consistent and always check PagePrivate() before using
    page_private().
    
    Fixes: 8062382c8dbe2 ("perf/x86/intel/bts: Add BTS PMU driver")
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Link: https://lkml.kernel.org/r/20191205142853.28894-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 618ab2e3c1ee713517b881b5038a9a1cef51aa7f
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Dec 10 10:09:45 2019 +0100

    efi: Don't attempt to map RCI2 config table if it doesn't exist
    
    [ Upstream commit a470552ee8965da0fe6fd4df0aa39c4cda652c7c ]
    
    Commit:
    
      1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs")
    
    ... added support for a Dell specific UEFI configuration table, but
    failed to take into account that mapping the table should not be
    attempted unless the table actually exists. If it doesn't exist,
    the code usually fails silently unless pr_debug() prints are
    enabled. However, on 32-bit PAE x86, the splat below is produced due
    to the attempt to map the placeholder value EFI_INVALID_TABLE_ADDR
    which we use for non-existing UEFI configuration tables, and which
    equals ULONG_MAX.
    
       memremap attempted on mixed range 0x00000000ffffffff size: 0x1e
       WARNING: CPU: 1 PID: 1 at kernel/iomem.c:81 memremap+0x1a3/0x1c0
       Modules linked in:
       CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.2-smp-mine #1
       Hardware name: Hewlett-Packard HP Z400 Workstation/0B4Ch, BIOS 786G3 v03.61 03/05/2018
       EIP: memremap+0x1a3/0x1c0
      ...
       Call Trace:
        ? map_properties+0x473/0x473
        ? efi_rci2_sysfs_init+0x2c/0x154
        ? map_properties+0x473/0x473
        ? do_one_initcall+0x49/0x1d4
        ? parse_args+0x1e8/0x2a0
        ? do_early_param+0x7a/0x7a
        ? kernel_init_freeable+0x139/0x1c2
        ? rest_init+0x8e/0x8e
        ? kernel_init+0xd/0xf2
        ? ret_from_fork+0x2e/0x38
    
    Fix this by checking whether the table exists before attempting to map it.
    
    Reported-by: Richard Narron <comet.berkeley@gmail.com>
    Tested-by: Richard Narron <comet.berkeley@gmail.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: linux-efi@vger.kernel.org
    Fixes: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs")
    Link: https://lkml.kernel.org/r/20191210090945.11501-2-ardb@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 735e7a12a639c6c196ac1acf41f024f84281e491
Author: Julien Grall <julien.grall@arm.com>
Date:   Wed Dec 4 16:52:53 2019 -0800

    lib/ubsan: don't serialize UBSAN report
    
    [ Upstream commit ce5c31db3645b649a31044a4d8b6057f6c723702 ]
    
    At the moment, UBSAN report will be serialized using a spin_lock().  On
    RT-systems, spinlocks are turned to rt_spin_lock and may sleep.  This
    will result to the following splat if the undefined behavior is in a
    context that can sleep:
    
      BUG: sleeping function called from invalid context at /src/linux/kernel/locking/rtmutex.c:968
      in_atomic(): 1, irqs_disabled(): 128, pid: 3447, name: make
      1 lock held by make/3447:
       #0: 000000009a966332 (&mm->mmap_sem){++++}, at: do_page_fault+0x140/0x4f8
      irq event stamp: 6284
      hardirqs last  enabled at (6283): [<ffff000011326520>] _raw_spin_unlock_irqrestore+0x90/0xa0
      hardirqs last disabled at (6284): [<ffff0000113262b0>] _raw_spin_lock_irqsave+0x30/0x78
      softirqs last  enabled at (2430): [<ffff000010088ef8>] fpsimd_restore_current_state+0x60/0xe8
      softirqs last disabled at (2427): [<ffff000010088ec0>] fpsimd_restore_current_state+0x28/0xe8
      Preemption disabled at:
      [<ffff000011324a4c>] rt_mutex_futex_unlock+0x4c/0xb0
      CPU: 3 PID: 3447 Comm: make Tainted: G        W         5.2.14-rt7-01890-ge6e057589653 #911
      Call trace:
        dump_backtrace+0x0/0x148
        show_stack+0x14/0x20
        dump_stack+0xbc/0x104
        ___might_sleep+0x154/0x210
        rt_spin_lock+0x68/0xa0
        ubsan_prologue+0x30/0x68
        handle_overflow+0x64/0xe0
        __ubsan_handle_add_overflow+0x10/0x18
        __lock_acquire+0x1c28/0x2a28
        lock_acquire+0xf0/0x370
        _raw_spin_lock_irqsave+0x58/0x78
        rt_mutex_futex_unlock+0x4c/0xb0
        rt_spin_unlock+0x28/0x70
        get_page_from_freelist+0x428/0x2b60
        __alloc_pages_nodemask+0x174/0x1708
        alloc_pages_vma+0x1ac/0x238
        __handle_mm_fault+0x4ac/0x10b0
        handle_mm_fault+0x1d8/0x3b0
        do_page_fault+0x1c8/0x4f8
        do_translation_fault+0xb8/0xe0
        do_mem_abort+0x3c/0x98
        el0_da+0x20/0x24
    
    The spin_lock() will protect against multiple CPUs to output a report
    together, I guess to prevent them from being interleaved.  However, they
    can still interleave with other messages (and even splat from
    __might_sleep).
    
    So the lock usefulness seems pretty limited.  Rather than trying to
    accomodate RT-system by switching to a raw_spin_lock(), the lock is now
    completely dropped.
    
    Link: http://lkml.kernel.org/r/20190920100835.14999-1-julien.grall@arm.com
    Signed-off-by: Julien Grall <julien.grall@arm.com>
    Reported-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50de69fd6e25a27998915cfd89aa95b362d6d189
Author: SeongJae Park <sjpark@amazon.de>
Date:   Tue Nov 26 16:36:05 2019 +0100

    xen/blkback: Avoid unmapping unmapped grant pages
    
    [ Upstream commit f9bd84a8a845d82f9b5a081a7ae68c98a11d2e84 ]
    
    For each I/O request, blkback first maps the foreign pages for the
    request to its local pages.  If an allocation of a local page for the
    mapping fails, it should unmap every mapping already made for the
    request.
    
    However, blkback's handling mechanism for the allocation failure does
    not mark the remaining foreign pages as unmapped.  Therefore, the unmap
    function merely tries to unmap every valid grant page for the request,
    including the pages not mapped due to the allocation failure.  On a
    system that fails the allocation frequently, this problem leads to
    following kernel crash.
    
      [  372.012538] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
      [  372.012546] IP: [<ffffffff814071ac>] gnttab_unmap_refs.part.7+0x1c/0x40
      [  372.012557] PGD 16f3e9067 PUD 16426e067 PMD 0
      [  372.012562] Oops: 0002 [#1] SMP
      [  372.012566] Modules linked in: act_police sch_ingress cls_u32
      ...
      [  372.012746] Call Trace:
      [  372.012752]  [<ffffffff81407204>] gnttab_unmap_refs+0x34/0x40
      [  372.012759]  [<ffffffffa0335ae3>] xen_blkbk_unmap+0x83/0x150 [xen_blkback]
      ...
      [  372.012802]  [<ffffffffa0336c50>] dispatch_rw_block_io+0x970/0x980 [xen_blkback]
      ...
      Decompressing Linux... Parsing ELF... done.
      Booting the kernel.
      [    0.000000] Initializing cgroup subsys cpuset
    
    This commit fixes this problem by marking the grant pages of the given
    request that didn't mapped due to the allocation failure as invalid.
    
    Fixes: c6cc142dac52 ("xen-blkback: use balloon pages for all mappings")
    
    Reviewed-by: David Woodhouse <dwmw@amazon.de>
    Reviewed-by: Maximilian Heyne <mheyne@amazon.de>
    Reviewed-by: Paul Durrant <pdurrant@amazon.co.uk>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    Signed-off-by: SeongJae Park <sjpark@amazon.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e71be1a60d881a4417b8f619d45e3ccfa7e548a
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Sat Nov 30 17:54:24 2019 -0800

    mm/sparse.c: mark populate_section_memmap as __meminit
    
    [ Upstream commit 030eab4f9ffb469344c10a46bc02c5149db0a2a9 ]
    
    Building the kernel on s390 with -Og produces the following warning:
    
      WARNING: vmlinux.o(.text+0x28dabe): Section mismatch in reference from the function populate_section_memmap() to the function .meminit.text:__populate_section_memmap()
      The function populate_section_memmap() references
      the function __meminit __populate_section_memmap().
      This is often because populate_section_memmap lacks a __meminit
      annotation or the annotation of __populate_section_memmap is wrong.
    
    While -Og is not supported, in theory this might still happen with
    another compiler or on another architecture.  So fix this by using the
    correct section annotations.
    
    [iii@linux.ibm.com: v2]
      Link: http://lkml.kernel.org/r/20191030151639.41486-1-iii@linux.ibm.com
    Link: http://lkml.kernel.org/r/20191028165549.14478-1-iii@linux.ibm.com
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Oscar Salvador <OSalvador@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 536d7fa7fb10aa72b604dccfa0a0732a74e80d00
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Sun Nov 17 14:55:38 2019 +0100

    s390/smp: fix physical to logical CPU map for SMT
    
    [ Upstream commit 72a81ad9d6d62dcb79f7e8ad66ffd1c768b72026 ]
    
    If an SMT capable system is not IPL'ed from the first CPU the setup of
    the physical to logical CPU mapping is broken: the IPL core gets CPU
    number 0, but then the next core gets CPU number 1. Correct would be
    that all SMT threads of CPU 0 get the subsequent logical CPU numbers.
    
    This is important since a lot of code (like e.g. the CPU topology
    code) assumes that CPU maps are setup like this. If the mapping is
    broken the system will not IPL due to broken topology masks:
    
    [    1.716341] BUG: arch topology broken
    [    1.716342]      the SMT domain not a subset of the MC domain
    [    1.716343] BUG: arch topology broken
    [    1.716344]      the MC domain not a subset of the BOOK domain
    
    This scenario can usually not happen since LPARs are always IPL'ed
    from CPU 0 and also re-IPL is intiated from CPU 0. However older
    kernels did initiate re-IPL on an arbitrary CPU. If therefore a re-IPL
    from an old kernel into a new kernel is initiated this may lead to
    crash.
    
    Fix this by setting up the physical to logical CPU mapping correctly.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e1269e147980f9f765c4d049058b2e8b000d196
Author: Chris Mason <clm@fb.com>
Date:   Wed Jul 10 12:28:16 2019 -0700

    Btrfs: only associate the locked page with one async_chunk struct
    
    [ Upstream commit 1d53c9e6723022b12e4a5ed4b141f67c834b7f6f ]
    
    The btrfs writepages function collects a large range of pages flagged
    for delayed allocation, and then sends them down through the COW code
    for processing.  When compression is on, we allocate one async_chunk
    structure for every 512K, and then run those pages through the
    compression code for IO submission.
    
    writepages starts all of this off with a single page, locked by the
    original call to extent_write_cache_pages(), and it's important to keep
    track of this page because it has already been through
    clear_page_dirty_for_io().
    
    The btrfs async_chunk struct has a pointer to the locked_page, and when
    we're redirtying the page because compression had to fallback to
    uncompressed IO, we use page->index to decide if a given async_chunk
    struct really owns that page.
    
    But, this is racey.  If a given delalloc range is broken up into two
    async_chunks (chunkA and chunkB), we can end up with something like
    this:
    
     compress_file_range(chunkA)
     submit_compress_extents(chunkA)
     submit compressed bios(chunkA)
     put_page(locked_page)
    
                                     compress_file_range(chunkB)
                                     ...
    
    Or:
    
     async_cow_submit
      submit_compressed_extents <--- falls back to buffered writeout
       cow_file_range
        extent_clear_unlock_delalloc
         __process_pages_contig
           put_page(locked_pages)
    
                                                async_cow_submit
    
    The end result is that chunkA is completed and cleaned up before chunkB
    even starts processing.  This means we can free locked_page() and reuse
    it elsewhere.  If we get really lucky, it'll have the same page->index
    in its new home as it did before.
    
    While we're processing chunkB, we might decide we need to fall back to
    uncompressed IO, and so compress_file_range() will call
    __set_page_dirty_nobufers() on chunkB->locked_page.
    
    Without cgroups in use, this creates as a phantom dirty page, which
    isn't great but isn't the end of the world. What can happen, it can go
    through the fixup worker and the whole COW machinery again:
    
    in submit_compressed_extents():
      while (async extents) {
      ...
        cow_file_range
        if (!page_started ...)
          extent_write_locked_range
        else if (...)
          unlock_page
        continue;
    
    This hasn't been observed in practice but is still possible.
    
    With cgroups in use, we might crash in the accounting code because
    page->mapping->i_wb isn't set.
    
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0
      IP: percpu_counter_add_batch+0x11/0x70
      PGD 66534e067 P4D 66534e067 PUD 66534f067 PMD 0
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      CPU: 16 PID: 2172 Comm: rm Not tainted
      RIP: 0010:percpu_counter_add_batch+0x11/0x70
      RSP: 0018:ffffc9000a97bbe0 EFLAGS: 00010286
      RAX: 0000000000000005 RBX: 0000000000000090 RCX: 0000000000026115
      RDX: 0000000000000030 RSI: ffffffffffffffff RDI: 0000000000000090
      RBP: 0000000000000000 R08: fffffffffffffff5 R09: 0000000000000000
      R10: 00000000000260c0 R11: ffff881037fc26c0 R12: ffffffffffffffff
      R13: ffff880fe4111548 R14: ffffc9000a97bc90 R15: 0000000000000001
      FS:  00007f5503ced480(0000) GS:ffff880ff7200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000000d0 CR3: 00000001e0459005 CR4: 0000000000360ee0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       account_page_cleaned+0x15b/0x1f0
       __cancel_dirty_page+0x146/0x200
       truncate_cleanup_page+0x92/0xb0
       truncate_inode_pages_range+0x202/0x7d0
       btrfs_evict_inode+0x92/0x5a0
       evict+0xc1/0x190
       do_unlinkat+0x176/0x280
       do_syscall_64+0x63/0x1a0
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    The fix here is to make asyc_chunk->locked_page NULL everywhere but the
    one async_chunk struct that's allowed to do things to the locked page.
    
    Link: https://lore.kernel.org/linux-btrfs/c2419d01-5c84-3fb4-189e-4db519d08796@suse.com/
    Fixes: 771ed689d2cd ("Btrfs: Optimize compressed writeback and reads")
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    [ update changelog from mail thread discussion ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bae3ee327c972896543c8f2f190568bbcf64b54
Author: Omar Sandoval <osandov@fb.com>
Date:   Mon Sep 16 11:30:57 2019 -0700

    btrfs: get rid of unique workqueue helper functions
    
    [ Upstream commit a0cac0ec961f0d42828eeef196ac2246a2f07659 ]
    
    Commit 9e0af2376434 ("Btrfs: fix task hang under heavy compressed
    write") worked around the issue that a recycled work item could get a
    false dependency on the original work item due to how the workqueue code
    guarantees non-reentrancy. It did so by giving different work functions
    to different types of work.
    
    However, the fixes in the previous few patches are more complete, as
    they prevent a work item from being recycled at all (except for a tiny
    window that the kernel workqueue code handles for us). This obsoletes
    the previous fix, so we don't need the unique helpers for correctness.
    The only other reason to keep them would be so they show up in stack
    traces, but they always seem to be optimized to a tail call, so they
    don't show up anyways. So, let's just get rid of the extra indirection.
    
    While we're here, rename normal_work_helper() to the more informative
    btrfs_work_helper().
    
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c261ca281733557413a2d93c8fd9fd2eec6156e
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Sat Jul 20 14:05:20 2019 +0800

    ubifs: ubifs_tnc_start_commit: Fix OOB in layout_in_gaps
    
    [ Upstream commit 6abf57262166b4f4294667fb5206ae7ba1ba96f5 ]
    
    Running stress-test test_2 in mtd-utils on ubi device, sometimes we can
    get following oops message:
    
      BUG: unable to handle page fault for address: ffffffff00000140
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 280a067 P4D 280a067 PUD 0
      Oops: 0000 [#1] SMP
      CPU: 0 PID: 60 Comm: kworker/u16:1 Kdump: loaded Not tainted 5.2.0 #13
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0
      -0-ga698c8995f-prebuilt.qemu.org 04/01/2014
      Workqueue: writeback wb_workfn (flush-ubifs_0_0)
      RIP: 0010:rb_next_postorder+0x2e/0xb0
      Code: 80 db 03 01 48 85 ff 0f 84 97 00 00 00 48 8b 17 48 83 05 bc 80 db
      03 01 48 83 e2 fc 0f 84 82 00 00 00 48 83 05 b2 80 db 03 01 <48> 3b 7a
      10 48 89 d0 74 02 f3 c3 48 8b 52 08 48 83 05 a3 80 db 03
      RSP: 0018:ffffc90000887758 EFLAGS: 00010202
      RAX: ffff888129ae4700 RBX: ffff888138b08400 RCX: 0000000080800001
      RDX: ffffffff00000130 RSI: 0000000080800024 RDI: ffff888138b08400
      RBP: ffff888138b08400 R08: ffffea0004a6b920 R09: 0000000000000000
      R10: ffffc90000887740 R11: 0000000000000001 R12: ffff888128d48000
      R13: 0000000000000800 R14: 000000000000011e R15: 00000000000007c8
      FS:  0000000000000000(0000) GS:ffff88813ba00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffff00000140 CR3: 000000013789d000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        destroy_old_idx+0x5d/0xa0 [ubifs]
        ubifs_tnc_start_commit+0x4fe/0x1380 [ubifs]
        do_commit+0x3eb/0x830 [ubifs]
        ubifs_run_commit+0xdc/0x1c0 [ubifs]
    
    Above Oops are due to the slab-out-of-bounds happened in do-while of
    function layout_in_gaps indirectly called by ubifs_tnc_start_commit. In
    function layout_in_gaps, there is a do-while loop placing index nodes
    into the gaps created by obsolete index nodes in non-empty index LEBs
    until rest index nodes can totally be placed into pre-allocated empty
    LEBs. @c->gap_lebs points to a memory area(integer array) which records
    LEB numbers used by 'in-the-gaps' method. Whenever a fitable index LEB
    is found, corresponding lnum will be incrementally written into the
    memory area pointed by @c->gap_lebs. The size
    ((@c->lst.idx_lebs + 1) * sizeof(int)) of memory area is allocated before
    do-while loop and can not be changed in the loop. But @c->lst.idx_lebs
    could be increased by function ubifs_change_lp (called by
    layout_leb_in_gaps->ubifs_find_dirty_idx_leb->get_idx_gc_leb) during the
    loop. So, sometimes oob happens when number of cycles in do-while loop
    exceeds the original value of @c->lst.idx_lebs. See detail in
    https://bugzilla.kernel.org/show_bug.cgi?id=204229.
    This patch fixes oob in layout_in_gaps.
    
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3900f9268a3d07de08286f82ea328120801008f5
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Nov 7 18:29:11 2019 -0800

    net: add annotations on hh->hh_len lockless accesses
    
    [ Upstream commit c305c6ae79e2ce20c22660ceda94f0d86d639a82 ]
    
    KCSAN reported a data-race [1]
    
    While we can use READ_ONCE() on the read sides,
    we need to make sure hh->hh_len is written last.
    
    [1]
    
    BUG: KCSAN: data-race in eth_header_cache / neigh_resolve_output
    
    write to 0xffff8880b9dedcb8 of 4 bytes by task 29760 on cpu 0:
     eth_header_cache+0xa9/0xd0 net/ethernet/eth.c:247
     neigh_hh_init net/core/neighbour.c:1463 [inline]
     neigh_resolve_output net/core/neighbour.c:1480 [inline]
     neigh_resolve_output+0x415/0x470 net/core/neighbour.c:1470
     neigh_output include/net/neighbour.h:511 [inline]
     ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
     __ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
     __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
     ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
     NF_HOOK_COND include/linux/netfilter.h:294 [inline]
     ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
     dst_output include/net/dst.h:436 [inline]
     NF_HOOK include/linux/netfilter.h:305 [inline]
     ndisc_send_skb+0x459/0x5f0 net/ipv6/ndisc.c:505
     ndisc_send_ns+0x207/0x430 net/ipv6/ndisc.c:647
     rt6_probe_deferred+0x98/0xf0 net/ipv6/route.c:615
     process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
     worker_thread+0xa0/0x800 kernel/workqueue.c:2415
     kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
    
    read to 0xffff8880b9dedcb8 of 4 bytes by task 29572 on cpu 1:
     neigh_resolve_output net/core/neighbour.c:1479 [inline]
     neigh_resolve_output+0x113/0x470 net/core/neighbour.c:1470
     neigh_output include/net/neighbour.h:511 [inline]
     ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
     __ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
     __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
     ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
     NF_HOOK_COND include/linux/netfilter.h:294 [inline]
     ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
     dst_output include/net/dst.h:436 [inline]
     NF_HOOK include/linux/netfilter.h:305 [inline]
     ndisc_send_skb+0x459/0x5f0 net/ipv6/ndisc.c:505
     ndisc_send_ns+0x207/0x430 net/ipv6/ndisc.c:647
     rt6_probe_deferred+0x98/0xf0 net/ipv6/route.c:615
     process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
     worker_thread+0xa0/0x800 kernel/workqueue.c:2415
     kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 29572 Comm: kworker/1:4 Not tainted 5.4.0-rc6+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events rt6_probe_deferred
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8233f7b2f77336fddb089bb8b8bc17fa0934373
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Tue Nov 5 15:33:57 2019 -0800

    xfs: periodically yield scrub threads to the scheduler
    
    [ Upstream commit 5d1116d4c6af3e580f1ed0382ca5a94bd65a34cf ]
    
    Christoph Hellwig complained about the following soft lockup warning
    when running scrub after generic/175 when preemption is disabled and
    slub debugging is enabled:
    
    watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [xfs_scrub:161]
    Modules linked in:
    irq event stamp: 41692326
    hardirqs last  enabled at (41692325): [<ffffffff8232c3b7>] _raw_0
    hardirqs last disabled at (41692326): [<ffffffff81001c5a>] trace0
    softirqs last  enabled at (41684994): [<ffffffff8260031f>] __do_e
    softirqs last disabled at (41684987): [<ffffffff81127d8c>] irq_e0
    CPU: 3 PID: 16189 Comm: xfs_scrub Not tainted 5.4.0-rc3+ #30
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.124
    RIP: 0010:_raw_spin_unlock_irqrestore+0x39/0x40
    Code: 89 f3 be 01 00 00 00 e8 d5 3a e5 fe 48 89 ef e8 ed 87 e5 f2
    RSP: 0018:ffffc9000233f970 EFLAGS: 00000286 ORIG_RAX: ffffffffff3
    RAX: ffff88813b398040 RBX: 0000000000000286 RCX: 0000000000000006
    RDX: 0000000000000006 RSI: ffff88813b3988c0 RDI: ffff88813b398040
    RBP: ffff888137958640 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffffea00042b0c00
    R13: 0000000000000001 R14: ffff88810ac32308 R15: ffff8881376fc040
    FS:  00007f6113dea700(0000) GS:ffff88813bb80000(0000) knlGS:00000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f6113de8ff8 CR3: 000000012f290000 CR4: 00000000000006e0
    Call Trace:
     free_debug_processing+0x1dd/0x240
     __slab_free+0x231/0x410
     kmem_cache_free+0x30e/0x360
     xchk_ag_btcur_free+0x76/0xb0
     xchk_ag_free+0x10/0x80
     xchk_bmap_iextent_xref.isra.14+0xd9/0x120
     xchk_bmap_iextent+0x187/0x210
     xchk_bmap+0x2e0/0x3b0
     xfs_scrub_metadata+0x2e7/0x500
     xfs_ioc_scrub_metadata+0x4a/0xa0
     xfs_file_ioctl+0x58a/0xcd0
     do_vfs_ioctl+0xa0/0x6f0
     ksys_ioctl+0x5b/0x90
     __x64_sys_ioctl+0x11/0x20
     do_syscall_64+0x4b/0x1a0
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    If preemption is disabled, all metadata buffers needed to perform the
    scrub are already in memory, and there are a lot of records to check,
    it's possible that the scrub thread will run for an extended period of
    time without sleeping for IO or any other reason.  Then the watchdog
    timer or the RCU stall timeout can trigger, producing the backtrace
    above.
    
    To fix this problem, call cond_resched() from the scrub thread so that
    we back out to the scheduler whenever necessary.
    
    Reported-by: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c35de2e005b2bf1f59fa98bc69ea2dbb9a75380f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Oct 4 20:47:58 2019 +0100

    drm/i915/execlists: Fix annotation for decoupling virtual request
    
    [ Upstream commit 08ad9a3846fc72b047b110b36d162ffbcf298fa2 ]
    
    As we may signal a request and take the engine->active.lock within the
    signaler, the engine submission paths have to use a nested annotation on
    their requests -- but we guarantee that we can never submit on the same
    engine as the signaling fence.
    
    <4>[  723.763281] WARNING: possible circular locking dependency detected
    <4>[  723.763285] 5.3.0-g80fa0e042cdb-drmtip_379+ #1 Tainted: G     U
    <4>[  723.763288] ------------------------------------------------------
    <4>[  723.763291] gem_exec_await/1388 is trying to acquire lock:
    <4>[  723.763294] ffff93a7b53221d8 (&engine->active.lock){..-.}, at: execlists_submit_request+0x2b/0x1e0 [i915]
    <4>[  723.763378]
                      but task is already holding lock:
    <4>[  723.763381] ffff93a7c25f6d20 (&i915_request_get(rq)->submit/1){-.-.}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915]
    <4>[  723.763420]
                      which lock already depends on the new lock.
    
    <4>[  723.763423]
                      the existing dependency chain (in reverse order) is:
    <4>[  723.763427]
                      -> #2 (&i915_request_get(rq)->submit/1){-.-.}:
    <4>[  723.763434]        _raw_spin_lock_irqsave_nested+0x39/0x50
    <4>[  723.763478]        __i915_sw_fence_complete+0x1b2/0x250 [i915]
    <4>[  723.763513]        intel_engine_breadcrumbs_irq+0x3aa/0x5e0 [i915]
    <4>[  723.763600]        cs_irq_handler+0x49/0x50 [i915]
    <4>[  723.763659]        gen11_gt_irq_handler+0x17b/0x280 [i915]
    <4>[  723.763690]        gen11_irq_handler+0x54/0xf0 [i915]
    <4>[  723.763695]        __handle_irq_event_percpu+0x41/0x2d0
    <4>[  723.763699]        handle_irq_event_percpu+0x2b/0x70
    <4>[  723.763702]        handle_irq_event+0x2f/0x50
    <4>[  723.763706]        handle_edge_irq+0xee/0x1a0
    <4>[  723.763709]        do_IRQ+0x7e/0x160
    <4>[  723.763712]        ret_from_intr+0x0/0x1d
    <4>[  723.763717]        __slab_alloc.isra.28.constprop.33+0x4f/0x70
    <4>[  723.763720]        kmem_cache_alloc+0x28d/0x2f0
    <4>[  723.763724]        vm_area_dup+0x15/0x40
    <4>[  723.763727]        dup_mm+0x2dd/0x550
    <4>[  723.763730]        copy_process+0xf21/0x1ef0
    <4>[  723.763734]        _do_fork+0x71/0x670
    <4>[  723.763737]        __se_sys_clone+0x6e/0xa0
    <4>[  723.763741]        do_syscall_64+0x4f/0x210
    <4>[  723.763744]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    <4>[  723.763747]
                      -> #1 (&(&rq->lock)->rlock#2){-.-.}:
    <4>[  723.763752]        _raw_spin_lock+0x2a/0x40
    <4>[  723.763789]        __unwind_incomplete_requests+0x3eb/0x450 [i915]
    <4>[  723.763825]        __execlists_submission_tasklet+0x9ec/0x1d60 [i915]
    <4>[  723.763864]        execlists_submission_tasklet+0x34/0x50 [i915]
    <4>[  723.763874]        tasklet_action_common.isra.5+0x47/0xb0
    <4>[  723.763878]        __do_softirq+0xd8/0x4ae
    <4>[  723.763881]        irq_exit+0xa9/0xc0
    <4>[  723.763883]        smp_apic_timer_interrupt+0xb7/0x280
    <4>[  723.763887]        apic_timer_interrupt+0xf/0x20
    <4>[  723.763892]        cpuidle_enter_state+0xae/0x450
    <4>[  723.763895]        cpuidle_enter+0x24/0x40
    <4>[  723.763899]        do_idle+0x1e7/0x250
    <4>[  723.763902]        cpu_startup_entry+0x14/0x20
    <4>[  723.763905]        start_secondary+0x15f/0x1b0
    <4>[  723.763908]        secondary_startup_64+0xa4/0xb0
    <4>[  723.763911]
                      -> #0 (&engine->active.lock){..-.}:
    <4>[  723.763916]        __lock_acquire+0x15d8/0x1ea0
    <4>[  723.763919]        lock_acquire+0xa6/0x1c0
    <4>[  723.763922]        _raw_spin_lock_irqsave+0x33/0x50
    <4>[  723.763956]        execlists_submit_request+0x2b/0x1e0 [i915]
    <4>[  723.764002]        submit_notify+0xa8/0x13c [i915]
    <4>[  723.764035]        __i915_sw_fence_complete+0x81/0x250 [i915]
    <4>[  723.764054]        i915_sw_fence_wake+0x51/0x64 [i915]
    <4>[  723.764054]        __i915_sw_fence_complete+0x1ee/0x250 [i915]
    <4>[  723.764054]        dma_i915_sw_fence_wake_timer+0x14/0x20 [i915]
    <4>[  723.764054]        dma_fence_signal_locked+0x9e/0x1c0
    <4>[  723.764054]        dma_fence_signal+0x1f/0x40
    <4>[  723.764054]        vgem_fence_signal_ioctl+0x67/0xc0 [vgem]
    <4>[  723.764054]        drm_ioctl_kernel+0x83/0xf0
    <4>[  723.764054]        drm_ioctl+0x2f3/0x3b0
    <4>[  723.764054]        do_vfs_ioctl+0xa0/0x6f0
    <4>[  723.764054]        ksys_ioctl+0x35/0x60
    <4>[  723.764054]        __x64_sys_ioctl+0x11/0x20
    <4>[  723.764054]        do_syscall_64+0x4f/0x210
    <4>[  723.764054]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    <4>[  723.764054]
                      other info that might help us debug this:
    
    <4>[  723.764054] Chain exists of:
                        &engine->active.lock --> &(&rq->lock)->rlock#2 --> &i915_request_get(rq)->submit/1
    
    <4>[  723.764054]  Possible unsafe locking scenario:
    
    <4>[  723.764054]        CPU0                    CPU1
    <4>[  723.764054]        ----                    ----
    <4>[  723.764054]   lock(&i915_request_get(rq)->submit/1);
    <4>[  723.764054]                                lock(&(&rq->lock)->rlock#2);
    <4>[  723.764054]                                lock(&i915_request_get(rq)->submit/1);
    <4>[  723.764054]   lock(&engine->active.lock);
    <4>[  723.764054]
                       *** DEADLOCK ***
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111862
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191004194758.19679-1-chris@chris-wilson.co.uk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e307bfda74a9c66426313eca25ccfea877a50036
Author: Masashi Honma <masashi.honma@gmail.com>
Date:   Fri Sep 27 11:51:46 2019 +0900

    ath9k_htc: Discard undersized packets
    
    [ Upstream commit cd486e627e67ee9ab66914d36d3127ef057cc010 ]
    
    Sometimes the hardware will push small packets that trigger a WARN_ON
    in mac80211. Discard them early to avoid this issue.
    
    This patch ports 2 patches from ath9k to ath9k_htc.
    commit 3c0efb745a172bfe96459e20cbd37b0c945d5f8d "ath9k: discard
    undersized packets".
    commit df5c4150501ee7e86383be88f6490d970adcf157 "ath9k: correctly
    handle short radar pulses".
    
    [  112.835889] ------------[ cut here ]------------
    [  112.835971] WARNING: CPU: 5 PID: 0 at net/mac80211/rx.c:804 ieee80211_rx_napi+0xaac/0xb40 [mac80211]
    [  112.835973] Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 libarc4 nouveau snd_hda_codec_hdmi intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_hda_codec video snd_hda_core ttm snd_hwdep drm_kms_helper snd_pcm crct10dif_pclmul snd_seq_midi drm snd_seq_midi_event crc32_pclmul snd_rawmidi ghash_clmulni_intel snd_seq aesni_intel aes_x86_64 crypto_simd cryptd snd_seq_device glue_helper snd_timer sch_fq_codel i2c_algo_bit fb_sys_fops snd input_leds syscopyarea sysfillrect sysimgblt intel_cstate mei_me intel_rapl_perf soundcore mxm_wmi lpc_ich mei kvm_intel kvm mac_hid irqbypass parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear e1000e ahci libahci wmi
    [  112.836022] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.3.0-wt #1
    [  112.836023] Hardware name: MouseComputer Co.,Ltd. X99-S01/X99-S01, BIOS 1.0C-W7 04/01/2015
    [  112.836056] RIP: 0010:ieee80211_rx_napi+0xaac/0xb40 [mac80211]
    [  112.836059] Code: 00 00 66 41 89 86 b0 00 00 00 e9 c8 fa ff ff 4c 89 b5 40 ff ff ff 49 89 c6 e9 c9 fa ff ff 48 c7 c7 e0 a2 a5 c0 e8 47 41 b0 e9 <0f> 0b 48 89 df e8 5a 94 2d ea e9 02 f9 ff ff 41 39 c1 44 89 85 60
    [  112.836060] RSP: 0018:ffffaa6180220da8 EFLAGS: 00010286
    [  112.836062] RAX: 0000000000000024 RBX: ffff909a20eeda00 RCX: 0000000000000000
    [  112.836064] RDX: 0000000000000000 RSI: ffff909a2f957448 RDI: ffff909a2f957448
    [  112.836065] RBP: ffffaa6180220e78 R08: 00000000000006e9 R09: 0000000000000004
    [  112.836066] R10: 000000000000000a R11: 0000000000000001 R12: 0000000000000000
    [  112.836068] R13: ffff909a261a47a0 R14: 0000000000000000 R15: 0000000000000004
    [  112.836070] FS:  0000000000000000(0000) GS:ffff909a2f940000(0000) knlGS:0000000000000000
    [  112.836071] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  112.836073] CR2: 00007f4e3ffffa08 CR3: 00000001afc0a006 CR4: 00000000001606e0
    [  112.836074] Call Trace:
    [  112.836076]  <IRQ>
    [  112.836083]  ? finish_td+0xb3/0xf0
    [  112.836092]  ? ath9k_rx_prepare.isra.11+0x22f/0x2a0 [ath9k_htc]
    [  112.836099]  ath9k_rx_tasklet+0x10b/0x1d0 [ath9k_htc]
    [  112.836105]  tasklet_action_common.isra.22+0x63/0x110
    [  112.836108]  tasklet_action+0x22/0x30
    [  112.836115]  __do_softirq+0xe4/0x2da
    [  112.836118]  irq_exit+0xae/0xb0
    [  112.836121]  do_IRQ+0x86/0xe0
    [  112.836125]  common_interrupt+0xf/0xf
    [  112.836126]  </IRQ>
    [  112.836130] RIP: 0010:cpuidle_enter_state+0xa9/0x440
    [  112.836133] Code: 3d bc 20 38 55 e8 f7 1d 84 ff 49 89 c7 0f 1f 44 00 00 31 ff e8 28 29 84 ff 80 7d d3 00 0f 85 e6 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 ed 0f 89 ff 01 00 00 41 c7 44 24 10 00 00 00 00 48 83 c4 18
    [  112.836134] RSP: 0018:ffffaa61800e3e48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
    [  112.836136] RAX: ffff909a2f96b340 RBX: ffffffffabb58200 RCX: 000000000000001f
    [  112.836137] RDX: 0000001a458adc5d RSI: 0000000026c9b581 RDI: 0000000000000000
    [  112.836139] RBP: ffffaa61800e3e88 R08: 0000000000000002 R09: 000000000002abc0
    [  112.836140] R10: ffffaa61800e3e18 R11: 000000000000002d R12: ffffca617fb40b00
    [  112.836141] R13: 0000000000000002 R14: ffffffffabb582d8 R15: 0000001a458adc5d
    [  112.836145]  ? cpuidle_enter_state+0x98/0x440
    [  112.836149]  ? menu_select+0x370/0x600
    [  112.836151]  cpuidle_enter+0x2e/0x40
    [  112.836154]  call_cpuidle+0x23/0x40
    [  112.836156]  do_idle+0x204/0x280
    [  112.836159]  cpu_startup_entry+0x1d/0x20
    [  112.836164]  start_secondary+0x167/0x1c0
    [  112.836169]  secondary_startup_64+0xa4/0xb0
    [  112.836173] ---[ end trace 9f4cd18479cc5ae5 ]---
    
    Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ceea88623947dbd12c74a7063bbf75f92afb1529
Author: Masashi Honma <masashi.honma@gmail.com>
Date:   Fri Sep 27 11:51:45 2019 +0900

    ath9k_htc: Modify byte order for an error message
    
    [ Upstream commit e01fddc19d215f6ad397894ec2a851d99bf154e2 ]
    
    rs_datalen is be16 so we need to convert it before printing.
    
    Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d536e814a36cc81a53cba83350ffc536c788a8de
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Apr 21 18:53:50 2019 -0400

    fix compat handling of FICLONERANGE, FIDEDUPERANGE and FS_IOC_FIEMAP
    
    commit 6b2daec19094a90435abe67d16fb43b1a5527254 upstream.
    
    Unlike FICLONE, all of those take a pointer argument; they do need
    compat_ptr() applied to arg.
    
    Fixes: d79bdd52d8be ("vfs: wire up compat ioctl for CLONE/CLONE_RANGE")
    Fixes: 54dbc1517237 ("vfs: hoist the btrfs deduplication ioctl to the vfs")
    Fixes: ceac204e1da9 ("fs: make fiemap work from compat_ioctl")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52788b4af1b6379541b8d2b3a4e3d20c275cc42a
Author: Deepa Dinamani <deepa.kernel@gmail.com>
Date:   Fri Nov 29 21:30:25 2019 -0800

    fs: cifs: Fix atime update check vs mtime
    
    commit 69738cfdfa7032f45d9e7462d24490e61cf163dd upstream.
    
    According to the comment in the code and commit log, some apps
    expect atime >= mtime; but the introduced code results in
    atime==mtime.  Fix the comparison to guard against atime<mtime.
    
    Fixes: 9b9c5bea0b96 ("cifs: do not return atime less than mtime")
    Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
    Cc: stfrench@microsoft.com
    Cc: linux-cifs@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42692a61ab19151159b62887136039840b53f923
Author: Paulo Alcantara (SUSE) <pc@cjr.nz>
Date:   Fri Nov 22 12:30:52 2019 -0300

    cifs: Fix lookup of root ses in DFS referral cache
    
    commit df3df923b31d298c3d3653a0380202b9f2df9864 upstream.
    
    We don't care about module aliasing validation in
    cifs_compose_mount_options(..., is_smb3) when finding the root SMB
    session of an DFS namespace in order to refresh DFS referral cache.
    
    The following issue has been observed when mounting with '-t smb3' and
    then specifying 'vers=2.0':
    
    ...
    Nov 08 15:27:08 tw kernel: address conversion returned 0 for FS0.WIN.LOCAL
    Nov 08 15:27:08 tw kernel: [kworke] ==> dns_query((null),FS0.WIN.LOCAL,13,(null))
    Nov 08 15:27:08 tw kernel: [kworke] call request_key(,FS0.WIN.LOCAL,)
    Nov 08 15:27:08 tw kernel: [kworke] ==> dns_resolver_cmp(FS0.WIN.LOCAL,FS0.WIN.LOCAL)
    Nov 08 15:27:08 tw kernel: [kworke] <== dns_resolver_cmp() = 1
    Nov 08 15:27:08 tw kernel: [kworke] <== dns_query() = 13
    Nov 08 15:27:08 tw kernel: fs/cifs/dns_resolve.c: dns_resolve_server_name_to_ip: resolved: FS0.WIN.LOCAL to 192.168.30.26
    ===> Nov 08 15:27:08 tw kernel: CIFS VFS: vers=2.0 not permitted when mounting with smb3
    Nov 08 15:27:08 tw kernel: fs/cifs/dfs_cache.c: CIFS VFS: leaving refresh_tcon (xid = 26) rc = -22
    ...
    
    Fixes: 5072010ccf05 ("cifs: Fix DFS cache refresher for DFS links")
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4bd6190498baeb50862d72c3d16f97edb9554e3
Author: Leo Yan <leo.yan@linaro.org>
Date:   Wed Nov 27 22:15:43 2019 +0800

    tty: serial: msm_serial: Fix lockup for sysrq and oops
    
    commit 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e upstream.
    
    As the commit 677fe555cbfb ("serial: imx: Fix recursive locking bug")
    has mentioned the uart driver might cause recursive locking between
    normal printing and the kernel debugging facilities (e.g. sysrq and
    oops).  In the commit it gave out suggestion for fixing recursive
    locking issue: "The solution is to avoid locking in the sysrq case
    and trylock in the oops_in_progress case."
    
    This patch follows the suggestion (also used the exactly same code with
    other serial drivers, e.g. amba-pl011.c) to fix the recursive locking
    issue, this can avoid stuck caused by deadlock and print out log for
    sysrq and oops.
    
    Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
    Link: https://lore.kernel.org/r/20191127141544.4277-2-leo.yan@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 985b411769c1604fc127f7dd859f324c42acdcb8
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Oct 1 20:11:09 2019 +0200

    phy: renesas: rcar-gen3-usb2: Use platform_get_irq_optional() for optional irq
    
    commit b049e03ca57f238e74a79e44ffc85904db465e72 upstream.
    
    As platform_get_irq() now prints an error when the interrupt does not
    exist, a scary warning may be printed for an optional interrupt:
    
        phy_rcar_gen3_usb2 ee0a0200.usb-phy: IRQ index 0 not found
    
    Fix this by calling platform_get_irq_optional() instead.
    
    Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()")
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3476cfa23804c03feb8047132f3d42e9f3d4456
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Mon Sep 2 05:49:35 2019 +0000

    arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning
    
    commit 72c9b5f6f75fbc6c47e0a2d02bc3838a2a47c90a upstream.
    
    usb_otg bus needs to get initialize from the u-boot to be configured
    to used as power source to SBC or usb otg port will get configured
    as host device. Right now this support is missing in the u-boot and
    phy driver so to avoid power failed warning, we would disable this
    feature  until proper fix is found.
    
    [    2.716048] phy phy-c0000000.phy.0: USB ID detect failed!
    [    2.720186] phy phy-c0000000.phy.0: phy poweron failed --> -22
    [    2.726001] ------------[ cut here ]------------
    [    2.730583] WARNING: CPU: 0 PID: 12 at drivers/regulator/core.c:2039 _regulator_put+0x3c/0xe8
    [    2.738983] Modules linked in:
    [    2.742005] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.9-1-ARCH #1
    [    2.748643] Hardware name: Hardkernel ODROID-C2 (DT)
    [    2.753566] Workqueue: events deferred_probe_work_func
    [    2.758649] pstate: 60000005 (nZCv daif -PAN -UAO)
    [    2.763394] pc : _regulator_put+0x3c/0xe8
    [    2.767361] lr : _regulator_put+0x3c/0xe8
    [    2.771326] sp : ffff000011aa3a50
    [    2.774604] x29: ffff000011aa3a50 x28: ffff80007ed1b600
    [    2.779865] x27: ffff80007f7036a8 x26: ffff80007f7036a8
    [    2.785126] x25: 0000000000000000 x24: ffff000011a44458
    [    2.790387] x23: ffff000011344218 x22: 0000000000000009
    [    2.795649] x21: ffff000011aa3b68 x20: ffff80007ed1b500
    [    2.800910] x19: ffff80007ed1b500 x18: 0000000000000010
    [    2.806171] x17: 000000005be5943c x16: 00000000f1c73b29
    [    2.811432] x15: ffffffffffffffff x14: ffff0000117396c8
    [    2.816694] x13: ffff000091aa37a7 x12: ffff000011aa37af
    [    2.821955] x11: ffff000011763000 x10: ffff000011aa3730
    [    2.827216] x9 : 00000000ffffffd0 x8 : ffff000010871760
    [    2.832477] x7 : 00000000000000d0 x6 : ffff0000119d151b
    [    2.837739] x5 : 000000000000000f x4 : 0000000000000000
    [    2.843000] x3 : 0000000000000000 x2 : 38104b2678c20100
    [    2.848261] x1 : 0000000000000000 x0 : 0000000000000024
    [    2.853523] Call trace:
    [    2.855940]  _regulator_put+0x3c/0xe8
    [    2.859562]  regulator_put+0x34/0x48
    [    2.863098]  regulator_bulk_free+0x40/0x58
    [    2.867153]  devm_regulator_bulk_release+0x24/0x30
    [    2.871896]  release_nodes+0x1f0/0x2e0
    [    2.875604]  devres_release_all+0x64/0xa4
    [    2.879571]  really_probe+0x1c8/0x3e0
    [    2.883194]  driver_probe_device+0xe4/0x138
    [    2.887334]  __device_attach_driver+0x90/0x110
    [    2.891733]  bus_for_each_drv+0x8c/0xd8
    [    2.895527]  __device_attach+0xdc/0x160
    [    2.899322]  device_initial_probe+0x24/0x30
    [    2.903463]  bus_probe_device+0x9c/0xa8
    [    2.907258]  deferred_probe_work_func+0xa0/0xf0
    [    2.911745]  process_one_work+0x1b4/0x408
    [    2.915711]  worker_thread+0x54/0x4b8
    [    2.919334]  kthread+0x12c/0x130
    [    2.922526]  ret_from_fork+0x10/0x1c
    [    2.926060] ---[ end trace 51a68f4c0035d6c0 ]---
    [    2.930691] ------------[ cut here ]------------
    [    2.935242] WARNING: CPU: 0 PID: 12 at drivers/regulator/core.c:2039 _regulator_put+0x3c/0xe8
    [    2.943653] Modules linked in:
    [    2.946675] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G        W         5.2.9-1-ARCH #1
    [    2.954694] Hardware name: Hardkernel ODROID-C2 (DT)
    [    2.959613] Workqueue: events deferred_probe_work_func
    [    2.964700] pstate: 60000005 (nZCv daif -PAN -UAO)
    [    2.969445] pc : _regulator_put+0x3c/0xe8
    [    2.973412] lr : _regulator_put+0x3c/0xe8
    [    2.977377] sp : ffff000011aa3a50
    [    2.980655] x29: ffff000011aa3a50 x28: ffff80007ed1b600
    [    2.985916] x27: ffff80007f7036a8 x26: ffff80007f7036a8
    [    2.991177] x25: 0000000000000000 x24: ffff000011a44458
    [    2.996439] x23: ffff000011344218 x22: 0000000000000009
    [    3.001700] x21: ffff000011aa3b68 x20: ffff80007ed1bd00
    [    3.006961] x19: ffff80007ed1bd00 x18: 0000000000000010
    [    3.012222] x17: 000000005be5943c x16: 00000000f1c73b29
    [    3.017484] x15: ffffffffffffffff x14: ffff0000117396c8
    [    3.022745] x13: ffff000091aa37a7 x12: ffff000011aa37af
    [    3.028006] x11: ffff000011763000 x10: ffff000011aa3730
    [    3.033267] x9 : 00000000ffffffd0 x8 : ffff000010871760
    [    3.038528] x7 : 00000000000000fd x6 : ffff0000119d151b
    [    3.043790] x5 : 000000000000000f x4 : 0000000000000000
    [    3.049051] x3 : 0000000000000000 x2 : 38104b2678c20100
    [    3.054312] x1 : 0000000000000000 x0 : 0000000000000024
    [    3.059574] Call trace:
    [    3.061991]  _regulator_put+0x3c/0xe8
    [    3.065613]  regulator_put+0x34/0x48
    [    3.069149]  regulator_bulk_free+0x40/0x58
    [    3.073203]  devm_regulator_bulk_release+0x24/0x30
    [    3.077947]  release_nodes+0x1f0/0x2e0
    [    3.081655]  devres_release_all+0x64/0xa4
    [    3.085622]  really_probe+0x1c8/0x3e0
    [    3.089245]  driver_probe_device+0xe4/0x138
    [    3.093385]  __device_attach_driver+0x90/0x110
    [    3.097784]  bus_for_each_drv+0x8c/0xd8
    [    3.101578]  __device_attach+0xdc/0x160
    [    3.105373]  device_initial_probe+0x24/0x30
    [    3.109514]  bus_probe_device+0x9c/0xa8
    [    3.113309]  deferred_probe_work_func+0xa0/0xf0
    [    3.117796]  process_one_work+0x1b4/0x408
    [    3.121762]  worker_thread+0x54/0x4b8
    [    3.125384]  kthread+0x12c/0x130
    [    3.128575]  ret_from_fork+0x10/0x1c
    [    3.132110] ---[ end trace 51a68f4c0035d6c1 ]---
    [    3.136753] dwc2: probe of c9000000.usb failed with error -22
    
    Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes")
    Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Cc: Jerome Brunet <jbrunet@baylibre.com>
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da9eb04eaa643d795bbf3dc642a8988d3f3c4b6c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Oct 16 16:56:50 2019 +0200

    dt-bindings: clock: renesas: rcar-usb2-clock-sel: Fix typo in example
    
    commit 830dbce7c76ea529decac7d23b808c1e7da3d891 upstream.
    
    The documented compatible value for R-Car H3 is
    "renesas,r8a7795-rcar-usb2-clock-sel", not
    "renesas,r8a77950-rcar-usb2-clock-sel".
    
    Fixes: 311accb64570db45 ("clk: renesas: rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20191016145650.30003-1-geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3dba6e50d09ee8c05d5ba68bd69624ac1ea0c814
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Wed Oct 9 12:01:47 2019 -0300

    media: usb: fix memory leak in af9005_identify_state
    
    commit 2289adbfa559050d2a38bcd9caac1c18b800e928 upstream.
    
    In af9005_identify_state when returning -EIO the allocated buffer should
    be released. Replace the "return -EIO" with assignment into ret and move
    deb_info() under a check.
    
    Fixes: af4e067e1dcf ("V4L/DVB (5625): Add support for the AF9005 demodulator from Afatech")
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56eb000be1142c3fb3a60d08ffb1cfef49996bc5
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Wed Nov 6 18:31:24 2019 +0100

    regulator: ab8500: Remove AB8505 USB regulator
    
    commit 99c4f70df3a6446c56ca817c2d0f9c12d85d4e7c upstream.
    
    The USB regulator was removed for AB8500 in
    commit 41a06aa738ad ("regulator: ab8500: Remove USB regulator").
    It was then added for AB8505 in
    commit 547f384f33db ("regulator: ab8500: add support for ab8505").
    
    However, there was never an entry added for it in
    ab8505_regulator_match. This causes all regulators after it
    to be initialized with the wrong device tree data, eventually
    leading to an out-of-bounds array read.
    
    Given that it is not used anywhere in the kernel, it seems
    likely that similar arguments against supporting it exist for
    AB8505 (it is controlled by hardware).
    
    Therefore, simply remove it like for AB8500 instead of adding
    an entry in ab8505_regulator_match.
    
    Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505")
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.net
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6851d4004b6f770dd9e71b4da61a02d14cbacedb
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Oct 25 15:33:39 2019 +0200

    media: flexcop-usb: ensure -EIO is returned on error condition
    
    commit 74a96b51a36de4d86660fbc56b05d86668162d6b upstream.
    
    An earlier commit hard coded a return 0 to function flexcop_usb_i2c_req
    even though the an -EIO was intended to be returned in the case where
    ret != buflen.  Fix this by replacing the return 0 with the return of
    ret to return the error return code.
    
    Addresses-Coverity: ("Unused value")
    
    Fixes: b430eaba0be5 ("[media] flexcop-usb: don't use stack for DMA")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0123e668ca943ac9d9ceb9579f007e4581d92b63
Author: Christian Hewitt <christianshewitt@gmail.com>
Date:   Mon Sep 9 19:01:24 2019 +0400

    arm64: dts: meson-gxm-khadas-vim2: fix uart_A bluetooth node
    
    commit 388a2772979b625042524d8b91280616ab4ff5ee upstream.
    
    Fixes: 33344e2111a3 ("arm64: dts: meson-gxm-khadas-vim2: fix Bluetooth support")
    Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
    Reviewed-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f05d1ede71b24405ca5c49382bf97382322a4b00
Author: Christian Hewitt <christianshewitt@gmail.com>
Date:   Mon Sep 9 19:01:23 2019 +0400

    arm64: dts: meson-gxl-s905x-khadas-vim: fix uart_A bluetooth node
    
    commit 1c6d575574ec87dbccf7af20ef9dc0df02614069 upstream.
    
    Fixes: dd5297cc8b8b ("arm64: dts: meson-gxl-s905x-khadas-vim enable Bluetooth")
    Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
    Reviewed-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36427907e08613382e469acf096d4efbdbf8bb1a
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Thu Nov 21 14:20:36 2019 -0600

    Bluetooth: Fix memory leak in hci_connect_le_scan
    
    commit d088337c38a5cd8f0230fbf2d514ff7672f9d0d3 upstream.
    
    In the implementation of hci_connect_le_scan() when conn is added via
    hci_conn_add(), if hci_explicit_conn_params_set() fails the allocated
    memory for conn is leaked. Use hci_conn_del() to release it.
    
    Fixes: f75113a26008 ("Bluetooth: add hci_connect_le_scan")
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 081d57ac233a56fdb5655fb898b681088235fadc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Nov 19 09:17:05 2019 +0300

    Bluetooth: delete a stray unlock
    
    commit df66499a1fab340c167250a5743931dc50d5f0fa upstream.
    
    We used to take a lock in amp_physical_cfm() but then we moved it to
    the caller function.  Unfortunately the unlock on this error path was
    overlooked so it leads to a double unlock.
    
    Fixes: a514b17fab51 ("Bluetooth: Refactor locking in amp_physical_cfm")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1221702c41d0e760e4cc00ea12fbf45966b50d8
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 16:01:18 2019 +0100

    Bluetooth: btusb: fix PM leak in error case of setup
    
    commit 3d44a6fd0775e6215e836423e27f8eedf8c871ea upstream.
    
    If setup() fails a reference for runtime PM has already
    been taken. Proper use of the error handling in btusb_open()is needed.
    You cannot just return.
    
    Fixes: ace31982585a3 ("Bluetooth: btusb: Add setup callback for chip init on USB")
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fb97a8e25aa54fa436734aa86f41b2813ba33cd
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Sat Dec 21 14:16:54 2019 +1100

    powerpc/mm: Mark get_slice_psize() & slice_addr_is_low() as notrace
    
    commit 91a063c956084fb21cf2523bce6892514e3f1799 upstream.
    
    These slice routines are called from the SLB miss handler, which can
    lead to warnings from the IRQ code, because we have not reconciled the
    IRQ state properly:
    
      WARNING: CPU: 72 PID: 30150 at arch/powerpc/kernel/irq.c:258 arch_local_irq_restore.part.0+0xcc/0x100
      Modules linked in:
      CPU: 72 PID: 30150 Comm: ftracetest Not tainted 5.5.0-rc2-gcc9x-g7e0165b2f1a9 #1
      NIP:  c00000000001d83c LR: c00000000029ab90 CTR: c00000000026cf90
      REGS: c0000007eee3b960 TRAP: 0700   Not tainted  (5.5.0-rc2-gcc9x-g7e0165b2f1a9)
      MSR:  8000000000021033 <SF,ME,IR,DR,RI,LE>  CR: 22242844  XER: 20000000
      CFAR: c00000000001d780 IRQMASK: 0
      ...
      NIP arch_local_irq_restore.part.0+0xcc/0x100
      LR  trace_graph_entry+0x270/0x340
      Call Trace:
        trace_graph_entry+0x254/0x340 (unreliable)
        function_graph_enter+0xe4/0x1a0
        prepare_ftrace_return+0xa0/0x130
        ftrace_graph_caller+0x44/0x94       # (get_slice_psize())
        slb_allocate_user+0x7c/0x100
        do_slb_fault+0xf8/0x300
        instruction_access_slb_common+0x140/0x180
    
    Fixes: 48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191221121337.4894-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc51beb1637c89b0c81c3548061a689e9d708f18
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Wed Dec 18 12:47:20 2019 +0800

    regulator: axp20x: Fix AXP22x ELDO2 regulator enable bitmask
    
    commit f40ddaa059fdfb472e3aeb733c6220d8e0633a47 upstream.
    
    A copy-paste error was introduced when bitmasks were converted to
    macros, incorrectly setting the enable bitmask for ELDO2 to the one
    for ELDO1 for the AXP22x units.
    
    Fix it by using the correct macro.
    
    On affected boards, ELDO1 and/or ELDO2 are used to power the camera,
    which is currently unsupported.
    
    Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20191218044720.21990-1-wens@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6eeb06587f4053fd586969499af90274f16dabf
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Tue Dec 24 09:58:23 2019 +0900

    spi: uniphier: Fix FIFO threshold
    
    commit 9cd34efbd3012171c102910ce17ee632a3cccb44 upstream.
    
    Rx threshold means the value to inform the receiver when the number of words
    in Rx FIFO is equal to or more than the value. Similarly, Tx threshold means
    the value to inform the sender when the number of words in Tx FIFO is equal
    to or less than the value. The controller triggers the driver to start
    the transfer.
    
    In case of Rx, the driver wants to detect that the specified number of words
    N are in Rx FIFO, so the value of Rx threshold should be N. In case of Tx,
    the driver wants to detect that the same number of spaces as Rx are in
    Tx FIFO, so the value of Tx threshold should be (FIFO size - N).
    
    For example, in order for the driver to receive at least 3 words from
    Rx FIFO, set 3 to Rx threshold.
       +-+-+-+-+-+-+-+-+
       | | | | | |*|*|*|
       +-+-+-+-+-+-+-+-+
    
    In order for the driver to send at least 3 words to Tx FIFO, because
    it needs at least 3 spaces, set 8(FIFO size) - 3 = 5 to Tx threshold.
       +-+-+-+-+-+-+-+-+
       |*|*|*|*|*| | | |
       +-+-+-+-+-+-+-+-+
    
    This adds new function uniphier_spi_set_fifo_threshold() to set
    threshold value to the register.
    
    And more, FIFO counts by 'words', so this renames 'fill_bytes' with
    'fill_words', and fixes the calculation using bytes_per_words.
    
    Fixes: 37ffab817098 ("spi: uniphier: introduce polling mode")
    Cc: Keiji Hayashibara <hayashibara.keiji@socionext.com>
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Link: https://lore.kernel.org/r/1577149107-30670-2-git-send-email-hayashi.kunihiko@socionext.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39add6227821dd1c23b8d221660a8a25f5536501
Author: Axel Lin <axel.lin@ingics.com>
Date:   Wed Jan 1 10:24:06 2020 +0800

    regulator: bd70528: Remove .set_ramp_delay for bd70528_ldo_ops
    
    commit 6f1ff76154b8b36033efcbf6453a71a3d28f52cd upstream.
    
    The .set_ramp_delay should be for bd70528_buck_ops only.
    Setting .set_ramp_delay for for bd70528_ldo_ops causes problem because
    BD70528_MASK_BUCK_RAMP (0x10) overlaps with BD70528_MASK_LDO_VOLT (0x1f).
    So setting ramp_delay for LDOs may change the voltage output, fix it.
    
    Fixes: 99ea37bd1e7d ("regulator: bd70528: Support ROHM BD70528 regulator block")
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
    Link: https://lore.kernel.org/r/20200101022406.15176-1-axel.lin@ingics.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25b48ee49164de288a4fcdd2031c155da966c39d
Author: Axel Lin <axel.lin@ingics.com>
Date:   Sat Dec 21 16:10:49 2019 +0800

    regulator: axp20x: Fix axp20x_set_ramp_delay
    
    commit 71dd2fe5dec171b34b71603a81bb46c24c498fde upstream.
    
    Current code set incorrect bits when set ramp_delay for AXP20X_DCDC2,
    fix it.
    
    Fixes: d29f54df8b16 ("regulator: axp20x: add support for set_ramp_delay for AXP209")
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Link: https://lore.kernel.org/r/20191221081049.32490-1-axel.lin@ingics.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5b89e112483b4b9b1fb1825f4c924afc79611bf
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Dec 6 20:42:59 2019 +0800

    watchdog: tqmx86_wdt: Fix build error
    
    commit 9a6c274ac1c4346f5384f2290caeb42dc674c471 upstream.
    
    If TQMX86_WDT is y and WATCHDOG_CORE is m, building fails:
    
    drivers/watchdog/tqmx86_wdt.o: In function `tqmx86_wdt_probe':
    tqmx86_wdt.c:(.text+0x46e): undefined reference to `watchdog_init_timeout'
    tqmx86_wdt.c:(.text+0x4e0): undefined reference to `devm_watchdog_register_device'
    
    Select WATCHDOG_CORE to fix this.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: e3c21e088f89 ("watchdog: tqmx86: Add watchdog driver for the IO controller")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20191206124259.25880-1-yuehaibing@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bac47f2ee76ad9097ffdf5f08e209ef3952f9771
Author: Alexander Lobakin <alobakin@dlink.ru>
Date:   Wed Dec 18 12:18:21 2019 +0300

    net, sysctl: Fix compiler warning when only cBPF is present
    
    commit 1148f9adbe71415836a18a36c1b4ece999ab0973 upstream.
    
    proc_dointvec_minmax_bpf_restricted() has been firstly introduced
    in commit 2e4a30983b0f ("bpf: restrict access to core bpf sysctls")
    under CONFIG_HAVE_EBPF_JIT. Then, this ifdef has been removed in
    ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv
    allocations"), because a new sysctl, bpf_jit_limit, made use of it.
    Finally, this parameter has become long instead of integer with
    fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
    and thus, a new proc_dolongvec_minmax_bpf_restricted() has been
    added.
    
    With this last change, we got back to that
    proc_dointvec_minmax_bpf_restricted() is used only under
    CONFIG_HAVE_EBPF_JIT, but the corresponding ifdef has not been
    brought back.
    
    So, in configurations like CONFIG_BPF_JIT=y && CONFIG_HAVE_EBPF_JIT=n
    since v4.20 we have:
    
      CC      net/core/sysctl_net_core.o
    net/core/sysctl_net_core.c:292:1: warning: ‘proc_dointvec_minmax_bpf_restricted’ defined but not used [-Wunused-function]
      292 | proc_dointvec_minmax_bpf_restricted(struct ctl_table *table, int write,
          | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Suppress this by guarding it with CONFIG_HAVE_EBPF_JIT again.
    
    Fixes: fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
    Signed-off-by: Alexander Lobakin <alobakin@dlink.ru>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20191218091821.7080-1-alobakin@dlink.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d8ff70c73b14c12040e593f9aa60ea01238f686
Author: Marco Oliverio <marco.oliverio@tanaza.com>
Date:   Mon Dec 2 19:54:30 2019 +0100

    netfilter: nf_queue: enqueue skbs with NULL dst
    
    commit 0b9173f4688dfa7c5d723426be1d979c24ce3d51 upstream.
    
    Bridge packets that are forwarded have skb->dst == NULL and get
    dropped by the check introduced by
    b60a77386b1d4868f72f6353d35dabe5fbe981f2 (net: make skb_dst_force
    return true when dst is refcounted).
    
    To fix this we check skb_dst() before skb_dst_force(), so we don't
    drop skb packet with dst == NULL. This holds also for skb at the
    PRE_ROUTING hook so we remove the second check.
    
    Fixes: b60a77386b1d ("net: make skb_dst_force return true when dst is refcounted")
    Signed-off-by: Marco Oliverio <marco.oliverio@tanaza.com>
    Signed-off-by: Rocco Folino <rocco.folino@tanaza.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6cc75f1d705fe420bb95179afad6bfe4e141f21
Author: Michael Haener <michael.haener@siemens.com>
Date:   Fri Nov 29 10:16:49 2019 +0100

    platform/x86: pmc_atom: Add Siemens CONNECT X300 to critclk_systems DMI table
    
    commit e8796c6c69d129420ee94a1906b18d86b84644d4 upstream.
    
    The CONNECT X300 uses the PMC clock for on-board components and gets
    stuck during boot if the clock is disabled. Therefore, add this
    device to the critical systems list.
    Tested on CONNECT X300.
    
    Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    Signed-off-by: Michael Haener <michael.haener@siemens.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c440a4d1f3a088ff0923e3853829e0a7a9b610f
Author: Omar Sandoval <osandov@fb.com>
Date:   Tue Nov 26 16:58:08 2019 -0800

    xfs: don't check for AG deadlock for realtime files in bunmapi
    
    commit 69ffe5960df16938bccfe1b65382af0b3de51265 upstream.
    
    Commit 5b094d6dac04 ("xfs: fix multi-AG deadlock in xfs_bunmapi") added
    a check in __xfs_bunmapi() to stop early if we would touch multiple AGs
    in the wrong order. However, this check isn't applicable for realtime
    files. In most cases, it just makes us do unnecessary commits. However,
    without the fix from the previous commit ("xfs: fix realtime file data
    space leak"), if the last and second-to-last extents also happen to have
    different "AG numbers", then the break actually causes __xfs_bunmapi()
    to return without making any progress, which sends
    xfs_itruncate_extents_flags() into an infinite loop.
    
    Fixes: 5b094d6dac04 ("xfs: fix multi-AG deadlock in xfs_bunmapi")
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7da501c21a4aab22956c9323e04453a7ebe329d2
Author: Wen Yang <wenyang@linux.alibaba.com>
Date:   Mon Nov 25 23:54:09 2019 +0800

    firmware: arm_scmi: Avoid double free in error flow
    
    commit 8305e90a894f82c278c17e51a28459deee78b263 upstream.
    
    If device_register() fails, both put_device() and kfree() are called,
    ending with a double free of the scmi_dev.
    
    Calling kfree() is needed only when a failure happens between the
    allocation of the scmi_dev and its registration, so move it to there
    and remove it from the error flow.
    
    Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback")
    Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d29dc60aac16831b1822c831a7f40b45a9686d9
Author: Paulo Alcantara (SUSE) <pc@cjr.nz>
Date:   Fri Nov 22 12:30:53 2019 -0300

    cifs: Fix potential softlockups while refreshing DFS cache
    
    commit 84a1f5b1cc6fd7f6cd99fc5630c36f631b19fa60 upstream.
    
    We used to skip reconnects on all SMB2_IOCTL commands due to SMB3+
    FSCTL_VALIDATE_NEGOTIATE_INFO - which made sense since we're still
    establishing a SMB session.
    
    However, when refresh_cache_worker() calls smb2_get_dfs_refer() and
    we're under reconnect, SMB2_ioctl() will not be able to get a proper
    status error (e.g. -EHOSTDOWN in case we failed to reconnect) but an
    -EAGAIN from cifs_send_recv() thus looping forever in
    refresh_cache_worker().
    
    Fixes: e99c63e4d86d ("SMB3: Fix deadlock in validate negotiate hits reconnect")
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Suggested-by: Aurelien Aptel <aaptel@suse.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6eaf5653ddab9ce8572f50d2e477e8cddba4994d
Author: Frank Rowand <frank.rowand@sony.com>
Date:   Thu Nov 21 13:16:56 2019 -0600

    of: overlay: add_changeset_property() memory leak
    
    commit 637392a8506a3a7dd24ab9094a14f7522adb73b4 upstream.
    
    No changeset entries are created for #address-cells and #size-cells
    properties, but the duplicated properties are never freed.  This
    results in a memory leak which is detected by kmemleak:
    
     unreferenced object 0x85887180 (size 64):
       backtrace:
         kmem_cache_alloc_trace+0x1fb/0x1fc
         __of_prop_dup+0x25/0x7c
         add_changeset_property+0x17f/0x370
         build_changeset_next_level+0x29/0x20c
         of_overlay_fdt_apply+0x32b/0x6b4
         ...
    
    Fixes: 6f75118800ac ("of: overlay: validate overlay properties #address-cells and #size-cells")
    Reported-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Frank Rowand <frank.rowand@sony.com>
    Tested-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f2c72738dce49a62a69e81ec1ceeab16d23eec3
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Wed Nov 20 14:10:16 2019 +0800

    iommu/vt-d: Remove incorrect PSI capability check
    
    commit f81b846dcd9a1e6d120f73970a9a98b7fcaaffba upstream.
    
    The PSI (Page Selective Invalidation) bit in the capability register
    is only valid for second-level translation. Intel IOMMU supporting
    scalable mode must support page/address selective IOTLB invalidation
    for first-level translation. Remove the PSI capability check in SVA
    cache invalidation code.
    
    Fixes: 8744daf4b0699 ("iommu/vt-d: Remove global page flush support")
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 632a300260a852069784802b7a33e954ed1dc31f
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu Nov 14 16:25:38 2019 +0200

    perf callchain: Fix segfault in thread__resolve_callchain_sample()
    
    commit aceb98261ea7d9fe38f9c140c5531f0b13623832 upstream.
    
    Do not dereference 'chain' when it is NULL.
    
      $ perf record -e intel_pt//u -e branch-misses:u uname
      $ perf report --itrace=l --branch-history
      perf: Segmentation fault
    
    Fixes: e9024d519d89 ("perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Link: http://lore.kernel.org/lkml/20191114142538.4097-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58501792851d3c1ed64a8df98933ebf233b2e2bf
Author: Yunfeng Ye <yeyunfeng@huawei.com>
Date:   Thu Nov 14 15:16:24 2019 +0800

    ACPI: sysfs: Change ACPI_MASKABLE_GPE_MAX to 0x100
    
    commit a7583e72a5f22470d3e6fd3b6ba912892242339f upstream.
    
    The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel
    parameter cover all GPEs") says:
      "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256
       GPEs can be masked"
    
    But the masking of GPE 0xFF it not supported and the check condition
    "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is
    u8.
    
    So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe >
    ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for
    acpi_mask_gpe parameter.
    
    Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs")
    Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
    [ rjw: Use u16 as gpe data type in acpi_gpe_apply_masked_gpes() ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e102037f87b9ace4b8531bce1b97b7d0f83fcd7
Author: Konstantin Khorenko <khorenko@virtuozzo.com>
Date:   Wed Nov 13 12:29:50 2019 +0300

    kernel/module.c: wakeup processes in module_wq on module unload
    
    commit 5d603311615f612320bb77bd2a82553ef1ced5b7 upstream.
    
    Fix the race between load and unload a kernel module.
    
    sys_delete_module()
     try_stop_module()
      mod->state = _GOING
                                            add_unformed_module()
                                             old = find_module_all()
                                             (old->state == _GOING =>
                                              wait_event_interruptible())
    
                                             During pre-condition
                                             finished_loading() rets 0
                                             schedule()
                                             (never gets waken up later)
     free_module()
      mod->state = _UNFORMED
       list_del_rcu(&mod->list)
       (dels mod from "modules" list)
    
    return
    
    The race above leads to modprobe hanging forever on loading
    a module.
    
    Error paths on loading module call wake_up_all(&module_wq) after
    freeing module, so let's do the same on straight module unload.
    
    Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading")
    Reviewed-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b91237c52549da9890b69b751d96042c7c2dcdf
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Nov 8 08:45:23 2019 -0800

    net/sched: annotate lockless accesses to qdisc->empty
    
    commit 90b2be27bb0e56483f335cc10fb59ec66882b949 upstream.
    
    KCSAN reported the following race [1]
    
    BUG: KCSAN: data-race in __dev_queue_xmit / net_tx_action
    
    read to 0xffff8880ba403508 of 1 bytes by task 21814 on cpu 1:
     __dev_xmit_skb net/core/dev.c:3389 [inline]
     __dev_queue_xmit+0x9db/0x1b40 net/core/dev.c:3761
     dev_queue_xmit+0x21/0x30 net/core/dev.c:3825
     neigh_hh_output include/net/neighbour.h:500 [inline]
     neigh_output include/net/neighbour.h:509 [inline]
     ip6_finish_output2+0x873/0xec0 net/ipv6/ip6_output.c:116
     __ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
     __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
     ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
     NF_HOOK_COND include/linux/netfilter.h:294 [inline]
     ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
     dst_output include/net/dst.h:436 [inline]
     ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179
     ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795
     udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173
     udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471
     inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576
     sock_sendmsg_nosec net/socket.c:637 [inline]
     sock_sendmsg+0x9f/0xc0 net/socket.c:657
     ___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311
     __sys_sendmmsg+0x123/0x350 net/socket.c:2413
     __do_sys_sendmmsg net/socket.c:2442 [inline]
     __se_sys_sendmmsg net/socket.c:2439 [inline]
     __x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439
     do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    write to 0xffff8880ba403508 of 1 bytes by interrupt on cpu 0:
     qdisc_run_begin include/net/sch_generic.h:160 [inline]
     qdisc_run include/net/pkt_sched.h:120 [inline]
     net_tx_action+0x2b1/0x6c0 net/core/dev.c:4551
     __do_softirq+0x115/0x33f kernel/softirq.c:292
     do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1082
     do_softirq.part.0+0x6b/0x80 kernel/softirq.c:337
     do_softirq kernel/softirq.c:329 [inline]
     __local_bh_enable_ip+0x76/0x80 kernel/softirq.c:189
     local_bh_enable include/linux/bottom_half.h:32 [inline]
     rcu_read_unlock_bh include/linux/rcupdate.h:688 [inline]
     ip6_finish_output2+0x7bb/0xec0 net/ipv6/ip6_output.c:117
     __ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
     __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
     ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
     NF_HOOK_COND include/linux/netfilter.h:294 [inline]
     ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
     dst_output include/net/dst.h:436 [inline]
     ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179
     ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795
     udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173
     udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471
     inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576
     sock_sendmsg_nosec net/socket.c:637 [inline]
     sock_sendmsg+0x9f/0xc0 net/socket.c:657
     ___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311
     __sys_sendmmsg+0x123/0x350 net/socket.c:2413
     __do_sys_sendmmsg net/socket.c:2442 [inline]
     __se_sys_sendmmsg net/socket.c:2439 [inline]
     __x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439
     do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 21817 Comm: syz-executor.2 Not tainted 5.4.0-rc6+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: d518d2ed8640 ("net/sched: fix race between deactivation and dequeue for NOLOCK qdisc")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Davide Caratti <dcaratti@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 440d3e7beb60a19d82d75692a5f44c5d20a84923
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Thu Nov 7 22:28:11 2019 +0800

    HID: i2c-hid: Reset ALPS touchpads on resume
    
    commit fd70466d37bf3fe0118d18c56ddde85b428f86cf upstream.
    
    Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system
    resume") fixes many touchpads and touchscreens, however ALPS touchpads
    start to trigger IRQ storm after system resume.
    
    Since it's total silence from ALPS, let's bring the old behavior back
    to ALPS touchpads.
    
    Fixes: 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e9d2e5f7141cb48a52063a56f73aaa56652ec6b
Author: Alastair D'Silva <alastair@d-silva.org>
Date:   Mon Nov 4 13:32:57 2019 +1100

    powerpc: Chunk calls to flush_dcache_range in arch_*_memory
    
    commit 076265907cf9633bbef861c7c2a1c26a8209f283 upstream.
    
    When presented with large amounts of memory being hotplugged
    (in my test case, ~890GB), the call to flush_dcache_range takes
    a while (~50 seconds), triggering RCU stalls.
    
    This patch breaks up the call into 1GB chunks, calling
    cond_resched() inbetween to allow the scheduler to run.
    
    Fixes: fb5924fddf9e ("powerpc/mm: Flush cache on memory hot(un)plug")
    Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191104023305.9581-6-alastair@au1.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af8547549041936848c96bc3d5fddcd33ba9c0d2
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Wed Oct 9 15:11:37 2019 -0400

    nfsd4: fix up replay_matches_cache()
    
    commit 6e73e92b155c868ff7fce9d108839668caf1d9be upstream.
    
    When running an nfs stress test, I see quite a few cached replies that
    don't match up with the actual request.  The first comment in
    replay_matches_cache() makes sense, but the code doesn't seem to
    match... fix it.
    
    This isn't exactly a bugfix, as the server isn't required to catch every
    case of a false retry.  So, we may as well do this, but if this is
    fixing a problem then that suggests there's a client bug.
    
    Fixes: 53da6a53e1d4 ("nfsd4: catch some false session retries")
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c87a84c5ebcc4d94146bba3360d3ae26ea93b25c
Author: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Date:   Wed Oct 2 12:07:56 2019 -0700

    arm64: dts: qcom: msm8998-clamshell: Remove retention idle state
    
    commit b40dd23f9a8987c8336df0a00e33f52b1f3f19ad upstream.
    
    The retention idle state does not appear to be supported by the firmware
    present on the msm8998 laptops since the state is advertised as disabled
    in ACPI, and attempting to enable the state in DT is observed to result
    in boot hangs.  Therefore, remove the state from use to address the
    observed issues.
    
    Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
    Fixes: 2c6d2d3a580a (arm64: dts: qcom: Add Lenovo Miix 630)
    Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d4a0a31ce70b3d45e7605a7f3ef94c072eb43de
Author: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Date:   Tue Oct 1 11:03:59 2019 +0300

    sunrpc: fix crash when cache_head become valid before update
    
    commit 5fcaf6982d1167f1cd9b264704f6d1ef4c505d54 upstream.
    
    I was investigating a crash in our Virtuozzo7 kernel which happened in
    in svcauth_unix_set_client. I found out that we access m_client field
    in ip_map structure, which was received from sunrpc_cache_lookup (we
    have a bit older kernel, now the code is in sunrpc_cache_add_entry), and
    these field looks uninitialized (m_client == 0x74 don't look like a
    pointer) but in the cache_head in flags we see 0x1 which is CACHE_VALID.
    
    It looks like the problem appeared from our previous fix to sunrpc (1):
    commit 4ecd55ea0742 ("sunrpc: fix cache_head leak due to queued
    request")
    
    And we've also found a patch already fixing our patch (2):
    commit d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")
    
    Though the crash is eliminated, I think the core of the problem is not
    completely fixed:
    
    Neil in the patch (2) makes cache_head CACHE_NEGATIVE, before
    cache_fresh_locked which was added in (1) to fix crash. These way
    cache_is_valid won't say the cache is valid anymore and in
    svcauth_unix_set_client the function cache_check will return error
    instead of 0, and we don't count entry as initialized.
    
    But it looks like we need to remove cache_fresh_locked completely in
    sunrpc_cache_lookup:
    
    In (1) we've only wanted to make cache_fresh_unlocked->cache_dequeue so
    that cache_requests with no readers also release corresponding
    cache_head, to fix their leak.  We with Vasily were not sure if
    cache_fresh_locked and cache_fresh_unlocked should be used in pair or
    not, so we've guessed to use them in pair.
    
    Now we see that we don't want the CACHE_VALID bit set here by
    cache_fresh_locked, as "valid" means "initialized" and there is no
    initialization in sunrpc_cache_add_entry. Both expiry_time and
    last_refresh are not used in cache_fresh_unlocked code-path and also not
    required for the initial fix.
    
    So to conclude cache_fresh_locked was called by mistake, and we can just
    safely remove it instead of crutching it with CACHE_NEGATIVE. It looks
    ideologically better for me. Hope I don't miss something here.
    
    Here is our crash backtrace:
    [13108726.326291] BUG: unable to handle kernel NULL pointer dereference at 0000000000000074
    [13108726.326365] IP: [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
    [13108726.326448] PGD 0
    [13108726.326468] Oops: 0002 [#1] SMP
    [13108726.326497] Modules linked in: nbd isofs xfs loop kpatch_cumulative_81_0_r1(O) xt_physdev nfnetlink_queue bluetooth rfkill ip6table_nat nf_nat_ipv6 ip_vs_wrr ip_vs_wlc ip_vs_sh nf_conntrack_netlink ip_vs_sed ip_vs_pe_sip nf_conntrack_sip ip_vs_nq ip_vs_lc ip_vs_lblcr ip_vs_lblc ip_vs_ftp ip_vs_dh nf_nat_ftp nf_conntrack_ftp iptable_raw xt_recent nf_log_ipv6 xt_hl ip6t_rt nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_TCPMSS xt_tcpmss vxlan ip6_udp_tunnel udp_tunnel xt_statistic xt_NFLOG nfnetlink_log dummy xt_mark xt_REDIRECT nf_nat_redirect raw_diag udp_diag tcp_diag inet_diag netlink_diag af_packet_diag unix_diag rpcsec_gss_krb5 xt_addrtype ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 ebtable_nat ebtable_broute nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle ip6table_raw nfsv4
    [13108726.327173]  dns_resolver cls_u32 binfmt_misc arptable_filter arp_tables ip6table_filter ip6_tables devlink fuse_kio_pcs ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_wdog_tmo xt_multiport bonding xt_set xt_conntrack iptable_filter iptable_mangle kpatch(O) ebtable_filter ebt_among ebtables ip_set_hash_ip ip_set nfnetlink vfat fat skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass fuse pcspkr ses enclosure joydev sg mei_me hpwdt hpilo lpc_ich mei ipmi_si shpchp ipmi_devintf ipmi_msghandler xt_ipvs acpi_power_meter ip_vs_rr nfsv3 nfsd auth_rpcgss nfs_acl nfs lockd grace fscache nf_nat cls_fw sch_htb sch_cbq sch_sfq ip_vs em_u32 nf_conntrack tun br_netfilter veth overlay ip6_vzprivnet ip6_vznetstat ip_vznetstat
    [13108726.327817]  ip_vzprivnet vziolimit vzevent vzlist vzstat vznetstat vznetdev vzmon vzdev bridge pio_kaio pio_nfs pio_direct pfmt_raw pfmt_ploop1 ploop ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper scsi_transport_iscsi 8021q syscopyarea sysfillrect garp sysimgblt fb_sys_fops mrp stp ttm llc bnx2x crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel drm dm_multipath ghash_clmulni_intel uas aesni_intel lrw gf128mul glue_helper ablk_helper cryptd tg3 smartpqi scsi_transport_sas mdio libcrc32c i2c_core usb_storage ptp pps_core wmi sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: kpatch_cumulative_82_0_r1]
    [13108726.328403] CPU: 35 PID: 63742 Comm: nfsd ve: 51332 Kdump: loaded Tainted: G        W  O   ------------   3.10.0-862.20.2.vz7.73.29 #1 73.29
    [13108726.328491] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 10/02/2018
    [13108726.328554] task: ffffa0a6a41b1160 ti: ffffa0c2a74bc000 task.ti: ffffa0c2a74bc000
    [13108726.328610] RIP: 0010:[<ffffffffc01f79eb>]  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
    [13108726.328706] RSP: 0018:ffffa0c2a74bfd80  EFLAGS: 00010246
    [13108726.328750] RAX: 0000000000000001 RBX: ffffa0a6183ae000 RCX: 0000000000000000
    [13108726.328811] RDX: 0000000000000074 RSI: 0000000000000286 RDI: ffffa0c2a74bfcf0
    [13108726.328864] RBP: ffffa0c2a74bfe00 R08: ffffa0bab8c22960 R09: 0000000000000001
    [13108726.328916] R10: 0000000000000001 R11: 0000000000000001 R12: ffffa0a32aa7f000
    [13108726.328969] R13: ffffa0a6183afac0 R14: ffffa0c233d88d00 R15: ffffa0c2a74bfdb4
    [13108726.329022] FS:  0000000000000000(0000) GS:ffffa0e17f9c0000(0000) knlGS:0000000000000000
    [13108726.329081] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [13108726.332311] CR2: 0000000000000074 CR3: 00000026a1b28000 CR4: 00000000007607e0
    [13108726.334606] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [13108726.336754] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [13108726.338908] PKRU: 00000000
    [13108726.341047] Call Trace:
    [13108726.343074]  [<ffffffff8a2c78b4>] ? groups_alloc+0x34/0x110
    [13108726.344837]  [<ffffffffc01f5eb4>] svc_set_client+0x24/0x30 [sunrpc]
    [13108726.346631]  [<ffffffffc01f2ac1>] svc_process_common+0x241/0x710 [sunrpc]
    [13108726.348332]  [<ffffffffc01f3093>] svc_process+0x103/0x190 [sunrpc]
    [13108726.350016]  [<ffffffffc07d605f>] nfsd+0xdf/0x150 [nfsd]
    [13108726.351735]  [<ffffffffc07d5f80>] ? nfsd_destroy+0x80/0x80 [nfsd]
    [13108726.353459]  [<ffffffff8a2bf741>] kthread+0xd1/0xe0
    [13108726.355195]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
    [13108726.356896]  [<ffffffff8a9556dd>] ret_from_fork_nospec_begin+0x7/0x21
    [13108726.358577]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
    [13108726.360240] Code: 4c 8b 45 98 0f 8e 2e 01 00 00 83 f8 fe 0f 84 76 fe ff ff 85 c0 0f 85 2b 01 00 00 49 8b 50 40 b8 01 00 00 00 48 89 93 d0 1a 00 00 <f0> 0f c1 02 83 c0 01 83 f8 01 0f 8e 53 02 00 00 49 8b 44 24 38
    [13108726.363769] RIP  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
    [13108726.365530]  RSP <ffffa0c2a74bfd80>
    [13108726.367179] CR2: 0000000000000074
    
    Fixes: d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")
    Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Acked-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89dda19e77ce019582ce1d7f19396de6ad846091
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Tue Sep 24 10:26:53 2019 +0300

    PM / devfreq: Check NULL governor in available_governors_show
    
    commit d68adc8f85cd757bd33c8d7b2660ad6f16f7f3dc upstream.
    
    The governor is initialized after sysfs attributes become visible so in
    theory the governor field can be NULL here.
    
    Fixes: bcf23c79c4e46 ("PM / devfreq: Fix available_governor sysfs")
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe8adb0aae33905bdd6b682907d8c48b1857ec99
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Sep 18 21:57:07 2019 +0200

    drm/msm: include linux/sched/task.h
    
    commit 70082a52f96a45650dfc3d8cdcd2c42bdac9f6f0 upstream.
    
    Without this header file, compile-testing may run into a missing
    declaration:
    
    drivers/gpu/drm/msm/msm_gpu.c:444:4: error: implicit declaration of function 'put_task_struct' [-Werror,-Wimplicit-function-declaration]
    
    Fixes: 482f96324a4e ("drm/msm: Fix task dump in gpu recovery")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit accc08f40655159c0906c724d80d42099bec4eef
Author: Vladimir Oltean <olteanv@gmail.com>
Date:   Sat Dec 28 15:55:36 2019 +0200

    spi: spi-fsl-dspi: Fix 16-bit word order in 32-bit XSPI mode
    
    commit ca59d5a51690d5b9340343dc36792a252e9414ae upstream.
    
    When used in Extended SPI mode on LS1021A, the DSPI controller wants to
    have the least significant 16-bit word written first to the TX FIFO.
    
    In fact, the LS1021A reference manual says:
    
    33.5.2.4.2 Draining the TX FIFO
    
    When Extended SPI Mode (DSPIx_MCR[XSPI]) is enabled, if the frame size
    of SPI Data to be transmitted is more than 16 bits, then it causes two
    Data entries to be popped from TX FIFO simultaneously which are
    transferred to the shift register. The first of the two popped entries
    forms the 16 least significant bits of the SPI frame to be transmitted.
    
    So given the following TX buffer:
    
     +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
     | 0x0 | 0x1 | 0x2 | 0x3 | 0x4 | 0x5 | 0x6 | 0x7 | 0x8 | 0x9 | 0xa | 0xb |
     +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
     |     32-bit word 1     |     32-bit word 2     |     32-bit word 3     |
     +-----------------------+-----------------------+-----------------------+
    
    The correct way that a little-endian system should transmit it on the
    wire when bits_per_word is 32 is:
    
    0x03020100
    0x07060504
    0x0b0a0908
    
    But it is actually transmitted as following, as seen with a scope:
    
    0x01000302
    0x05040706
    0x09080b0a
    
    It appears that this patch has been submitted at least once before:
    https://lkml.org/lkml/2018/9/21/286
    but in that case Chuanhua Han did not manage to explain the problem
    clearly enough and the patch did not get merged, leaving XSPI mode
    broken.
    
    Fixes: 8fcd151d2619 ("spi: spi-fsl-dspi: XSPI FIFO handling (in TCFQ mode)")
    Cc: Esben Haabendal <eha@deif.com>
    Cc: Chuanhua Han <chuanhua.han@nxp.com>
    Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20191228135536.14284-1-olteanv@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0629ee3922f10112584b1898491fecc74d98b3b
Author: Wen Yang <wenyang@linux.alibaba.com>
Date:   Fri Jan 3 11:02:48 2020 +0800

    ftrace: Avoid potential division by zero in function profiler
    
    commit e31f7939c1c27faa5d0e3f14519eaf7c89e8a69d upstream.
    
    The ftrace_profile->counter is unsigned long and
    do_div truncates it to 32 bits, which means it can test
    non-zero and be truncated to zero for division.
    Fix this issue by using div64_ul() instead.
    
    Link: http://lkml.kernel.org/r/20200103030248.14516-1-wenyang@linux.alibaba.com
    
    Cc: stable@vger.kernel.org
    Fixes: e330b3bcd8319 ("tracing: Show sample std dev in function profiling")
    Fixes: 34886c8bc590f ("tracing: add average time in function to function profiler")
    Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 623e5ae074fe95e960ff588fd7d2ee2299c2704e
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Mon Jan 6 14:35:39 2020 +0000

    arm64: Revert support for execute-only user mappings
    
    commit 24cecc37746393432d994c0dbc251fb9ac7c5d72 upstream.
    
    The ARMv8 64-bit architecture supports execute-only user permissions by
    clearing the PTE_USER and PTE_UXN bits, practically making it a mostly
    privileged mapping but from which user running at EL0 can still execute.
    
    The downside, however, is that the kernel at EL1 inadvertently reading
    such mapping would not trip over the PAN (privileged access never)
    protection.
    
    Revert the relevant bits from commit cab15ce604e5 ("arm64: Introduce
    execute-only page access permissions") so that PROT_EXEC implies
    PROT_READ (and therefore PTE_USER) until the architecture gains proper
    support for execute-only user mappings.
    
    Fixes: cab15ce604e5 ("arm64: Introduce execute-only page access permissions")
    Cc: <stable@vger.kernel.org> # 4.9.x-
    Acked-by: Will Deacon <will@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66d9052e6c765f74fa4a1bce874fab29a6b9583d
Author: chenqiwu <chenqiwu@xiaomi.com>
Date:   Thu Dec 19 14:29:53 2019 +0800

    exit: panic before exit_mm() on global init exit
    
    commit 43cf75d96409a20ef06b756877a2e72b10a026fc upstream.
    
    Currently, when global init and all threads in its thread-group have exited
    we panic via:
    do_exit()
    -> exit_notify()
       -> forget_original_parent()
          -> find_child_reaper()
    This makes it hard to extract a useable coredump for global init from a
    kernel crashdump because by the time we panic exit_mm() will have already
    released global init's mm.
    This patch moves the panic futher up before exit_mm() is called. As was the
    case previously, we only panic when global init and all its threads in the
    thread-group have exited.
    
    Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    [christian.brauner@ubuntu.com: fix typo, rewrite commit message]
    Link: https://lore.kernel.org/r/1576736993-10121-1-git-send-email-qiwuchen55@gmail.com
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 858f090696ca51f520ed002c781acd0f7d2475e3
Author: James Smart <jsmart2021@gmail.com>
Date:   Sat Sep 21 20:58:51 2019 -0700

    scsi: lpfc: Fix rpi release when deleting vport
    
    commit 97acd0019d5dadd9c0e111c2083c889bfe548f25 upstream.
    
    A prior use-after-free mailbox fix solved it's problem by null'ing a ndlp
    pointer.  However, further testing has shown that this change causes a
    later state change to occasionally be skipped, which results in a reference
    count never being decremented thus the rpi is never released, which causes
    a vport delete to never succeed.
    
    Revise the fix in the prior patch to no longer null the ndlp. Instead the
    RELEASE_RPI flag is set which will drive the release of the rpi.
    
    Given the new code was added at a deep indentation level, refactor the code
    block using a new routine that avoids the indentation issues.
    
    Fixes:  9b1640686470 ("scsi: lpfc: Fix use-after-free mailbox cmd completion")
    Link: https://lore.kernel.org/r/20190922035906.10977-6-jsmart2021@gmail.com
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbfc067c211d70f219c11ceaa58f4d759a410489
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 11:09:21 2019 +0100

    ALSA: firewire-motu: Correct a typo in the clock proc string
    
    commit 0929249e3be3bb82ee6cfec0025f4dde952210b3 upstream.
    
    Just fix a typo of "S/PDIF" in the clock name string.
    
    Fixes: 4638ec6ede08 ("ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats")
    Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20191030100921.3826-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d77ae7624782bb947cf71696d28aad2f476fd17e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 8 17:56:26 2019 +0100

    ALSA: pcm: Yet another missing check of non-cached buffer type
    
    commit 2406ff9b86aa1b77fe1a6d15f37195ac1fdb2a14 upstream.
    
    For non-x86 architectures, SNDRV_DMA_TYPE_DEV_UC should be treated
    equivalent with SNDRV_DMA_TYPE_DEV, where the default mmap handler
    still checks only about SNDRV_DMA_TYPE_DEV.  Make the check more
    proper.
    
    Note that all existing users of *_UC buffer types are x86-only, so
    this doesn't fix any bug, but just for consistency.
    
    Fixes: 42e748a0b325 ("ALSA: memalloc: Add non-cached buffer type")
    Link: https://lore.kernel.org/r/20191108165626.5947-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aea6343885a67cd0ff69cba720c7e8538e78cc40
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Nov 22 13:13:54 2019 +0000

    ALSA: cs4236: fix error return comparison of an unsigned integer
    
    commit d60229d84846a8399257006af9c5444599f64361 upstream.
    
    The return from pnp_irq is an unsigned integer type resource_size_t
    and hence the error check for a positive non-error code is always
    going to be true.  A check for a non-failure return from pnp_irq
    should in fact be for (resource_size_t)-1 rather than >= 0.
    
    Addresses-Coverity: ("Unsigned compared against 0")
    Fixes: a9824c868a2c ("[ALSA] Add CS4232 PnP BIOS support")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20191122131354.58042-1-colin.king@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebf3afa3cbd1778131af012531a0f7cc896c6621
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Dec 30 22:20:06 2019 +0900

    gen_initramfs_list.sh: fix 'bad variable name' error
    
    commit cc976614f59bd8e45de8ce988a6bcb5de711d994 upstream.
    
    Prior to commit 858805b336be ("kbuild: add $(BASH) to run scripts with
    bash-extension"), this shell script was almost always run by bash since
    bash is usually installed on the system by default.
    
    Now, this script is run by sh, which might be a symlink to dash. On such
    distributions, the following code emits an error:
    
      local dev=`LC_ALL=C ls -l "${location}"`
    
    You can reproduce the build error, for example by setting
    CONFIG_INITRAMFS_SOURCE="/dev".
    
        GEN     usr/initramfs_data.cpio.gz
      ./usr/gen_initramfs_list.sh: 131: local: 1: bad variable name
      make[1]: *** [usr/Makefile:61: usr/initramfs_data.cpio.gz] Error 2
    
    This is because `LC_ALL=C ls -l "${location}"` contains spaces.
    Surrounding it with double-quotes fixes the error.
    
    Fixes: 858805b336be ("kbuild: add $(BASH) to run scripts with bash-extension")
    Reported-by: Jory A. Pratt <anarchy@gentoo.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdfd8f9ef2d3a35764e8fabc035bd0bbb382e318
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Fri Dec 20 15:11:00 2019 +0200

    dmaengine: virt-dma: Fix access after free in vchan_complete()
    
    commit 24461d9792c2c706092805ff1b067628933441bd upstream.
    
    vchan_vdesc_fini() is freeing up 'vd' so the access to vd->tx_result is
    via already freed up memory.
    
    Move the vchan_vdesc_fini() after invoking the callback to avoid this.
    
    Fixes: 09d5b702b0f97 ("dmaengine: virt-dma: store result on dma descriptor")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Link: https://lore.kernel.org/r/20191220131100.21804-1-peter.ujfalusi@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0d2bf5a012974c2f718ce41dbff185666eae11f
Author: John Johansen <john.johansen@canonical.com>
Date:   Thu Jan 2 05:31:22 2020 -0800

    apparmor: fix aa_xattrs_match() may sleep while holding a RCU lock
    
    commit 8c62ed27a12c00e3db1c9f04bc0f272bdbb06734 upstream.
    
    aa_xattrs_match() is unfortunately calling vfs_getxattr_alloc() from a
    context protected by an rcu_read_lock. This can not be done as
    vfs_getxattr_alloc() may sleep regardles of the gfp_t value being
    passed to it.
    
    Fix this by breaking the rcu_read_lock on the policy search when the
    xattr match feature is requested and restarting the search if a policy
    changes occur.
    
    Fixes: 8e51f9087f40 ("apparmor: Add support for attaching profiles via xattr, presence and value")
    Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20170bfa3d9a58f788d5b4255c138ded5cefd7a1
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Sat Jan 4 13:00:12 2020 -0800

    mm/gup: fix memory leak in __gup_benchmark_ioctl
    
    commit a7c46c0c0e3d62f2764cd08b90934cd2aaaf8545 upstream.
    
    In the implementation of __gup_benchmark_ioctl() the allocated pages
    should be released before returning in case of an invalid cmd.  Release
    pages via kvfree().
    
    [akpm@linux-foundation.org: rework code flow, return -EINVAL rather than -1]
    Link: http://lkml.kernel.org/r/20191211174653.4102-1-navid.emamdoost@gmail.com
    Fixes: 714a3a1ebafe ("mm/gup_benchmark.c: add additional pinning methods")
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Cc: Keith Busch <keith.busch@intel.com>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: David Hildenbrand <david@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1b69aabcd4ae7efefb38edf73eceefdf560b24a
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Dec 2 08:50:00 2019 -0700

    io_uring: use current task creds instead of allocating a new one
    
    commit 0b8c0ec7eedcd8f9f1a1f238d87f9b512b09e71a upstream.
    
    syzbot reports:
    
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 9217 Comm: io_uring-sq Not tainted 5.4.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    RIP: 0010:creds_are_invalid kernel/cred.c:792 [inline]
    RIP: 0010:__validate_creds include/linux/cred.h:187 [inline]
    RIP: 0010:override_creds+0x9f/0x170 kernel/cred.c:550
    Code: ac 25 00 81 fb 64 65 73 43 0f 85 a3 37 00 00 e8 17 ab 25 00 49 8d 7c
    24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
    c0 74 08 3c 03 0f 8e 96 00 00 00 41 8b 5c 24 10 bf
    RSP: 0018:ffff88809c45fda0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000043736564 RCX: ffffffff814f3318
    RDX: 0000000000000002 RSI: ffffffff814f3329 RDI: 0000000000000010
    RBP: ffff88809c45fdb8 R08: ffff8880a3aac240 R09: ffffed1014755849
    R10: ffffed1014755848 R11: ffff8880a3aac247 R12: 0000000000000000
    R13: ffff888098ab1600 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffd51c40664 CR3: 0000000092641000 CR4: 00000000001406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
      io_sq_thread+0x1c7/0xa20 fs/io_uring.c:3274
      kthread+0x361/0x430 kernel/kthread.c:255
      ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    Modules linked in:
    ---[ end trace f2e1a4307fbe2245 ]---
    RIP: 0010:creds_are_invalid kernel/cred.c:792 [inline]
    RIP: 0010:__validate_creds include/linux/cred.h:187 [inline]
    RIP: 0010:override_creds+0x9f/0x170 kernel/cred.c:550
    Code: ac 25 00 81 fb 64 65 73 43 0f 85 a3 37 00 00 e8 17 ab 25 00 49 8d 7c
    24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
    c0 74 08 3c 03 0f 8e 96 00 00 00 41 8b 5c 24 10 bf
    RSP: 0018:ffff88809c45fda0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000043736564 RCX: ffffffff814f3318
    RDX: 0000000000000002 RSI: ffffffff814f3329 RDI: 0000000000000010
    RBP: ffff88809c45fdb8 R08: ffff8880a3aac240 R09: ffffed1014755849
    R10: ffffed1014755848 R11: ffff8880a3aac247 R12: 0000000000000000
    R13: ffff888098ab1600 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffd51c40664 CR3: 0000000092641000 CR4: 00000000001406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    which is caused by slab fault injection triggering a failure in
    prepare_creds(). We don't actually need to create a copy of the creds
    as we're not modifying it, we just need a reference on the current task
    creds. This avoids the failure case as well, and propagates the const
    throughout the stack.
    
    Fixes: 181e448d8709 ("io_uring: async workers should inherit the user creds")
    Reported-by: syzbot+5320383e16029ba057ff@syzkaller.appspotmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [ only use the io_uring.c portion of the patch - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7aa117bfc27a15bb2656b34bc6322417065a828d
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Wed Dec 18 08:44:26 2019 +0100

    samples/trace_printk: Wait for IRQ work to finish
    
    commit 01f36a554e3ef32f9fc4b81a4437cf08fd0e4742 upstream.
    
    trace_printk schedules work via irq_work_queue(), but doesn't
    wait until it was processed. The kprobe_module.tc testcase does:
    
    :;: "Load module again, which means the event1 should be recorded";:
    modprobe trace-printk
    grep "event1:" trace
    
    so the grep which checks the trace file might run before the irq work
    was processed. Fix this by adding a irq_work_sync().
    
    Link: http://lore.kernel.org/linux-trace-devel/20191218074427.96184-3-svens@linux.ibm.com
    
    Cc: stable@vger.kernel.org
    Fixes: af2a0750f3749 ("selftests/ftrace: Improve kprobe on module testcase to load/unload module")
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09f80e915f1421d9e04c4b691f0f2f3358d1c1e9
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Wed Dec 18 08:44:27 2019 +0100

    tracing: Fix endianness bug in histogram trigger
    
    commit fe6e096a5bbf73a142f09c72e7aa2835026eb1a3 upstream.
    
    At least on PA-RISC and s390 synthetic histogram triggers are failing
    selftests because trace_event_raw_event_synth() always writes a 64 bit
    values, but the reader expects a field->size sized value. On little endian
    machines this doesn't hurt, but on big endian this makes the reader always
    read zero values.
    
    Link: http://lore.kernel.org/linux-trace-devel/20191218074427.96184-4-svens@linux.ibm.com
    
    Cc: stable@vger.kernel.org
    Fixes: 4b147936fa509 ("tracing: Add support for 'synthetic' events")
    Acked-by: Tom Zanussi <tom.zanussi@linux.intel.com>
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 038840ff78f4d9c9699cf2eb7f0798152b671a51
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Dec 11 15:44:22 2019 -0500

    tracing: Have the histogram compare functions convert to u64 first
    
    commit 106f41f5a302cb1f36c7543fae6a05de12e96fa4 upstream.
    
    The compare functions of the histogram code would be specific for the size
    of the value being compared (byte, short, int, long long). It would
    reference the value from the array via the type of the compare, but the
    value was stored in a 64 bit number. This is fine for little endian
    machines, but for big endian machines, it would end up comparing zeros or
    all ones (depending on the sign) for anything but 64 bit numbers.
    
    To fix this, first derference the value as a u64 then convert it to the type
    being compared.
    
    Link: http://lkml.kernel.org/r/20191211103557.7bed6928@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Fixes: 08d43a5fa063e ("tracing: Add lock-free tracing_map")
    Acked-by: Tom Zanussi <zanussi@kernel.org>
    Reported-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d50bc5758e28fda93e3fdc2c3fedb83700c5b724
Author: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
Date:   Wed Dec 11 09:12:58 2019 +0000

    tracing: Avoid memory leak in process_system_preds()
    
    commit 79e65c27f09683fbb50c33acab395d0ddf5302d2 upstream.
    
    When failing in the allocation of filter_item, process_system_preds()
    goes to fail_mem, where the allocated filter is freed.
    
    However, this leads to memory leak of filter->filter_string and
    filter->prog, which is allocated before and in process_preds().
    This bug has been detected by kmemleak as well.
    
    Fix this by changing kfree to __free_fiter.
    
    unreferenced object 0xffff8880658007c0 (size 32):
      comm "bash", pid 579, jiffies 4295096372 (age 17.752s)
      hex dump (first 32 bytes):
        63 6f 6d 6d 6f 6e 5f 70 69 64 20 20 3e 20 31 30  common_pid  > 10
        00 00 00 00 00 00 00 00 65 73 00 00 00 00 00 00  ........es......
      backtrace:
        [<0000000067441602>] kstrdup+0x2d/0x60
        [<00000000141cf7b7>] apply_subsystem_event_filter+0x378/0x932
        [<000000009ca32334>] subsystem_filter_write+0x5a/0x90
        [<0000000072da2bee>] vfs_write+0xe1/0x240
        [<000000004f14f473>] ksys_write+0xb4/0x150
        [<00000000a968b4a0>] do_syscall_64+0x6d/0x1e0
        [<000000001a189f40>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    unreferenced object 0xffff888060c22d00 (size 64):
      comm "bash", pid 579, jiffies 4295096372 (age 17.752s)
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 00 e8 d7 41 80 88 ff ff  ...........A....
        01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000b8c1b109>] process_preds+0x243/0x1820
        [<000000003972c7f0>] apply_subsystem_event_filter+0x3be/0x932
        [<000000009ca32334>] subsystem_filter_write+0x5a/0x90
        [<0000000072da2bee>] vfs_write+0xe1/0x240
        [<000000004f14f473>] ksys_write+0xb4/0x150
        [<00000000a968b4a0>] do_syscall_64+0x6d/0x1e0
        [<000000001a189f40>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    unreferenced object 0xffff888041d7e800 (size 512):
      comm "bash", pid 579, jiffies 4295096372 (age 17.752s)
      hex dump (first 32 bytes):
        70 bc 85 97 ff ff ff ff 0a 00 00 00 00 00 00 00  p...............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000001e04af34>] process_preds+0x71a/0x1820
        [<000000003972c7f0>] apply_subsystem_event_filter+0x3be/0x932
        [<000000009ca32334>] subsystem_filter_write+0x5a/0x90
        [<0000000072da2bee>] vfs_write+0xe1/0x240
        [<000000004f14f473>] ksys_write+0xb4/0x150
        [<00000000a968b4a0>] do_syscall_64+0x6d/0x1e0
        [<000000001a189f40>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Link: http://lkml.kernel.org/r/20191211091258.11310-1-keitasuzuki.park@sslab.ics.keio.ac.jp
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 404a3add43c9c ("tracing: Only add filter list when needed")
    Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5361afa0ebe53b35e7609c544ebf66bb27ec846
Author: Prateek Sood <prsood@codeaurora.org>
Date:   Tue Dec 10 09:15:16 2019 +0000

    tracing: Fix lock inversion in trace_event_enable_tgid_record()
    
    commit 3a53acf1d9bea11b57c1f6205e3fe73f9d8a3688 upstream.
    
           Task T2                             Task T3
    trace_options_core_write()            subsystem_open()
    
     mutex_lock(trace_types_lock)           mutex_lock(event_mutex)
    
     set_tracer_flag()
    
       trace_event_enable_tgid_record()       mutex_lock(trace_types_lock)
    
        mutex_lock(event_mutex)
    
    This gives a circular dependency deadlock between trace_types_lock and
    event_mutex. To fix this invert the usage of trace_types_lock and
    event_mutex in trace_options_core_write(). This keeps the sequence of
    lock usage consistent.
    
    Link: http://lkml.kernel.org/r/0101016eef175e38-8ca71caf-a4eb-480d-a1e6-6f0bbc015495-000000@us-west-2.amazonses.com
    
    Cc: stable@vger.kernel.org
    Fixes: d914ba37d7145 ("tracing: Add support for recording tgid of tasks")
    Signed-off-by: Prateek Sood <prsood@codeaurora.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0426c59b638c5fbd32dab1a54f3ccbeab1c2bcd3
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Wed Dec 11 11:17:13 2019 -0500

    rseq/selftests: Fix: Namespace gettid() for compatibility with glibc 2.30
    
    commit 8df34c56321479bfa1ec732c675b686c2b4df412 upstream.
    
    glibc 2.30 introduces gettid() in public headers, which clashes with
    the internal static definition within rseq selftests.
    
    Rename gettid() to rseq_gettid() to eliminate this symbol name clash.
    
    Reported-by: Tommi T. Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Tommi T. Rantala <tommi.t.rantala@nokia.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: "H . Peter Anvin" <hpa@zytor.com>
    Cc: Paul Turner <pjt@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: <stable@vger.kernel.org>    # v4.18+
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 927cc45771d9ecf10f179fb43049fc58f6f2f48c
Author: Zong Li <zong.li@sifive.com>
Date:   Mon Dec 23 16:46:13 2019 +0800

    riscv: ftrace: correct the condition logic in function graph tracer
    
    commit 1d8f65798240b6577d8c44d20c8ea8f1d429e495 upstream.
    
    The condition should be logical NOT to assign the hook address to parent
    address. Because the return value 0 of function_graph_enter upon
    success.
    
    Fixes: e949b6db51dc (riscv/function_graph: Simplify with function_graph_enter())
    Signed-off-by: Zong Li <zong.li@sifive.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3757ec3d9bf8697508dbd8fae2f5860806611f7
Author: Zong Li <zong.li@sifive.com>
Date:   Mon Dec 23 16:46:14 2019 +0800

    clocksource: riscv: add notrace to riscv_sched_clock
    
    commit 9d05c18e8d7de566ff68f221fcae65e78708dd1d upstream.
    
    When enabling ftrace graph tracer, it gets the tracing clock in
    ftrace_push_return_trace().  Eventually, it invokes riscv_sched_clock()
    to get the clock value.  If riscv_sched_clock() isn't marked with
    'notrace', it will call ftrace_push_return_trace() and cause infinite
    loop.
    
    The result of failure as follow:
    
    command: echo function_graph >current_tracer
    [   46.176787] Unable to handle kernel paging request at virtual address ffffffe04fb38c48
    [   46.177309] Oops [#1]
    [   46.177478] Modules linked in:
    [   46.177770] CPU: 0 PID: 256 Comm: $d Not tainted 5.5.0-rc1 #47
    [   46.177981] epc: ffffffe00035e59a ra : ffffffe00035e57e sp : ffffffe03a7569b0
    [   46.178216]  gp : ffffffe000d29b90 tp : ffffffe03a756180 t0 : ffffffe03a756968
    [   46.178430]  t1 : ffffffe00087f408 t2 : ffffffe03a7569a0 s0 : ffffffe03a7569f0
    [   46.178643]  s1 : ffffffe00087f408 a0 : 0000000ac054cda4 a1 : 000000000087f411
    [   46.178856]  a2 : 0000000ac054cda4 a3 : 0000000000373ca0 a4 : ffffffe04fb38c48
    [   46.179099]  a5 : 00000000153e22a8 a6 : 00000000005522ff a7 : 0000000000000005
    [   46.179338]  s2 : ffffffe03a756a90 s3 : ffffffe00032811c s4 : ffffffe03a756a58
    [   46.179570]  s5 : ffffffe000d29fe0 s6 : 0000000000000001 s7 : 0000000000000003
    [   46.179809]  s8 : 0000000000000003 s9 : 0000000000000002 s10: 0000000000000004
    [   46.180053]  s11: 0000000000000000 t3 : 0000003fc815749c t4 : 00000000000efc90
    [   46.180293]  t5 : ffffffe000d29658 t6 : 0000000000040000
    [   46.180482] status: 0000000000000100 badaddr: ffffffe04fb38c48 cause: 000000000000000f
    
    Signed-off-by: Zong Li <zong.li@sifive.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    [paul.walmsley@sifive.com: cleaned up patch description]
    Fixes: 92e0d143fdef ("clocksource/drivers/riscv_timer: Provide the sched_clock")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 530f7c6df94e2190ae4499633910f36487da4d6c
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Sat Dec 7 16:20:18 2019 +0000

    gpiolib: fix up emulated open drain outputs
    
    commit 256efaea1fdc4e38970489197409a26125ee0aaa upstream.
    
    gpiolib has a corner case with open drain outputs that are emulated.
    When such outputs are outputting a logic 1, emulation will set the
    hardware to input mode, which will cause gpiod_get_direction() to
    report that it is in input mode. This is different from the behaviour
    with a true open-drain output.
    
    Unify the semantics here.
    
    Cc: <stable@vger.kernel.org>
    Suggested-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5654d5d25c17782e0a12554483bd345cd25b7bf6
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Tue Nov 26 11:30:27 2019 -0800

    gpio: xtensa: fix driver build
    
    commit 634f0348fe336fce8f6cab1933139115e983ed2f upstream.
    
    Commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") removed
    {RSR,WSR}_CPENABLE from xtensa code, but did not fix up all users,
    breaking gpio-xtensa driver build. Update gpio-xtensa to use
    new xtensa_{get,set}_sr API.
    
    Cc: stable@vger.kernel.org # v5.0+
    Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9738c3a4e1378f26d92d1c061f08ff0c12116b5
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Fri Dec 13 09:04:08 2019 +0100

    libata: Fix retrieving of active qcs
    
    commit 8385d756e114f2df8568e508902d5f9850817ffb upstream.
    
    ata_qc_complete_multiple() is called with a mask of the still active
    tags.
    
    mv_sata doesn't have this information directly and instead calculates
    the still active tags from the started tags (ap->qc_active) and the
    finished tags as (ap->qc_active ^ done_mask)
    
    Since 28361c40368 the hw_tag and tag are no longer the same and the
    equation is no longer valid. In ata_exec_internal_sg() ap->qc_active is
    initialized as 1ULL << ATA_TAG_INTERNAL, but in hardware tag 0 is
    started and this will be in done_mask on completion. ap->qc_active ^
    done_mask becomes 0x100000000 ^ 0x1 = 0x100000001 and thus tag 0 used as
    the internal tag will never be reported as completed.
    
    This is fixed by introducing ata_qc_get_active() which returns the
    active hardware tags and calling it where appropriate.
    
    This is tested on mv_sata, but sata_fsl and sata_nv suffer from the same
    problem. There is another case in sata_nv that most likely needs fixing
    as well, but this looks a little different, so I wasn't confident enough
    to change that.
    
    Fixes: 28361c403683 ("libata: add extra internal command")
    Cc: stable@vger.kernel.org
    Tested-by: Pali Rohár <pali.rohar@gmail.com>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Add missing export of ata_qc_get_active(), as per Pali.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit fc6e6f322eaf7f4744b758898a7b6ef65d3f67fa
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Dec 10 10:53:46 2019 -0800

    ata: ahci_brcm: BCM7425 AHCI requires AHCI_HFLAG_DELAY_ENGINE
    
    commit 1a3d78cb6e20779a19388315bd8efefbd8d4a656 upstream.
    
    Set AHCI_HFLAG_DELAY_ENGINE for the BCM7425 AHCI controller thus making
    it conforming to the 'strict' AHCI implementation which this controller
    is based on.
    
    This solves long link establishment with specific hard drives (e.g.:
    Seagate ST1000VM002-9ZL1 SC12) that would otherwise have to complete the
    error recovery handling before finally establishing a succesful SATA
    link at the desired speed.
    
    We re-order the hpriv->flags assignment to also remove the NONCQ quirk
    since we can set the flag directly.
    
    Fixes: 9586114cf1e9 ("ata: ahci_brcmstb: add support MIPS-based platforms")
    Fixes: 423be77daabe ("ata: ahci_brcmstb: add quirk for broken ncq")
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3b6848e8de6c0251ba4a172812b2fa2fab9fda1
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Dec 10 10:53:47 2019 -0800

    ata: ahci_brcm: Add missing clock management during recovery
    
    commit bf0e5013bc2dcac205417e1252205dca39dfc005 upstream.
    
    The downstream implementation of ahci_brcm.c did contain clock
    management recovery, but until recently, did that outside of the
    libahci_platform helpers and this was unintentionally stripped out while
    forward porting the patch upstream.
    
    Add the missing clock management during recovery and sleep for 10
    milliseconds per the design team recommendations to ensure the SATA PHY
    controller and AFE have been fully quiesced.
    
    Fixes: eb73390ae241 ("ata: ahci_brcm: Recover from failures to identify devices")
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9295852f8721ca714e4745f24dad0e617f19da0
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Dec 10 10:53:45 2019 -0800

    ata: ahci_brcm: Fix AHCI resources management
    
    commit c0cdf2ac4b5bf3e5ef2451ea29fb4104278cdabc upstream.
    
    The AHCI resources management within ahci_brcm.c is a little
    convoluted, largely because it historically had a dedicated clock that
    was managed within this file in the downstream tree. Once brough
    upstream though, the clock was left to be managed by libahci_platform.c
    which is entirely appropriate.
    
    This patch series ensures that the AHCI resources are fetched and
    enabled before any register access is done, thus avoiding bus errors on
    platforms which clock gate the controller by default.
    
    As a result we need to re-arrange the suspend() and resume() functions
    in order to avoid accessing registers after the clocks have been turned
    off respectively before the clocks have been turned on. Finally, we can
    refactor brcm_ahci_get_portmask() in order to fetch the number of ports
    from hpriv->mmio which is now accessible without jumping through hoops
    like we used to do.
    
    The commit pointed in the Fixes tag is both old and new enough not to
    require major headaches for backporting of this patch.
    
    Fixes: eba68f829794 ("ata: ahci_brcmstb: rename to support across Broadcom SoC's")
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ce0f1e6fa8824b1c09ef5f64d0be569e91e7dc8
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Dec 10 10:53:44 2019 -0800

    ata: libahci_platform: Export again ahci_platform_<en/dis>able_phys()
    
    commit 84b032dbfdf1c139cd2b864e43959510646975f8 upstream.
    
    This reverts commit 6bb86fefa086faba7b60bb452300b76a47cde1a5
    ("libahci_platform: Staticize ahci_platform_<en/dis>able_phys()") we are
    going to need ahci_platform_{enable,disable}_phys() in a subsequent
    commit for ahci_brcm.c in order to properly control the PHY
    initialization order.
    
    Also make sure the function prototypes are declared in
    include/linux/ahci_platform.h as a result.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abaf57360e3b1868615eacb71af466baf8156ffb
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Sun Dec 22 23:37:40 2019 +0100

    bpf: Fix precision tracking for unbounded scalars
    
    commit f54c7898ed1c3c9331376c0337a5049c38f66497 upstream.
    
    Anatoly has been fuzzing with kBdysch harness and reported a hang in one
    of the outcomes. Upon closer analysis, it turns out that precise scalar
    value tracking is missing a few precision markings for unknown scalars:
    
      0: R1=ctx(id=0,off=0,imm=0) R10=fp0
      0: (b7) r0 = 0
      1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
      1: (35) if r0 >= 0xf72e goto pc+0
      --> only follow fallthrough
      2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
      2: (35) if r0 >= 0x80fe0000 goto pc+0
      --> only follow fallthrough
      3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
      3: (14) w0 -= -536870912
      4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0
      4: (0f) r1 += r0
      5: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0
      5: (55) if r1 != 0x104c1500 goto pc+0
      --> push other branch for later analysis
      R0_w=invP536870912 R1_w=inv273421568 R10=fp0
      6: R0_w=invP536870912 R1_w=inv273421568 R10=fp0
      6: (b7) r0 = 0
      7: R0=invP0 R1=inv273421568 R10=fp0
      7: (76) if w1 s>= 0xffffff00 goto pc+3
      --> only follow goto
      11: R0=invP0 R1=inv273421568 R10=fp0
      11: (95) exit
      6: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0
      6: (b7) r0 = 0
      propagating r0
      7: safe
      processed 11 insns [...]
    
    In the analysis of the second path coming after the successful exit above,
    the path is being pruned at line 7. Pruning analysis found that both r0 are
    precise P0 and both R1 are non-precise scalars and given prior path with
    R1 as non-precise scalar succeeded, this one is therefore safe as well.
    
    However, problem is that given condition at insn 7 in the first run, we only
    followed goto and didn't push the other branch for later analysis, we've
    never walked the few insns in there and therefore dead-code sanitation
    rewrites it as goto pc-1, causing the hang depending on the skb address
    hitting these conditions. The issue is that R1 should have been marked as
    precise as well such that pruning enforces range check and conluded that new
    R1 is not in range of old R1. In insn 4, we mark R1 (skb) as unknown scalar
    via __mark_reg_unbounded() but not mark_reg_unbounded() and therefore
    regs->precise remains as false.
    
    Back in b5dc0163d8fd ("bpf: precise scalar_value tracking"), this was not
    the case since marking out of __mark_reg_unbounded() had this covered as well.
    Once in both are set as precise in 4 as they should have been, we conclude
    that given R1 was in prior fall-through path 0x104c1500 and now is completely
    unknown, the check at insn 7 concludes that we need to continue walking.
    Analysis after the fix:
    
      0: R1=ctx(id=0,off=0,imm=0) R10=fp0
      0: (b7) r0 = 0
      1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
      1: (35) if r0 >= 0xf72e goto pc+0
      2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
      2: (35) if r0 >= 0x80fe0000 goto pc+0
      3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
      3: (14) w0 -= -536870912
      4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0
      4: (0f) r1 += r0
      5: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0
      5: (55) if r1 != 0x104c1500 goto pc+0
      R0_w=invP536870912 R1_w=invP273421568 R10=fp0
      6: R0_w=invP536870912 R1_w=invP273421568 R10=fp0
      6: (b7) r0 = 0
      7: R0=invP0 R1=invP273421568 R10=fp0
      7: (76) if w1 s>= 0xffffff00 goto pc+3
      11: R0=invP0 R1=invP273421568 R10=fp0
      11: (95) exit
      6: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0
      6: (b7) r0 = 0
      7: R0_w=invP0 R1_w=invP(id=0) R10=fp0
      7: (76) if w1 s>= 0xffffff00 goto pc+3
      R0_w=invP0 R1_w=invP(id=0) R10=fp0
      8: R0_w=invP0 R1_w=invP(id=0) R10=fp0
      8: (a5) if r0 < 0x2007002a goto pc+0
      9: R0_w=invP0 R1_w=invP(id=0) R10=fp0
      9: (57) r0 &= -16316416
      10: R0_w=invP0 R1_w=invP(id=0) R10=fp0
      10: (a6) if w0 < 0x1201 goto pc+0
      11: R0_w=invP0 R1_w=invP(id=0) R10=fp0
      11: (95) exit
      11: R0=invP0 R1=invP(id=0) R10=fp0
      11: (95) exit
      processed 16 insns [...]
    
    Fixes: 6754172c208d ("bpf: fix precision tracking in presence of bpf2bpf calls")
    Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20191222223740.25297-1-daniel@iogearbox.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 247aca0b6baef106ed99fbc43bd0a367c865ccce
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 29 11:28:22 2019 +0100

    compat_ioctl: block: handle BLKGETZONESZ/BLKGETNRZONES
    
    commit 21d37340912d74b1222d43c11aa9dd0687162573 upstream.
    
    These were added to blkdev_ioctl() in v4.20 but not blkdev_compat_ioctl,
    so add them now.
    
    Cc: <stable@vger.kernel.org> # v4.20+
    Fixes: 72cd87576d1d ("block: Introduce BLKGETZONESZ ioctl")
    Fixes: 65e4e3eee83d ("block: Introduce BLKGETNRZONES ioctl")
    Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17d3c07aaba71b23c10a6e1dce2320ac5fdfae3b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 29 11:28:22 2019 +0100

    compat_ioctl: block: handle BLKREPORTZONE/BLKRESETZONE
    
    commit 673bdf8ce0a387ef585c13b69a2676096c6edfe9 upstream.
    
    These were added to blkdev_ioctl() but not blkdev_compat_ioctl,
    so add them now.
    
    Cc: <stable@vger.kernel.org> # v4.10+
    Fixes: 3ed05a987e0f ("blk-zoned: implement ioctls")
    Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 755d02fcf855cb38df1f97dab60c0ecf15671975
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 29 11:28:22 2019 +0100

    compat_ioctl: block: handle Persistent Reservations
    
    commit b2c0fcd28772f99236d261509bcd242135677965 upstream.
    
    These were added to blkdev_ioctl() in linux-5.5 but not
    blkdev_compat_ioctl, so add them now.
    
    Cc: <stable@vger.kernel.org> # v4.4+
    Fixes: bbd3e064362e ("block: add an API for Persistent Reservations")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Fold in followup patch from Arnd with missing pr.h header include.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit 842c4cd688268859f077f552fd60f0521abf52dc
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Dec 11 09:01:40 2019 +0000

    Btrfs: fix infinite loop during nocow writeback due to race
    
    commit de7999afedff02c6631feab3ea726a0e8f8c3d40 upstream.
    
    When starting writeback for a range that covers part of a preallocated
    extent, due to a race with writeback for another range that also covers
    another part of the same preallocated extent, we can end up in an infinite
    loop.
    
    Consider the following example where for inode 280 we have two dirty
    ranges:
    
      range A, from 294912 to 303103, 8192 bytes
      range B, from 348160 to 438271, 90112 bytes
    
    and we have the following file extent item layout for our inode:
    
      leaf 38895616 gen 24544 total ptrs 29 free space 13820 owner 5
          (...)
          item 27 key (280 108 200704) itemoff 14598 itemsize 53
              extent data disk bytenr 0 nr 0 type 1 (regular)
              extent data offset 0 nr 94208 ram 94208
          item 28 key (280 108 294912) itemoff 14545 itemsize 53
              extent data disk bytenr 10433052672 nr 81920 type 2 (prealloc)
              extent data offset 0 nr 81920 ram 81920
    
    Then the following happens:
    
    1) Writeback starts for range B (from 348160 to 438271), execution of
       run_delalloc_nocow() starts;
    
    2) The first iteration of run_delalloc_nocow()'s whil loop leaves us at
       the extent item at slot 28, pointing to the prealloc extent item
       covering the range from 294912 to 376831. This extent covers part of
       our range;
    
    3) An ordered extent is created against that extent, covering the file
       range from 348160 to 376831 (28672 bytes);
    
    4) We adjust 'cur_offset' to 376832 and move on to the next iteration of
       the while loop;
    
    5) The call to btrfs_lookup_file_extent() leaves us at the same leaf,
       pointing to slot 29, 1 slot after the last item (the extent item
       we processed in the previous iteration);
    
    6) Because we are a slot beyond the last item, we call btrfs_next_leaf(),
       which releases the search path before doing a another search for the
       last key of the leaf (280 108 294912);
    
    7) Right after btrfs_next_leaf() released the path, and before it did
       another search for the last key of the leaf, writeback for the range
       A (from 294912 to 303103) completes (it was previously started at
       some point);
    
    8) Upon completion of the ordered extent for range A, the prealloc extent
       we previously found got split into two extent items, one covering the
       range from 294912 to 303103 (8192 bytes), with a type of regular extent
       (and no longer prealloc) and another covering the range from 303104 to
       376831 (73728 bytes), with a type of prealloc and an offset of 8192
       bytes. So our leaf now has the following layout:
    
         leaf 38895616 gen 24544 total ptrs 31 free space 13664 owner 5
             (...)
             item 27 key (280 108 200704) itemoff 14598 itemsize 53
                 extent data disk bytenr 0 nr 0 type 1
                 extent data offset 0 nr 8192 ram 94208
             item 28 key (280 108 208896) itemoff 14545 itemsize 53
                 extent data disk bytenr 10433142784 nr 86016 type 1
                 extent data offset 0 nr 86016 ram 86016
             item 29 key (280 108 294912) itemoff 14492 itemsize 53
                 extent data disk bytenr 10433052672 nr 81920 type 1
                 extent data offset 0 nr 8192 ram 81920
             item 30 key (280 108 303104) itemoff 14439 itemsize 53
                 extent data disk bytenr 10433052672 nr 81920 type 2
                 extent data offset 8192 nr 73728 ram 81920
    
    9) After btrfs_next_leaf() returns, we have our path pointing to that same
       leaf and at slot 30, since it has a key we didn't have before and it's
       the first key greater then the key that was previously the last key of
       the leaf (key (280 108 294912));
    
    10) The extent item at slot 30 covers the range from 303104 to 376831
        which is in our target range, so we process it, despite having already
        created an ordered extent against this extent for the file range from
        348160 to 376831. This is because we skip to the next extent item only
        if its end is less than or equals to the start of our delalloc range,
        and not less than or equals to the current offset ('cur_offset');
    
    11) As a result we compute 'num_bytes' as:
    
        num_bytes = min(end + 1, extent_end) - cur_offset;
                  = min(438271 + 1, 376832) - 376832 = 0
    
    12) We then call create_io_em() for a 0 bytes range starting at offset
        376832;
    
    13) Then create_io_em() enters an infinite loop because its calls to
        btrfs_drop_extent_cache() do nothing due to the 0 length range
        passed to it. So no existing extent maps that cover the offset
        376832 get removed, and therefore calls to add_extent_mapping()
        return -EEXIST, resulting in an infinite loop. This loop from
        create_io_em() is the following:
    
        do {
            btrfs_drop_extent_cache(BTRFS_I(inode), em->start,
                                    em->start + em->len - 1, 0);
            write_lock(&em_tree->lock);
            ret = add_extent_mapping(em_tree, em, 1);
            write_unlock(&em_tree->lock);
            /*
             * The caller has taken lock_extent(), who could race with us
             * to add em?
             */
        } while (ret == -EEXIST);
    
    Also, each call to btrfs_drop_extent_cache() triggers a warning because
    the start offset passed to it (376832) is smaller then the end offset
    (376832 - 1) passed to it by -1, due to the 0 length:
    
      [258532.052621] ------------[ cut here ]------------
      [258532.052643] WARNING: CPU: 0 PID: 9987 at fs/btrfs/file.c:602 btrfs_drop_extent_cache+0x3f4/0x590 [btrfs]
      (...)
      [258532.052672] CPU: 0 PID: 9987 Comm: fsx Tainted: G        W         5.4.0-rc7-btrfs-next-64 #1
      [258532.052673] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
      [258532.052691] RIP: 0010:btrfs_drop_extent_cache+0x3f4/0x590 [btrfs]
      (...)
      [258532.052695] RSP: 0018:ffffb4be0153f860 EFLAGS: 00010287
      [258532.052700] RAX: ffff975b445ee360 RBX: ffff975b44eb3e08 RCX: 0000000000000000
      [258532.052700] RDX: 0000000000038fff RSI: 0000000000039000 RDI: ffff975b445ee308
      [258532.052700] RBP: 0000000000038fff R08: 0000000000000000 R09: 0000000000000001
      [258532.052701] R10: ffff975b513c5c10 R11: 00000000e3c0cfa9 R12: 0000000000039000
      [258532.052703] R13: ffff975b445ee360 R14: 00000000ffffffef R15: ffff975b445ee308
      [258532.052705] FS:  00007f86a821de80(0000) GS:ffff975b76a00000(0000) knlGS:0000000000000000
      [258532.052707] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [258532.052708] CR2: 00007fdacf0f3ab4 CR3: 00000001f9d26002 CR4: 00000000003606f0
      [258532.052712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [258532.052717] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [258532.052717] Call Trace:
      [258532.052718]  ? preempt_schedule_common+0x32/0x70
      [258532.052722]  ? ___preempt_schedule+0x16/0x20
      [258532.052741]  create_io_em+0xff/0x180 [btrfs]
      [258532.052767]  run_delalloc_nocow+0x942/0xb10 [btrfs]
      [258532.052791]  btrfs_run_delalloc_range+0x30b/0x520 [btrfs]
      [258532.052812]  ? find_lock_delalloc_range+0x221/0x250 [btrfs]
      [258532.052834]  writepage_delalloc+0xe4/0x140 [btrfs]
      [258532.052855]  __extent_writepage+0x110/0x4e0 [btrfs]
      [258532.052876]  extent_write_cache_pages+0x21c/0x480 [btrfs]
      [258532.052906]  extent_writepages+0x52/0xb0 [btrfs]
      [258532.052911]  do_writepages+0x23/0x80
      [258532.052915]  __filemap_fdatawrite_range+0xd2/0x110
      [258532.052938]  btrfs_fdatawrite_range+0x1b/0x50 [btrfs]
      [258532.052954]  start_ordered_ops+0x57/0xa0 [btrfs]
      [258532.052973]  ? btrfs_sync_file+0x225/0x490 [btrfs]
      [258532.052988]  btrfs_sync_file+0x225/0x490 [btrfs]
      [258532.052997]  __x64_sys_msync+0x199/0x200
      [258532.053004]  do_syscall_64+0x5c/0x250
      [258532.053007]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [258532.053010] RIP: 0033:0x7f86a7dfd760
      (...)
      [258532.053014] RSP: 002b:00007ffd99af0368 EFLAGS: 00000246 ORIG_RAX: 000000000000001a
      [258532.053016] RAX: ffffffffffffffda RBX: 0000000000000ec9 RCX: 00007f86a7dfd760
      [258532.053017] RDX: 0000000000000004 RSI: 000000000000836c RDI: 00007f86a8221000
      [258532.053019] RBP: 0000000000021ec9 R08: 0000000000000003 R09: 00007f86a812037c
      [258532.053020] R10: 0000000000000001 R11: 0000000000000246 R12: 00000000000074a3
      [258532.053021] R13: 00007f86a8221000 R14: 000000000000836c R15: 0000000000000001
      [258532.053032] irq event stamp: 1653450494
      [258532.053035] hardirqs last  enabled at (1653450493): [<ffffffff9dec69f9>] _raw_spin_unlock_irq+0x29/0x50
      [258532.053037] hardirqs last disabled at (1653450494): [<ffffffff9d4048ea>] trace_hardirqs_off_thunk+0x1a/0x20
      [258532.053039] softirqs last  enabled at (1653449852): [<ffffffff9e200466>] __do_softirq+0x466/0x6bd
      [258532.053042] softirqs last disabled at (1653449845): [<ffffffff9d4c8a0c>] irq_exit+0xec/0x120
      [258532.053043] ---[ end trace 8476fce13d9ce20a ]---
    
    Which results in flooding dmesg/syslog since btrfs_drop_extent_cache()
    uses WARN_ON() and not WARN_ON_ONCE().
    
    So fix this issue by changing run_delalloc_nocow()'s loop to move to the
    next extent item when the current extent item ends at at offset less than
    or equals to the current offset instead of the start offset.
    
    Fixes: 80ff385665b7fc ("Btrfs: update nodatacow code v2")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61dc7d025d8061b1c92ab8aede836ee6942e9ad8
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Tue Dec 10 17:55:45 2019 +0100

    dmaengine: dma-jz4780: Also break descriptor chains on JZ4725B
    
    commit a40c94be2336f3002563c9ae16572143ae3422e2 upstream.
    
    It turns out that the JZ4725B displays the same buggy behaviour as the
    JZ4740 that was described in commit f4c255f1a747 ("dmaengine: dma-jz4780:
    Break descriptor chains on JZ4740").
    
    Work around it by using the same workaround previously used for the
    JZ4740.
    
    Fixes commit f4c255f1a747 ("dmaengine: dma-jz4780: Break descriptor
    chains on JZ4740")
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Link: https://lore.kernel.org/r/20191210165545.59690-1-paul@crapouillou.net
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a71b9dd7bf4b9184f6b72a937c6f9f6f19709306
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Dec 5 12:54:49 2019 +0100

    dmaengine: Fix access to uninitialized dma_slave_caps
    
    commit 53a256a9b925b47c7e67fc1f16ca41561a7b877c upstream.
    
    dmaengine_desc_set_reuse() allocates a struct dma_slave_caps on the
    stack, populates it using dma_get_slave_caps() and then accesses one
    of its members.
    
    However dma_get_slave_caps() may fail and this isn't accounted for,
    leading to a legitimate warning of gcc-4.9 (but not newer versions):
    
       In file included from drivers/spi/spi-bcm2835.c:19:0:
       drivers/spi/spi-bcm2835.c: In function 'dmaengine_desc_set_reuse':
    >> include/linux/dmaengine.h:1370:10: warning: 'caps.descriptor_reuse' is used uninitialized in this function [-Wuninitialized]
         if (caps.descriptor_reuse) {
    
    Fix it, thereby also silencing the gcc-4.9 warning.
    
    The issue has been present for 4 years but surfaces only now that
    the first caller of dmaengine_desc_set_reuse() has been added in
    spi-bcm2835.c. Another user of reusable DMA descriptors has existed
    for a while in pxa_camera.c, but it sets the DMA_CTRL_REUSE flag
    directly instead of calling dmaengine_desc_set_reuse(). Nevertheless,
    tag this commit for stable in case there are out-of-tree users.
    
    Fixes: 272420214d26 ("dmaengine: Add DMA_CTRL_REUSE")
    Reported-by: kbuild test robot <lkp@intel.com>
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v4.3+
    Link: https://lore.kernel.org/r/ca92998ccc054b4f2bfd60ef3adbab2913171eac.1575546234.git.lukas@wunner.de
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a61eb076ccaa22681ff225b4390b27f7a05e0b36
Author: Sargun Dhillon <sargun@sargun.me>
Date:   Mon Dec 30 12:38:11 2019 -0800

    selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECV
    
    commit e4ab5ccc357b978999328fadae164e098c26fa40 upstream.
    
    This adds logic to the user_notification_basic test to set a member
    of struct seccomp_notif to an invalid value to ensure that the kernel
    returns EINVAL if any of the struct seccomp_notif members are set to
    invalid values.
    
    Signed-off-by: Sargun Dhillon <sargun@sargun.me>
    Suggested-by: Christian Brauner <christian.brauner@ubuntu.com>
    Link: https://lore.kernel.org/r/20191230203811.4996-1-sargun@sargun.me
    Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de7cd9dfc578e8b1f6586ffbc0e24683c356d143
Author: Sargun Dhillon <sargun@sargun.me>
Date:   Mon Dec 30 12:35:03 2019 -0800

    samples/seccomp: Zero out members based on seccomp_notif_sizes
    
    commit 771b894f2f3dfedc2ba5561731fffa0e39b1bbb6 upstream.
    
    The sizes by which seccomp_notif and seccomp_notif_resp are allocated are
    based on the SECCOMP_GET_NOTIF_SIZES ioctl. This allows for graceful
    extension of these datastructures. If userspace zeroes out the
    datastructure based on its version, and it is lagging behind the kernel's
    version, it will end up sending trailing garbage. On the other hand,
    if it is ahead of the kernel version, it will write extra zero space,
    and potentially cause corruption.
    
    Signed-off-by: Sargun Dhillon <sargun@sargun.me>
    Suggested-by: Tycho Andersen <tycho@tycho.ws>
    Link: https://lore.kernel.org/r/20191230203503.4925-1-sargun@sargun.me
    Fixes: fec7b6690541 ("samples: add an example of seccomp user trap")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f75e60d239087a582ca3d828fb475422d8046b79
Author: Sargun Dhillon <sargun@sargun.me>
Date:   Sat Dec 28 22:24:50 2019 -0800

    seccomp: Check that seccomp_notif is zeroed out by the user
    
    commit 2882d53c9c6f3b8311d225062522f03772cf0179 upstream.
    
    This patch is a small change in enforcement of the uapi for
    SECCOMP_IOCTL_NOTIF_RECV ioctl. Specifically, the datastructure which
    is passed (seccomp_notif) must be zeroed out. Previously any of its
    members could be set to nonsense values, and we would ignore it.
    
    This ensures all fields are set to their zero value.
    
    Signed-off-by: Sargun Dhillon <sargun@sargun.me>
    Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
    Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
    Acked-by: Tycho Andersen <tycho@tycho.ws>
    Link: https://lore.kernel.org/r/20191229062451.9467-2-sargun@sargun.me
    Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0c77c3fa8aeb4811155c485e5be24805d6842c3
Author: Sargun Dhillon <sargun@sargun.me>
Date:   Sat Dec 28 22:24:49 2019 -0800

    selftests/seccomp: Zero out seccomp_notif
    
    commit 88c13f8bd71472fbab5338b01d99122908c77e53 upstream.
    
    The seccomp_notif structure should be zeroed out prior to calling the
    SECCOMP_IOCTL_NOTIF_RECV ioctl. Previously, the kernel did not check
    whether these structures were zeroed out or not, so these worked.
    
    This patch zeroes out the seccomp_notif data structure prior to calling
    the ioctl.
    
    Signed-off-by: Sargun Dhillon <sargun@sargun.me>
    Reviewed-by: Tycho Andersen <tycho@tycho.ws>
    Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
    Link: https://lore.kernel.org/r/20191229062451.9467-1-sargun@sargun.me
    Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72893303a6d2fb8d65c00f463bc443c3eab72808
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sun Dec 22 20:45:28 2019 +0200

    locks: print unsigned ino in /proc/locks
    
    commit 98ca480a8f22fdbd768e3dad07024c8d4856576c upstream.
    
    An ino is unsigned, so display it as such in /proc/locks.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3346358055dfc6e45b1c5c8ff29f39c0e9b9fde2
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Dec 11 14:39:28 2019 +0100

    gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS again
    
    commit a5b0dc5a46c221725c43bd9b01570239a4cd78b1 upstream.
    
    I noticed that randconfig builds with gcc no longer produce a lot of
    ccache hits, unlike with clang, and traced this back to plugins
    now being enabled unconditionally if they are supported.
    
    I am now working around this by adding
    
       export CCACHE_COMPILERCHECK=/usr/bin/size -A %compiler%
    
    to my top-level Makefile. This changes the heuristic that ccache uses
    to determine whether the plugins are the same after a 'make clean'.
    
    However, it also seems that being able to just turn off the plugins is
    generally useful, at least for build testing it adds noticeable overhead
    but does not find a lot of bugs additional bugs, and may be easier for
    ccache users than my workaround.
    
    Fixes: 9f671e58159a ("security: Create "kernel hardening" config area")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
    Link: https://lore.kernel.org/r/20191211133951.401933-1-arnd@arndb.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50d18b655bb0b7dce04d0594e9bf9390ff1a4bdf
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Dec 30 11:48:10 2019 -0800

    pstore/ram: Fix error-path memory leak in persistent_ram_new() callers
    
    commit 8df955a32a73315055e0cd187cbb1cea5820394b upstream.
    
    For callers that allocated a label for persistent_ram_new(), if the call
    fails, they must clean up the allocation.
    
    Suggested-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Fixes: 1227daa43bce ("pstore/ram: Clarify resource reservation labels")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/lkml/20191211191353.14385-1-navid.emamdoost@gmail.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b578c35ed97434ab8f17efce69b2722ebf94abc8
Author: Aleksandr Yashkin <a.yashkin@inango-systems.com>
Date:   Mon Dec 23 18:38:16 2019 +0500

    pstore/ram: Write new dumps to start of recycled zones
    
    commit 9e5f1c19800b808a37fb9815a26d382132c26c3d upstream.
    
    The ram_core.c routines treat przs as circular buffers. When writing a
    new crash dump, the old buffer needs to be cleared so that the new dump
    doesn't end up in the wrong place (i.e. at the end).
    
    The solution to this problem is to reset the circular buffer state before
    writing a new Oops dump.
    
    Signed-off-by: Aleksandr Yashkin <a.yashkin@inango-systems.com>
    Signed-off-by: Nikolay Merinov <n.merinov@inango-systems.com>
    Signed-off-by: Ariel Gilman <a.gilman@inango-systems.com>
    Link: https://lore.kernel.org/r/20191223133816.28155-1-n.merinov@inango-systems.com
    Fixes: 896fc1f0c4c6 ("pstore/ram: Switch to persistent_ram routines")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3f82a7c17de0918df0775ffac3be2f6c9b33dfe
Author: Gang He <GHe@suse.com>
Date:   Sat Jan 4 13:00:22 2020 -0800

    ocfs2: fix the crash due to call ocfs2_get_dlm_debug once less
    
    commit b73eba2a867e10b9b4477738677341f3307c07bb upstream.
    
    Because ocfs2_get_dlm_debug() function is called once less here, ocfs2
    file system will trigger the system crash, usually after ocfs2 file
    system is unmounted.
    
    This system crash is caused by a generic memory corruption, these crash
    backtraces are not always the same, for exapmle,
    
        ocfs2: Unmounting device (253,16) on (node 172167785)
        general protection fault: 0000 [#1] SMP PTI
        CPU: 3 PID: 14107 Comm: fence_legacy Kdump:
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
        RIP: 0010:__kmalloc+0xa5/0x2a0
        Code: 00 00 4d 8b 07 65 4d 8b
        RSP: 0018:ffffaa1fc094bbe8 EFLAGS: 00010286
        RAX: 0000000000000000 RBX: d310a8800d7a3faf RCX: 0000000000000000
        RDX: 0000000000000000 RSI: 0000000000000dc0 RDI: ffff96e68fc036c0
        RBP: d310a8800d7a3faf R08: ffff96e6ffdb10a0 R09: 00000000752e7079
        R10: 000000000001c513 R11: 0000000004091041 R12: 0000000000000dc0
        R13: 0000000000000039 R14: ffff96e68fc036c0 R15: ffff96e68fc036c0
        FS:  00007f699dfba540(0000) GS:ffff96e6ffd80000(0000) knlGS:00000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 000055f3a9d9b768 CR3: 000000002cd1c000 CR4: 00000000000006e0
        Call Trace:
         ext4_htree_store_dirent+0x35/0x100 [ext4]
         htree_dirblock_to_tree+0xea/0x290 [ext4]
         ext4_htree_fill_tree+0x1c1/0x2d0 [ext4]
         ext4_readdir+0x67c/0x9d0 [ext4]
         iterate_dir+0x8d/0x1a0
         __x64_sys_getdents+0xab/0x130
         do_syscall_64+0x60/0x1f0
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7f699d33a9fb
    
    This regression problem was introduced by commit e581595ea29c ("ocfs: no
    need to check return value of debugfs_create functions").
    
    Link: http://lkml.kernel.org/r/20191225061501.13587-1-ghe@suse.com
    Fixes: e581595ea29c ("ocfs: no need to check return value of debugfs_create functions")
    Signed-off-by: Gang He <ghe@suse.com>
    Acked-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>    [5.3+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7123ee7b3feeaf414bfe84fa388e4168d62e07fe
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Sat Jan 4 13:00:09 2020 -0800

    mm/oom: fix pgtables units mismatch in Killed process message
    
    commit 941f762bcb276259a78e7931674668874ccbda59 upstream.
    
    pr_err() expects kB, but mm_pgtables_bytes() returns the number of bytes.
    As everything else is printed in kB, I chose to fix the value rather than
    the string.
    
    Before:
    
    [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
    ...
    [   1878]  1000  1878   217253   151144  1269760        0             0 python
    ...
    Out of memory: Killed process 1878 (python) total-vm:869012kB, anon-rss:604572kB, file-rss:4kB, shmem-rss:0kB, UID:1000 pgtables:1269760kB oom_score_adj:0
    
    After:
    
    [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
    ...
    [   1436]  1000  1436   217253   151890  1294336        0             0 python
    ...
    Out of memory: Killed process 1436 (python) total-vm:869012kB, anon-rss:607516kB, file-rss:44kB, shmem-rss:0kB, UID:1000 pgtables:1264kB oom_score_adj:0
    
    Link: http://lkml.kernel.org/r/20191211202830.1600-1-idryomov@gmail.com
    Fixes: 70cb6d267790 ("mm/oom: add oom_score_adj and pgtables to Killed process message")
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Edward Chron <echron@arista.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 366b5dce6dcd8abe01953d58953d7bd4cea5d153
Author: Yang Shi <yang.shi@linux.alibaba.com>
Date:   Sat Jan 4 12:59:46 2020 -0800

    mm: move_pages: return valid node id in status if the page is already on the target node
    
    commit e0153fc2c7606f101392b682e720a7a456d6c766 upstream.
    
    Felix Abecassis reports move_pages() would return random status if the
    pages are already on the target node by the below test program:
    
      int main(void)
      {
            const long node_id = 1;
            const long page_size = sysconf(_SC_PAGESIZE);
            const int64_t num_pages = 8;
    
            unsigned long nodemask =  1 << node_id;
            long ret = set_mempolicy(MPOL_BIND, &nodemask, sizeof(nodemask));
            if (ret < 0)
                    return (EXIT_FAILURE);
    
            void **pages = malloc(sizeof(void*) * num_pages);
            for (int i = 0; i < num_pages; ++i) {
                    pages[i] = mmap(NULL, page_size, PROT_WRITE | PROT_READ,
                                    MAP_PRIVATE | MAP_POPULATE | MAP_ANONYMOUS,
                                    -1, 0);
                    if (pages[i] == MAP_FAILED)
                            return (EXIT_FAILURE);
            }
    
            ret = set_mempolicy(MPOL_DEFAULT, NULL, 0);
            if (ret < 0)
                    return (EXIT_FAILURE);
    
            int *nodes = malloc(sizeof(int) * num_pages);
            int *status = malloc(sizeof(int) * num_pages);
            for (int i = 0; i < num_pages; ++i) {
                    nodes[i] = node_id;
                    status[i] = 0xd0; /* simulate garbage values */
            }
    
            ret = move_pages(0, num_pages, pages, nodes, status, MPOL_MF_MOVE);
            printf("move_pages: %ld\n", ret);
            for (int i = 0; i < num_pages; ++i)
                    printf("status[%d] = %d\n", i, status[i]);
      }
    
    Then running the program would return nonsense status values:
    
      $ ./move_pages_bug
      move_pages: 0
      status[0] = 208
      status[1] = 208
      status[2] = 208
      status[3] = 208
      status[4] = 208
      status[5] = 208
      status[6] = 208
      status[7] = 208
    
    This is because the status is not set if the page is already on the
    target node, but move_pages() should return valid status as long as it
    succeeds.  The valid status may be errno or node id.
    
    We can't simply initialize status array to zero since the pages may be
    not on node 0.  Fix it by updating status with node id which the page is
    already on.
    
    Link: http://lkml.kernel.org/r/1575584353-125392-1-git-send-email-yang.shi@linux.alibaba.com
    Fixes: a49bd4d71637 ("mm, numa: rework do_pages_move")
    Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
    Reported-by: Felix Abecassis <fabecassis@nvidia.com>
    Tested-by: Felix Abecassis <fabecassis@nvidia.com>
    Suggested-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Acked-by: Christoph Lameter <cl@linux.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: <stable@vger.kernel.org>    [4.17+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a54454d5d6fd70dd7401994ebd859f7e4c961d6d
Author: Shakeel Butt <shakeelb@google.com>
Date:   Sat Jan 4 12:59:43 2020 -0800

    memcg: account security cred as well to kmemcg
    
    commit 84029fd04c201a4c7e0b07ba262664900f47c6f5 upstream.
    
    The cred_jar kmem_cache is already memcg accounted in the current kernel
    but cred->security is not.  Account cred->security to kmemcg.
    
    Recently we saw high root slab usage on our production and on further
    inspection, we found a buggy application leaking processes.  Though that
    buggy application was contained within its memcg but we observe much
    more system memory overhead, couple of GiBs, during that period.  This
    overhead can adversely impact the isolation on the system.
    
    One source of high overhead we found was cred->security objects, which
    have a lifetime of at least the life of the process which allocated
    them.
    
    Link: http://lkml.kernel.org/r/20191205223721.40034-1-shakeelb@google.com
    Signed-off-by: Shakeel Butt <shakeelb@google.com>
    Acked-by: Chris Down <chris@chrisdown.name>
    Reviewed-by: Roman Gushchin <guro@fb.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdc57bac994b100b3fc501f224cb1269812e8f31
Author: Chanho Min <chanho.min@lge.com>
Date:   Sat Jan 4 12:59:36 2020 -0800

    mm/zsmalloc.c: fix the migrated zspage statistics.
    
    commit ac8f05da5174c560de122c499ce5dfb5d0dfbee5 upstream.
    
    When zspage is migrated to the other zone, the zone page state should be
    updated as well, otherwise the NR_ZSPAGE for each zone shows wrong
    counts including proc/zoneinfo in practice.
    
    Link: http://lkml.kernel.org/r/1575434841-48009-1-git-send-email-chanho.min@lge.com
    Fixes: 91537fee0013 ("mm: add NR_ZSMALLOC to vmstat")
    Signed-off-by: Chanho Min <chanho.min@lge.com>
    Signed-off-by: Jinsuk Choi <jjinsuk.choi@lge.com>
    Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Cc: <stable@vger.kernel.org>        [4.9+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e84c5b76173b3b49b054aa340066d5001ab20b70
Author: David Hildenbrand <david@redhat.com>
Date:   Sat Jan 4 12:59:33 2020 -0800

    mm/memory_hotplug: shrink zones when offlining memory
    
    commit feee6b2989165631b17ac6d4ccdbf6759254e85a upstream.
    
    We currently try to shrink a single zone when removing memory.  We use
    the zone of the first page of the memory we are removing.  If that
    memmap was never initialized (e.g., memory was never onlined), we will
    read garbage and can trigger kernel BUGs (due to a stale pointer):
    
        BUG: unable to handle page fault for address: 000000000000353d
        #PF: supervisor write access in kernel mode
        #PF: error_code(0x0002) - not-present page
        PGD 0 P4D 0
        Oops: 0002 [#1] SMP PTI
        CPU: 1 PID: 7 Comm: kworker/u8:0 Not tainted 5.3.0-rc5-next-20190820+ #317
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.4
        Workqueue: kacpi_hotplug acpi_hotplug_work_fn
        RIP: 0010:clear_zone_contiguous+0x5/0x10
        Code: 48 89 c6 48 89 c3 e8 2a fe ff ff 48 85 c0 75 cf 5b 5d c3 c6 85 fd 05 00 00 01 5b 5d c3 0f 1f 840
        RSP: 0018:ffffad2400043c98 EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000200000000 RCX: 0000000000000000
        RDX: 0000000000200000 RSI: 0000000000140000 RDI: 0000000000002f40
        RBP: 0000000140000000 R08: 0000000000000000 R09: 0000000000000001
        R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000140000
        R13: 0000000000140000 R14: 0000000000002f40 R15: ffff9e3e7aff3680
        FS:  0000000000000000(0000) GS:ffff9e3e7bb00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 000000000000353d CR3: 0000000058610000 CR4: 00000000000006e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         __remove_pages+0x4b/0x640
         arch_remove_memory+0x63/0x8d
         try_remove_memory+0xdb/0x130
         __remove_memory+0xa/0x11
         acpi_memory_device_remove+0x70/0x100
         acpi_bus_trim+0x55/0x90
         acpi_device_hotplug+0x227/0x3a0
         acpi_hotplug_work_fn+0x1a/0x30
         process_one_work+0x221/0x550
         worker_thread+0x50/0x3b0
         kthread+0x105/0x140
         ret_from_fork+0x3a/0x50
        Modules linked in:
        CR2: 000000000000353d
    
    Instead, shrink the zones when offlining memory or when onlining failed.
    Introduce and use remove_pfn_range_from_zone(() for that.  We now
    properly shrink the zones, even if we have DIMMs whereby
    
     - Some memory blocks fall into no zone (never onlined)
    
     - Some memory blocks fall into multiple zones (offlined+re-onlined)
    
     - Multiple memory blocks that fall into different zones
    
    Drop the zone parameter (with a potential dubious value) from
    __remove_pages() and __remove_section().
    
    Link: http://lkml.kernel.org/r/20191006085646.5768-6-david@redhat.com
    Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online")      [visible after d0dc12e86b319]
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
    Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Logan Gunthorpe <logang@deltatee.com>
    Cc: <stable@vger.kernel.org>    [5.0+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80d9e63714a43a162ce79abe33dd18a2111f3c4e
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Dec 11 12:47:57 2019 +0100

    media: cec: check 'transmit_in_progress', not 'transmitting'
    
    commit ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 upstream.
    
    Currently wait_event_interruptible_timeout is called in cec_thread_func()
    when adap->transmitting is set. But if the adapter is unconfigured
    while transmitting, then adap->transmitting is set to NULL. But the
    hardware is still actually transmitting the message, and that's
    indicated by adap->transmit_in_progress and we should wait until that
    is finished or times out before transmitting new messages.
    
    As the original commit says: adap->transmitting is the userspace view,
    adap->transmit_in_progress reflects the hardware state.
    
    However, if adap->transmitting is NULL and adap->transmit_in_progress
    is true, then wait_event_interruptible is called (no timeout), which
    can get stuck indefinitely if the CEC driver is flaky and never marks
    the transmit-in-progress as 'done'.
    
    So test against transmit_in_progress when deciding whether to use
    the timeout variant or not, instead of testing against adap->transmitting.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 32804fcb612b ("media: cec: keep track of outstanding transmits")
    Cc: <stable@vger.kernel.org>      # for v4.19 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a7130220ab48b251987c3ec5843116285e67b22
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Sat Dec 7 23:48:09 2019 +0100

    media: cec: avoid decrementing transmit_queue_sz if it is 0
    
    commit 95c29d46ab2a517e4c26d0a07300edca6768db17 upstream.
    
    WARN if transmit_queue_sz is 0 but do not decrement it.
    The CEC adapter will become unresponsive if it goes below
    0 since then it thinks there are 4 billion messages in the
    queue.
    
    Obviously this should not happen, but a driver bug could
    cause this.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: <stable@vger.kernel.org>      # for v4.12 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e572db9a4dfe78bfa4a972832609de40907f21cb
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Dec 4 08:52:08 2019 +0100

    media: cec: CEC 2.0-only bcast messages were ignored
    
    commit cec935ce69fc386f13959578deb40963ebbb85c3 upstream.
    
    Some messages are allowed to be a broadcast message in CEC 2.0
    only, and should be ignored by CEC 1.4 devices.
    
    Unfortunately, the check was wrong, causing such messages to be
    marked as invalid under CEC 2.0.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: <stable@vger.kernel.org>      # for v4.10 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f868e597a3d9e66c61cb6a23f64dc9ec8361113c
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Sat Dec 7 23:43:23 2019 +0100

    media: pulse8-cec: fix lost cec_transmit_attempt_done() call
    
    commit e5a52a1d15c79bb48a430fb263852263ec1d3f11 upstream.
    
    The periodic PING command could interfere with the result of
    a CEC transmit, causing a lost cec_transmit_attempt_done()
    call.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: <stable@vger.kernel.org>      # for v4.10 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b004a238460113276319536534928c58d95e599
Author: Paul Burton <paulburton@kernel.org>
Date:   Wed Jan 1 20:50:38 2020 -0800

    MIPS: Avoid VDSO ABI breakage due to global register variable
    
    commit bbcc5672b0063b0e9d65dc8787a4f09c3b5bb5cc upstream.
    
    Declaring __current_thread_info as a global register variable has the
    effect of preventing GCC from saving & restoring its value in cases
    where the ABI would typically do so.
    
    To quote GCC documentation:
    
    > If the register is a call-saved register, call ABI is affected: the
    > register will not be restored in function epilogue sequences after the
    > variable has been assigned. Therefore, functions cannot safely return
    > to callers that assume standard ABI.
    
    When our position independent VDSO is built for the n32 or n64 ABIs all
    functions it exposes should be preserving the value of $gp/$28 for their
    caller, but in the presence of the __current_thread_info global register
    variable GCC stops doing so & simply clobbers $gp/$28 when calculating
    the address of the GOT.
    
    In cases where the VDSO returns success this problem will typically be
    masked by the caller in libc returning & restoring $gp/$28 itself, but
    that is by no means guaranteed. In cases where the VDSO returns an error
    libc will typically contain a fallback path which will now fail
    (typically with a bad memory access) if it attempts anything which
    relies upon the value of $gp/$28 - eg. accessing anything via the GOT.
    
    One fix for this would be to move the declaration of
    __current_thread_info inside the current_thread_info() function,
    demoting it from global register variable to local register variable &
    avoiding inadvertently creating a non-standard calling ABI for the VDSO.
    Unfortunately this causes issues for clang, which doesn't support local
    register variables as pointed out by commit fe92da0f355e ("MIPS: Changed
    current_thread_info() to an equivalent supported by both clang and GCC")
    which introduced the global register variable before we had a VDSO to
    worry about.
    
    Instead, fix this by continuing to use the global register variable for
    the kernel proper but declare __current_thread_info as a simple extern
    variable when building the VDSO. It should never be referenced, and will
    cause a link error if it is. This resolves the calling convention issue
    for the VDSO without having any impact upon the build of the kernel
    itself for either clang or gcc.
    
    Signed-off-by: Paul Burton <paulburton@kernel.org>
    Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
    Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Christian Brauner <christian.brauner@canonical.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: <stable@vger.kernel.org> # v4.4+
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e0bee36699da7ef7ee7f0e6facef305c2de281b
Author: Alexander Lobakin <alobakin@dlink.ru>
Date:   Fri Dec 6 11:07:41 2019 +0300

    MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig
    
    commit f596cf0d8062cb5d0a4513a8b3afca318c13be10 upstream.
    
    It is completely wrong to check for compile-time MIPS ISA revision in
    the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully
    omitted by the CC while the rest system will think that the JIT is
    actually present and works [1].
    We can check if the selected CPU really supports MIPS eBPF JIT at
    configure time and avoid such situations when kernel can be built
    without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y.
    
    [1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/
    
    Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
    Cc: <stable@vger.kernel.org> # v5.2+
    Signed-off-by: Alexander Lobakin <alobakin@dlink.ru>
    Signed-off-by: Paul Burton <paulburton@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: Hassan Naveed <hnaveed@wavecomp.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: Andrii Nakryiko <andriin@fb.com>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: bpf@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adbe05523e3411fbc6d013fb044d6e4e45f19479
Author: Paul Burton <paulburton@kernel.org>
Date:   Thu Dec 5 10:23:18 2019 -0800

    MIPS: BPF: Disable MIPS32 eBPF JIT
    
    commit f8fffebdea752a25757b906f3dffecf1a59a6194 upstream.
    
    Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32
    architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has
    previously only been availailable for MIPS64. It was my understanding at
    the time that the BPF test suite was passing & JITing a comparable
    number of tests to our cBPF JIT [1], but it turns out that was not the
    case.
    
    The eBPF JIT has a number of problems on MIPS32:
    
    - Most notably various code paths still result in emission of MIPS64
      instructions which will cause reserved instruction exceptions & kernel
      panics when run on MIPS32 CPUs.
    
    - The eBPF JIT doesn't account for differences between the O32 ABI used
      by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably
      arguments beyond the first 4 are passed on the stack in O32, and this
      is entirely unhandled when JITing a BPF_CALL instruction. Stack space
      must be reserved for arguments even if they all fit in registers, and
      the callee is free to assume that stack space has been reserved for
      its use - with the eBPF JIT this is not the case, so calling any
      function can result in clobbering values on the stack & unpredictable
      behaviour. Function arguments in eBPF are always 64-bit values which
      is also entirely unhandled - the JIT still uses a single (32-bit)
      register per argument. As a result all function arguments are always
      passed incorrectly when JITing a BPF_CALL instruction, leading to
      kernel crashes or strange behavior.
    
    - The JIT attempts to bail our on use of ALU64 instructions or 64-bit
      memory access instructions. The code doing this at the start of
      build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW,
      when it should really be checking BPF_SIZE() & only doing so when
      BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false
      positives that cause more bailouts than intended, and that in turns
      hides some of the problems described above.
    
    - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF
      instructions that the MIPS32 eBPF JIT bails out on, leading to most
      cBPF programs not being JITed at all.
    
    Until these problems are resolved, revert the enabling of the eBPF JIT
    on MIPS32 done by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support
    for MIPS32 architecture.").
    
    Note that this does not undo the changes made to the eBPF JIT by that
    commit, since they are a useful starting point to providing MIPS32
    support - they're just not nearly complete.
    
    [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/
    
    Signed-off-by: Paul Burton <paulburton@kernel.org>
    Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Hassan Naveed <hnaveed@wavecomp.com>
    Cc: Tony Ambardar <itugrok@yahoo.com>
    Cc: bpf@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: <stable@vger.kernel.org> # v5.2+
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f72e33675f3fd2d5808efd101d737b1517154bf3
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Dec 17 09:51:40 2019 -0500

    drm/amdgpu/smu: add metrics table lock for vega20 (v2)
    
    commit 1c455101c6d10c99b310d6bcf613244c97854012 upstream.
    
    To protect access to the metrics table.
    
    v2: unlock on error
    
    Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
    Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86164784cfbe7a23f91d2cf6e0dba82d61f38c32
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Dec 17 09:50:42 2019 -0500

    drm/amdgpu/smu: add metrics table lock for navi (v2)
    
    commit e0e384c398d4638e54b6d2098f0ceaafdab870ee upstream.
    
    To protect access to the metrics table.
    
    v2: unlock on error
    
    Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
    Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 881b399da3a160273905010a154e07bdeb003109
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Dec 17 09:49:52 2019 -0500

    drm/amdgpu/smu: add metrics table lock for arcturus (v2)
    
    commit 1da87c9f67c98d552679974dbfc1f0f65b6a0a53 upstream.
    
    To protect access to the metrics table.
    
    v2: unlock on error
    
    Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
    Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7514bbe97516963d6071c37bd06eadd9ad463d1d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Dec 17 09:35:01 2019 -0500

    drm/amdgpu/smu: add metrics table lock
    
    commit 073d5eef9e043c2b7e3ef12bc6c879b1d248e831 upstream.
    
    This table is used for lots of things, add it's own lock.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
    Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55ab031c0a7db9617ab437f95bda85386696d2cf
Author: Stefan Mavrodiev <stefan@olimex.com>
Date:   Tue Dec 17 14:46:32 2019 +0200

    drm/sun4i: hdmi: Remove duplicate cleanup calls
    
    commit 57177d214ee0816c4436c23d6c933ccb32c571f1 upstream.
    
    When the HDMI unbinds drm_connector_cleanup() and drm_encoder_cleanup()
    are called. This also happens when the connector and the encoder are
    destroyed. This double call triggers a NULL pointer exception.
    
    The patch fixes this by removing the cleanup calls in the unbind
    function.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
    Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191217124632.20820-1-stefan@olimex.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52702a539c33111fe35cc84593317cb2a9eb5f2b
Author: Kailang Yang <kailang@realtek.com>
Date:   Mon Dec 9 15:56:15 2019 +0800

    ALSA: hda/realtek - Add headset Mic no shutup for ALC283
    
    commit 66c5d718e5a6f80153b5e8d6ad8ba8e9c3320839 upstream.
    
    Chrome machine had humming noise from external speaker plugin at
    codec D3 state.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/2692449396954c6c968f5b75e2660358@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0844feca25b3a3d34d509ea936e6d52ecd0be32c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Dec 23 23:18:16 2019 +0100

    ALSA: hda - Apply sync-write workaround to old Intel platforms, too
    
    commit c366b3dbbab14b28d044b94eb9ce77c23482ea35 upstream.
    
    Klaus Ethgen reported occasional high CPU usages in his system that
    seem caused by HD-audio driver.  The perf output revealed that it's
    in the unsolicited event handling in the workqueue, and the problem
    seems triggered by some communication stall between the controller and
    the codec at the runtime or system resume.
    
    Actually a similar phenomenon was seen in the past for other Intel
    platforms, and we already applied the workaround to enforce sync-write
    for CORB/RIRB verbs for Skylake and newer chipsets (commit
    2756d9143aa5 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel
    chips").  Fortunately, the same workaround is applicable to the old
    chipset, and the experiment showed the positive effect.
    
    Based on the experiment result, this patch enables the sync-write
    workaround for all Intel chipsets.  The only reason I hesitated to
    apply this workaround was about the possibly slightly higher CPU usage.
    But if the lack of sync causes a much severer problem even for quite
    old chip, we should think this would be necessary for all Intel chips.
    
    Reported-by: Klaus Ethgen <Klaus@ethgen.ch>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191223171833.GA17053@chua
    Link: https://lore.kernel.org/r/20191223221816.32572-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56f395fb0a7ce9b7d55026fe6a5e94fa1b84b374
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Dec 18 21:26:50 2019 +0800

    ALSA: usb-audio: set the interface format after resume on Dell WD19
    
    commit 92adc96f8eecd9522a907c197cc3d62e405539fe upstream.
    
    Recently we found the headset-mic on the Dell Dock WD19 doesn't work
    anymore after s3 (s2i or deep), this problem could be workarounded by
    closing (pcm_close) the app and then reopening (pcm_open) the app, so
    this bug is not easy to be detected by users.
    
    When problem happens, retire_capture_urb() could still be called
    periodically, but the size of captured data is always 0, it could be
    a firmware bug on the dock. Anyway I found after resuming, the
    snd_usb_pcm_prepare() will be called, and if we forcibly run
    set_format() to set the interface and its endpoint, the capture
    size will be normal again. This problem and workaound also apply to
    playback.
    
    To fix it in the kernel, add a quirk to let set_format() run
    forcibly once after resume.
    
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191218132650.6303-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f47e52124334c8e25e2a82e2ac65609af078c4a4
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Dec 20 10:31:34 2019 +0100

    ALSA: usb-audio: fix set_format altsetting sanity check
    
    commit 0141254b0a74b37aa7eb13d42a56adba84d51c73 upstream.
    
    Make sure to check the return value of usb_altnum_to_altsetting() to
    avoid dereferencing a NULL pointer when the requested alternate settings
    is missing.
    
    The format altsetting number may come from a quirk table and there does
    not seem to be any other validation of it (the corresponding index is
    checked however).
    
    Fixes: b099b9693d23 ("ALSA: usb-audio: Avoid superfluous usb_set_interface() calls")
    Cc: stable <stable@vger.kernel.org>     # 4.18
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191220093134.1248-1-johan@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60a6c5d810bce7d55637a1f00c7e236dfce22fcd
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 18 20:26:06 2019 +0100

    ALSA: ice1724: Fix sleep-in-atomic in Infrasonic Quartet support code
    
    commit 0aec96f5897ac16ad9945f531b4bef9a2edd2ebd upstream.
    
    Jia-Ju Bai reported a possible sleep-in-atomic scenario in the ice1724
    driver with Infrasonic Quartet support code: namely, ice->set_rate
    callback gets called inside ice->reg_lock spinlock, while the callback
    in quartet.c holds ice->gpio_mutex.
    
    This patch fixes the invalid call: it simply moves the calls of
    ice->set_rate and ice->set_mclk callbacks outside the spinlock.
    
    Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/5d43135e-73b9-a46a-2155-9e91d0dcdf83@gmail.com
    Link: https://lore.kernel.org/r/20191218192606.12866-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 173fa52f7fd25519deb286173d80ed742007b28e
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Sat Nov 30 17:50:22 2019 -0800

    mm: drop mmap_sem before calling balance_dirty_pages() in write fault
    
    [ Upstream commit 89b15332af7c0312a41e50846819ca6613b58b4c ]
    
    One of our services is observing hanging ps/top/etc under heavy write
    IO, and the task states show this is an mmap_sem priority inversion:
    
    A write fault is holding the mmap_sem in read-mode and waiting for
    (heavily cgroup-limited) IO in balance_dirty_pages():
    
        balance_dirty_pages+0x724/0x905
        balance_dirty_pages_ratelimited+0x254/0x390
        fault_dirty_shared_page.isra.96+0x4a/0x90
        do_wp_page+0x33e/0x400
        __handle_mm_fault+0x6f0/0xfa0
        handle_mm_fault+0xe4/0x200
        __do_page_fault+0x22b/0x4a0
        page_fault+0x45/0x50
    
    Somebody tries to change the address space, contending for the mmap_sem in
    write-mode:
    
        call_rwsem_down_write_failed_killable+0x13/0x20
        do_mprotect_pkey+0xa8/0x330
        SyS_mprotect+0xf/0x20
        do_syscall_64+0x5b/0x100
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    
    The waiting writer locks out all subsequent readers to avoid lock
    starvation, and several threads can be seen hanging like this:
    
        call_rwsem_down_read_failed+0x14/0x30
        proc_pid_cmdline_read+0xa0/0x480
        __vfs_read+0x23/0x140
        vfs_read+0x87/0x130
        SyS_read+0x42/0x90
        do_syscall_64+0x5b/0x100
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    
    To fix this, do what we do for cache read faults already: drop the
    mmap_sem before calling into anything IO bound, in this case the
    balance_dirty_pages() function, and return VM_FAULT_RETRY.
    
    Link: http://lkml.kernel.org/r/20190924194238.GA29030@cmpxchg.org
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Josef Bacik <josef@toxicpanda.com>
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 943cd69efac437d82a7aea0659fccbcc071730de
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Dec 28 07:05:48 2019 +0800

    block: add bio_truncate to fix guard_bio_eod
    
    [ Upstream commit 85a8ce62c2eabe28b9d76ca4eecf37922402df93 ]
    
    Some filesystem, such as vfat, may send bio which crosses device boundary,
    and the worse thing is that the IO request starting within device boundaries
    can contain more than one segment past EOD.
    
    Commit dce30ca9e3b6 ("fs: fix guard_bio_eod to check for real EOD errors")
    tries to fix this issue by returning -EIO for this situation. However,
    this way lets fs user code lose chance to handle -EIO, then sync_inodes_sb()
    may hang for ever.
    
    Also the current truncating on last segment is dangerous by updating the
    last bvec, given bvec table becomes not immutable any more, and fs bio
    users may not retrieve the truncated pages via bio_for_each_segment_all() in
    its .end_io callback.
    
    Fixes this issue by supporting multi-segment truncating. And the
    approach is simpler:
    
    - just update bio size since block layer can make correct bvec with
    the updated bio size. Then bvec table becomes really immutable.
    
    - zero all truncated segments for read bio
    
    Cc: Carlos Maiolino <cmaiolino@redhat.com>
    Cc: linux-fsdevel@vger.kernel.org
    Fixed-by: dce30ca9e3b6 ("fs: fix guard_bio_eod to check for real EOD errors")
    Reported-by: syzbot+2b9e54155c8c25d8d165@syzkaller.appspotmail.com
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2922cf593f854ae2fe65e8666bb0330fcbdbddde
Author: Phil Sutter <phil@nwl.cc>
Date:   Wed Dec 18 00:59:29 2019 +0100

    netfilter: nft_tproxy: Fix port selector on Big Endian
    
    [ Upstream commit 8cb4ec44de42b99b92399b4d1daf3dc430ed0186 ]
    
    On Big Endian architectures, u16 port value was extracted from the wrong
    parts of u32 sreg_port, just like commit 10596608c4d62 ("netfilter:
    nf_tables: fix mismatch in big-endian system") describes.
    
    Fixes: 4ed8eb6570a49 ("netfilter: nf_tables: Add native tproxy support")
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Acked-by: Florian Westphal <fw@strlen.de>
    Acked-by: Máté Eckl <ecklm94@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8acc0f2c2989850e0e2e9122b225c89382bc2ca
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Dec 16 16:12:24 2019 +0100

    ALSA: hda - Downgrade error message for single-cmd fallback
    
    [ Upstream commit 475feec0c41ad71cb7d02f0310e56256606b57c5 ]
    
    We made the error message for the CORB/RIRB communication clearer by
    upgrading to dev_WARN() so that user can notice better.  But this
    struck us like a boomerang: now it caught syzbot and reported back as
    a fatal issue although it's not really any too serious bug that worth
    for stopping the whole system.
    
    OK, OK, let's be softy, downgrade it to the standard dev_err() again.
    
    Fixes: dd65f7e19c69 ("ALSA: hda - Show the fatal CORB/RIRB error more clearly")
    Reported-by: syzbot+b3028ac3933f5c466389@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20191216151224.30013-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d25bf5a341468935906d87e9aa7c95c2175651c9
Author: Christian Brauner <christian.brauner@ubuntu.com>
Date:   Wed Oct 9 13:48:09 2019 +0200

    taskstats: fix data-race
    
    [ Upstream commit 0b8d616fb5a8ffa307b1d3af37f55c15dae14f28 ]
    
    When assiging and testing taskstats in taskstats_exit() there's a race
    when setting up and reading sig->stats when a thread-group with more
    than one thread exits:
    
    write to 0xffff8881157bbe10 of 8 bytes by task 7951 on cpu 0:
     taskstats_tgid_alloc kernel/taskstats.c:567 [inline]
     taskstats_exit+0x6b7/0x717 kernel/taskstats.c:596
     do_exit+0x2c2/0x18e0 kernel/exit.c:864
     do_group_exit+0xb4/0x1c0 kernel/exit.c:983
     get_signal+0x2a2/0x1320 kernel/signal.c:2734
     do_signal+0x3b/0xc00 arch/x86/kernel/signal.c:815
     exit_to_usermode_loop+0x250/0x2c0 arch/x86/entry/common.c:159
     prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
     syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
     do_syscall_64+0x2d7/0x2f0 arch/x86/entry/common.c:299
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    read to 0xffff8881157bbe10 of 8 bytes by task 7949 on cpu 1:
     taskstats_tgid_alloc kernel/taskstats.c:559 [inline]
     taskstats_exit+0xb2/0x717 kernel/taskstats.c:596
     do_exit+0x2c2/0x18e0 kernel/exit.c:864
     do_group_exit+0xb4/0x1c0 kernel/exit.c:983
     __do_sys_exit_group kernel/exit.c:994 [inline]
     __se_sys_exit_group kernel/exit.c:992 [inline]
     __x64_sys_exit_group+0x2e/0x30 kernel/exit.c:992
     do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fix this by using smp_load_acquire() and smp_store_release().
    
    Reported-by: syzbot+c5d03165a1bd1dead0c1@syzkaller.appspotmail.com
    Fixes: 34ec12349c8a ("taskstats: cleanup ->signal->stats allocation")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
    Acked-by: Marco Elver <elver@google.com>
    Reviewed-by: Will Deacon <will@kernel.org>
    Reviewed-by: Andrea Parri <parri.andrea@gmail.com>
    Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
    Link: https://lore.kernel.org/r/20191009114809.8643-1-christian.brauner@ubuntu.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7af03159b88e72324639d216871aaf12c203b9e
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Sat Nov 30 17:50:26 2019 -0800

    shmem: pin the file in shmem_fault() if mmap_sem is dropped
    
    [ Upstream commit 8897c1b1a1795cab23d5ac13e4e23bf0b5f4e0c6 ]
    
    syzbot found the following crash:
    
      BUG: KASAN: use-after-free in perf_trace_lock_acquire+0x401/0x530 include/trace/events/lock.h:13
      Read of size 8 at addr ffff8880a5cf2c50 by task syz-executor.0/26173
    
      CPU: 0 PID: 26173 Comm: syz-executor.0 Not tainted 5.3.0-rc6 #146
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
         perf_trace_lock_acquire+0x401/0x530 include/trace/events/lock.h:13
         trace_lock_acquire include/trace/events/lock.h:13 [inline]
         lock_acquire+0x2de/0x410 kernel/locking/lockdep.c:4411
         __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
         _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
         spin_lock include/linux/spinlock.h:338 [inline]
         shmem_fault+0x5ec/0x7b0 mm/shmem.c:2034
         __do_fault+0x111/0x540 mm/memory.c:3083
         do_shared_fault mm/memory.c:3535 [inline]
         do_fault mm/memory.c:3613 [inline]
         handle_pte_fault mm/memory.c:3840 [inline]
         __handle_mm_fault+0x2adf/0x3f20 mm/memory.c:3964
         handle_mm_fault+0x1b5/0x6b0 mm/memory.c:4001
         do_user_addr_fault arch/x86/mm/fault.c:1441 [inline]
         __do_page_fault+0x536/0xdd0 arch/x86/mm/fault.c:1506
         do_page_fault+0x38/0x590 arch/x86/mm/fault.c:1530
         page_fault+0x39/0x40 arch/x86/entry/entry_64.S:1202
    
    It happens if the VMA got unmapped under us while we dropped mmap_sem
    and inode got freed.
    
    Pinning the file if we drop mmap_sem fixes the issue.
    
    Link: http://lkml.kernel.org/r/20190927083908.rhifa4mmaxefc24r@box
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reported-by: syzbot+03ee87124ee05af991bd@syzkaller.appspotmail.com
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d56c69c5ef98acd80d1a06467a06cc3e2d1f28b6
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Nov 6 12:59:33 2019 -0800

    tcp: fix data-race in tcp_recvmsg()
    
    [ Upstream commit a5a7daa52edb5197a3b696afee13ef174dc2e993 ]
    
    Reading tp->recvmsg_inq after socket lock is released
    raises a KCSAN warning [1]
    
    Replace has_tss & has_cmsg by cmsg_flags and make
    sure to not read tp->recvmsg_inq a second time.
    
    [1]
    BUG: KCSAN: data-race in tcp_chrono_stop / tcp_recvmsg
    
    write to 0xffff888126adef24 of 2 bytes by interrupt on cpu 0:
     tcp_chrono_set net/ipv4/tcp_output.c:2309 [inline]
     tcp_chrono_stop+0x14c/0x280 net/ipv4/tcp_output.c:2338
     tcp_clean_rtx_queue net/ipv4/tcp_input.c:3165 [inline]
     tcp_ack+0x274f/0x3170 net/ipv4/tcp_input.c:3688
     tcp_rcv_established+0x37e/0xf50 net/ipv4/tcp_input.c:5696
     tcp_v4_do_rcv+0x381/0x4e0 net/ipv4/tcp_ipv4.c:1561
     tcp_v4_rcv+0x19dc/0x1bb0 net/ipv4/tcp_ipv4.c:1942
     ip_protocol_deliver_rcu+0x4d/0x420 net/ipv4/ip_input.c:204
     ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
     NF_HOOK include/linux/netfilter.h:305 [inline]
     NF_HOOK include/linux/netfilter.h:299 [inline]
     ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
     dst_input include/net/dst.h:442 [inline]
     ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
     NF_HOOK include/linux/netfilter.h:305 [inline]
     NF_HOOK include/linux/netfilter.h:299 [inline]
     ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
     __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5010
     __netif_receive_skb+0x37/0xf0 net/core/dev.c:5124
     netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5214
     napi_skb_finish net/core/dev.c:5677 [inline]
     napi_gro_receive+0x28f/0x330 net/core/dev.c:5710
    
    read to 0xffff888126adef25 of 1 bytes by task 7275 on cpu 1:
     tcp_recvmsg+0x77b/0x1a30 net/ipv4/tcp.c:2187
     inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
     sock_recvmsg_nosec net/socket.c:871 [inline]
     sock_recvmsg net/socket.c:889 [inline]
     sock_recvmsg+0x92/0xb0 net/socket.c:885
     sock_read_iter+0x15f/0x1e0 net/socket.c:967
     call_read_iter include/linux/fs.h:1889 [inline]
     new_sync_read+0x389/0x4f0 fs/read_write.c:414
     __vfs_read+0xb1/0xc0 fs/read_write.c:427
     vfs_read fs/read_write.c:461 [inline]
     vfs_read+0x143/0x2c0 fs/read_write.c:446
     ksys_read+0xd5/0x1b0 fs/read_write.c:587
     __do_sys_read fs/read_write.c:597 [inline]
     __se_sys_read fs/read_write.c:595 [inline]
     __x64_sys_read+0x4c/0x60 fs/read_write.c:595
     do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 7275 Comm: sshd Not tainted 5.4.0-rc3+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: b75eba76d3d7 ("tcp: send in-queue bytes in cmsg upon read")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d53678610b863f7aa599f9c080b59674cb3aab07
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Fri Nov 29 15:40:27 2019 +0100

    ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen
    
    [ Upstream commit d2cd795c4ece1a24fda170c35eeb4f17d9826cbb ]
    
    The auto-parser assigns the bass speaker to DAC3 (NID 0x06) which
    is without the volume control. I do not see a reason to use DAC2,
    because the shared output to all speakers produces the sufficient
    and well balanced sound. The stereo support is enough for this
    purpose (laptop).
    
    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20191129144027.14765-1-perex@perex.cz
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9538659160cceadfeb5910e0d570c1f1df18e4b7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 21 16:25:20 2019 +0200

    PCI: Fix missing inline for pci_pr3_present()
    
    [ Upstream commit 46b4bff6572b0552b1ee062043621e4b252638d8 ]
    
    The inline prefix was missing in the dummy function pci_pr3_present()
    definition.  Fix it.
    
    Reported-by: kbuild test robot <lkp@intel.com>
    Fixes: 52525b7a3cf8 ("PCI: Add a helper to check Power Resource Requirements _PR3 existence")
    Link: https://lore.kernel.org/r/201910212111.qHm6OcWx%lkp@intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 891f29feeb36415475588d834a26a9cb0c44a062
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Oct 18 15:38:48 2019 +0800

    ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver
    
    [ Upstream commit bacd861452d2be86a4df341b12e32db7dac8021e ]
    
    Nvidia proprietary driver doesn't support runtime power management, so
    when a user only wants to use the integrated GPU, it's a common practice
    to let dGPU not to bind any driver, and let its upstream port to be
    runtime suspended. At the end of runtime suspension the port uses
    platform power management to disable power through _OFF method of power
    resource, which is listed by _PR3.
    
    After commit b516ea586d71 ("PCI: Enable NVIDIA HDA controllers"), when
    the dGPU comes with an HDA function, the HDA won't be suspended if the
    dGPU is unbound, so the power resource can't be turned off by its
    upstream port driver.
    
    Commit 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for
    discrete GPU") only allows HDA to be runtime suspended once GPU is
    bound, to keep APU's HDA working.
    
    However, HDA on dGPU isn't that useful if dGPU is not bound to any
    driver.  So let's relax the runtime suspend requirement for dGPU's HDA
    function, to disable the power source to save lots of power.
    
    BugLink: https://bugs.launchpad.net/bugs/1840835
    Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers")
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Link: https://lore.kernel.org/r/20191018073848.14590-2-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eef2e98832a1cbea9a66b46b5a42d38fc96bccf2
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Oct 18 15:38:47 2019 +0800

    PCI: Add a helper to check Power Resource Requirements _PR3 existence
    
    [ Upstream commit 52525b7a3cf82adec5c6cf0ecbd23ff228badc94 ]
    
    A driver may want to know the existence of _PR3, to choose different
    runtime suspend behavior. A user will be add in next patch.
    
    This is mostly the same as nouveau_pr3_present().
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://lore.kernel.org/r/20191018073848.14590-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1f7ec8e5b5408b8723f2f29847dcc3488a4246c
Author: Chris Chiu <chiu@endlessm.com>
Date:   Mon Dec 30 11:11:18 2019 +0800

    ALSA: hda/realtek - Enable the bass speaker of ASUS UX431FLC
    
    [ Upstream commit 48e01504cf5315cbe6de9b7412e792bfcc3dd9e1 ]
    
    ASUS reported that there's an bass speaker in addition to internal
    speaker and it uses DAC 0x02. It was not enabled in the commit
    436e25505f34 ("ALSA: hda/realtek - Enable internal speaker of ASUS
    UX431FLC") which only enables the amplifier and the front speaker.
    This commit enables the bass speaker on top of the aforementioned
    work to improve the acoustic experience.
    
    Fixes: 436e25505f34 ("ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC")
    Signed-off-by: Chris Chiu <chiu@endlessm.com>
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191230031118.95076-1-chiu@endlessm.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65e8768eb2642c697029b29673399b5418b2939e
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Dec 19 14:12:15 2019 +0800

    ALSA: hda/realtek - Add Bass Speaker and fixed dac for bass speaker
    
    [ Upstream commit e79c22695abd3b75a6aecf4ea4b9607e8d82c49c ]
    
    Dell has new platform which has dual speaker connecting.
    They want dual speaker which use same dac for output.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/229c7efa2b474a16b7d8a916cd096b68@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0360ce1eafbd00fb5169d8c19438554cde79cbb9
Author: Andy Whitcroft <apw@canonical.com>
Date:   Wed Sep 25 15:39:12 2019 +0100

    PM / hibernate: memory_bm_find_bit(): Tighten node optimisation
    
    [ Upstream commit da6043fe85eb5ec621e34a92540735dcebbea134 ]
    
    When looking for a bit by number we make use of the cached result from the
    preceding lookup to speed up operation.  Firstly we check if the requested
    pfn is within the cached zone and if not lookup the new zone.  We then
    check if the offset for that pfn falls within the existing cached node.
    This happens regardless of whether the node is within the zone we are
    now scanning.  With certain memory layouts it is possible for this to
    false trigger creating a temporary alias for the pfn to a different bit.
    This leads the hibernation code to free memory which it was never allocated
    with the expected fallout.
    
    Ensure the zone we are scanning matches the cached zone before considering
    the cached node.
    
    Deep thanks go to Andrea for many, many, many hours of hacking and testing
    that went into cornering this bug.
    
    Reported-by: Andrea Righi <andrea.righi@canonical.com>
    Tested-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33fa919df6643a97e696bfce022f5a3b0a8205ff
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Dec 12 15:17:50 2019 +0100

    xen/balloon: fix ballooned page accounting without hotplug enabled
    
    [ Upstream commit c673ec61ade89bf2f417960f986bc25671762efb ]
    
    When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
    reserve_additional_memory() will set balloon_stats.target_pages to a
    wrong value in case there are still some ballooned pages allocated via
    alloc_xenballooned_pages().
    
    This will result in balloon_process() no longer be triggered when
    ballooned pages are freed in batches.
    
    Reported-by: Nicholas Tsirakis <niko.tsirakis@gmail.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec177a46e9d0d35f81b254a616ff03fe757f14f6
Author: Paul Durrant <pdurrant@amazon.com>
Date:   Tue Dec 10 14:53:05 2019 +0000

    xen-blkback: prevent premature module unload
    
    [ Upstream commit fa2ac657f9783f0891b2935490afe9a7fd29d3fa ]
    
    Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
    cache. This cache is destoyed when xen-blkif is unloaded so it is
    necessary to wait for the deferred free routine used for such objects to
    complete. This necessity was missed in commit 14855954f636 "xen-blkback:
    allow module to be cleanly unloaded". This patch fixes the problem by
    taking/releasing extra module references in xen_blkif_alloc/free()
    respectively.
    
    Signed-off-by: Paul Durrant <pdurrant@amazon.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e56db866ceac1fbbbbda57d305764b9d957819e1
Author: Maor Gottlieb <maorg@mellanox.com>
Date:   Thu Dec 12 11:12:14 2019 +0200

    IB/mlx5: Fix steering rule of drop and count
    
    [ Upstream commit ed9085fed9d95d5921582e3c8474f3736c5d2782 ]
    
    There are two flow rule destinations: QP and packet. While users are
    setting DROP packet rule, the QP should not be set as a destination.
    
    Fixes: 3b3233fbf02e ("IB/mlx5: Add flow counters binding support")
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Raed Salem <raeds@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20191212091214.315005-4-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c251d5f5b125c651413dc3bf230a8f25d161adb6
Author: Parav Pandit <parav@mellanox.com>
Date:   Thu Dec 12 11:12:13 2019 +0200

    IB/mlx4: Follow mirror sequence of device add during device removal
    
    [ Upstream commit 89f988d93c62384758b19323c886db917a80c371 ]
    
    Current code device add sequence is:
    
    ib_register_device()
    ib_mad_init()
    init_sriov_init()
    register_netdev_notifier()
    
    Therefore, the remove sequence should be,
    
    unregister_netdev_notifier()
    close_sriov()
    mad_cleanup()
    ib_unregister_device()
    
    However it is not above.
    Hence, make do above remove sequence.
    
    Fixes: fa417f7b520ee ("IB/mlx4: Add support for IBoE")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20191212091214.315005-3-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0f34320f4c1741596eb080592a49c609183c0e4
Author: Mark Zhang <markz@mellanox.com>
Date:   Thu Dec 12 11:12:12 2019 +0200

    RDMA/counter: Prevent auto-binding a QP which are not tracked with res
    
    [ Upstream commit 33df2f1929df4a1cb13303e344fbf8a75f0dc41f ]
    
    Some QPs (e.g. XRC QP) are not tracked in kernel, in this case they have
    an invalid res and should not be bound to any dynamically-allocated
    counter in auto mode.
    
    This fixes below call trace:
    BUG: kernel NULL pointer dereference, address: 0000000000000390
    PGD 80000001a7233067 P4D 80000001a7233067 PUD 1a7215067 PMD 0
    Oops: 0000 [#1] SMP PTI
    CPU: 2 PID: 24822 Comm: ibv_xsrq_pingpo Not tainted 5.4.0-rc5+ #21
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
    RIP: 0010:rdma_counter_bind_qp_auto+0x142/0x270 [ib_core]
    Code: e1 48 85 c0 48 89 c2 0f 84 bc 00 00 00 49 8b 06 48 39 42 48 75 d6 40 3a aa 90 00 00 00 75 cd 49 8b 86 00 01 00 00 48 8b 4a 28 <8b> 80 90 03 00 00 39 81 90 03 00 00 75 b4 85 c0 74 b0 48 8b 04 24
    RSP: 0018:ffffc900003f39c0 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
    RDX: ffff88820020ec00 RSI: 0000000000000004 RDI: ffffffffffffffc0
    RBP: 0000000000000001 R08: ffff888224149ff0 R09: ffffc900003f3968
    R10: ffffffffffffffff R11: ffff8882249c5848 R12: ffffffffffffffff
    R13: ffff88821d5aca50 R14: ffff8881f7690800 R15: ffff8881ff890000
    FS:  00007fe53a3e1740(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000390 CR3: 00000001a7292006 CR4: 00000000003606a0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     _ib_modify_qp+0x3a4/0x3f0 [ib_core]
     ? lookup_get_idr_uobject.part.8+0x23/0x40 [ib_uverbs]
     modify_qp+0x322/0x3e0 [ib_uverbs]
     ib_uverbs_modify_qp+0x43/0x70 [ib_uverbs]
     ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xb1/0xf0 [ib_uverbs]
     ib_uverbs_run_method+0x6be/0x760 [ib_uverbs]
     ? uverbs_disassociate_api+0xd0/0xd0 [ib_uverbs]
     ib_uverbs_cmd_verbs+0x18d/0x3a0 [ib_uverbs]
     ? get_acl+0x1a/0x120
     ? __alloc_pages_nodemask+0x15d/0x2c0
     ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs]
     do_vfs_ioctl+0xa5/0x610
     ksys_ioctl+0x60/0x90
     __x64_sys_ioctl+0x16/0x20
     do_syscall_64+0x48/0x110
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 99fa331dc862 ("RDMA/counter: Add "auto" configuration mode support")
    Signed-off-by: Mark Zhang <markz@mellanox.com>
    Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Ido Kalir <idok@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20191212091214.315005-2-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 217c8169c6aab357dc11041a0706ea46b6b3f2fb
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Fri Nov 29 15:24:25 2019 +0100

    s390/cpum_sf: Avoid SBD overflow condition in irq handler
    
    [ Upstream commit 0539ad0b22877225095d8adef0c376f52cc23834 ]
    
    The s390 CPU Measurement sampling facility has an overflow condition
    which fires when all entries in a SBD are used.
    The measurement alert interrupt is triggered and reads out all samples
    in this SDB. It then tests the successor SDB, if this SBD is not full,
    the interrupt handler does not read any samples at all from this SDB
    The design waits for the hardware to fill this SBD and then trigger
    another meassurement alert interrupt.
    
    This scheme works nicely until
    an perf_event_overflow() function call discards the sample due to
    a too high sampling rate.
    The interrupt handler has logic to read out a partially filled SDB
    when the perf event overflow condition in linux common code is met.
    This causes the CPUM sampling measurement hardware and the PMU
    device driver to operate on the same SBD's trailer entry.
    This should not happen.
    
    This can be seen here using this trace:
       cpumsf_pmu_add: tear:0xb5286000
       hw_perf_event_update: sdbt 0xb5286000 full 1 over 0 flush_all:0
       hw_perf_event_update: sdbt 0xb5286008 full 0 over 0 flush_all:0
            above shows 1. interrupt
       hw_perf_event_update: sdbt 0xb5286008 full 1 over 0 flush_all:0
       hw_perf_event_update: sdbt 0xb5286008 full 0 over 0 flush_all:0
            above shows 2. interrupt
            ... this goes on fine until...
       hw_perf_event_update: sdbt 0xb5286068 full 1 over 0 flush_all:0
       perf_push_sample1: overflow
          one or more samples read from the IRQ handler are rejected by
          perf_event_overflow() and the IRQ handler advances to the next SDB
          and modifies the trailer entry of a partially filled SDB.
       hw_perf_event_update: sdbt 0xb5286070 full 0 over 0 flush_all:1
          timestamp: 14:32:52.519953
    
    Next time the IRQ handler is called for this SDB the trailer entry shows
    an overflow count of 19 missed entries.
       hw_perf_event_update: sdbt 0xb5286070 full 1 over 19 flush_all:1
          timestamp: 14:32:52.970058
    
    Remove access to a follow on SDB when event overflow happened.
    
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c320bb692623aac4decbf6f2b1ce4cd340b9bb2
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Thu Nov 28 10:26:41 2019 +0100

    s390/cpum_sf: Adjust sampling interval to avoid hitting sample limits
    
    [ Upstream commit 39d4a501a9ef55c57b51e3ef07fc2aeed7f30b3b ]
    
    Function perf_event_ever_overflow() and perf_event_account_interrupt()
    are called every time samples are processed by the interrupt handler.
    However function perf_event_account_interrupt() has checks to avoid being
    flooded with interrupts (more then 1000 samples are received per
    task_tick).  Samples are then dropped and a PERF_RECORD_THROTTLED is
    added to the perf data. The perf subsystem limit calculation is:
    
        maximum sample frequency := 100000 --> 1 samples per 10 us
        task_tick = 10ms = 10000us --> 1000 samples per task_tick
    
    The work flow is
    
    measurement_alert() uses SDBT head and each SBDT points to 511
     SDB pages, each with 126 sample entries. After processing 8 SBDs
     and for each valid sample calling:
    
         perf_event_overflow()
           perf_event_account_interrupts()
    
    there is a considerable amount of samples being dropped, especially when
    the sample frequency is very high and near the 100000 limit.
    
    To avoid the high amount of samples being dropped near the end of a
    task_tick time frame, increment the sampling interval in case of
    dropped events. The CPU Measurement sampling facility on the s390
    supports only intervals, specifiing how many CPU cycles have to be
    executed before a sample is generated. Increase the interval when the
    samples being generated hit the task_tick limit.
    
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25432fa3ac169ea8200f7e9b55aa2407d4458f15
Author: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Date:   Tue Dec 10 10:42:25 2019 +0800

    md: raid1: check rdev before reference in raid1_sync_request func
    
    [ Upstream commit 028288df635f5a9addd48ac4677b720192747944 ]
    
    In raid1_sync_request func, rdev should be checked before reference.
    
    Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aae93615aa8ccdfd2752756e6d9a21c519ba6fe8
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Wed Nov 27 17:57:50 2019 +0100

    raid5: need to set STRIPE_HANDLE for batch head
    
    [ Upstream commit a7ede3d16808b8f3915c8572d783530a82b2f027 ]
    
    With commit 6ce220dd2f8ea71d6afc29b9a7524c12e39f374a ("raid5: don't set
    STRIPE_HANDLE to stripe which is in batch list"), we don't want to set
    STRIPE_HANDLE flag for sh which is already in batch list.
    
    However, the stripe which is the head of batch list should set this flag,
    otherwise panic could happen inside init_stripe at BUG_ON(sh->batch_head),
    it is reproducible with raid5 on top of nvdimm devices per Xiao oberserved.
    
    Thanks for Xiao's effort to verify the change.
    
    Fixes: 6ce220dd2f8ea ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list")
    Reported-by: Xiao Ni <xni@redhat.com>
    Tested-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57a21cdbec1a61c954d9682564cfe25955705eb6
Author: David Howells <dhowells@redhat.com>
Date:   Wed Dec 11 08:56:04 2019 +0000

    afs: Fix creation calls in the dynamic root to fail with EOPNOTSUPP
    
    [ Upstream commit 1da4bd9f9d187f53618890d7b66b9628bbec3c70 ]
    
    Fix the lookup method on the dynamic root directory such that creation
    calls, such as mkdir, open(O_CREAT), symlink, etc. fail with EOPNOTSUPP
    rather than failing with some odd error (such as EEXIST).
    
    lookup() itself tries to create automount directories when it is invoked.
    These are cached locally in RAM and not committed to storage.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Tested-by: Jonathan Billings <jsbillings@jsbillings.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4086478da1e75ce839db1f75fec9650d86b4e52
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 9 15:04:45 2019 +0000

    afs: Fix mountpoint parsing
    
    [ Upstream commit 158d58335393af3956a9c06f0816ee75ed1f1447 ]
    
    Each AFS mountpoint has strings that define the target to be mounted.  This
    is required to end in a dot that is supposed to be stripped off.  The
    string can include suffixes of ".readonly" or ".backup" - which are
    supposed to come before the terminal dot.  To add to the confusion, the "fs
    lsmount" afs utility does not show the terminal dot when displaying the
    string.
    
    The kernel mount source string parser, however, assumes that the terminal
    dot marks the suffix and that the suffix is always "" and is thus ignored.
    In most cases, there is no suffix and this is not a problem - but if there
    is a suffix, it is lost and this affects the ability to mount the correct
    volume.
    
    The command line mount command, on the other hand, is expected not to
    include a terminal dot - so the problem doesn't arise there.
    
    Fix this by making sure that the dot exists and then stripping it when
    passing the string to the mount configuration.
    
    Fixes: bec5eb614130 ("AFS: Implement an autocell mount capability [ver #2]")
    Reported-by: Jonathan Billings <jsbillings@jsbillings.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Tested-by: Jonathan Billings <jsbillings@jsbillings.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1954fda6b2799ca631f956917499933b876baae
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Dec 9 20:58:56 2019 -0700

    net: make socket read/write_iter() honor IOCB_NOWAIT
    
    [ Upstream commit ebfcd8955c0b52eb793bcbc9e71140e3d0cdb228 ]
    
    The socket read/write helpers only look at the file O_NONBLOCK. not
    the iocb IOCB_NOWAIT flag. This breaks users like preadv2/pwritev2
    and io_uring that rely on not having the file itself marked nonblocking,
    but rather the iocb itself.
    
    Cc: netdev@vger.kernel.org
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae6e5f8d5108326390a444f4e04ee5c5053e5543
Author: EJ Hsu <ejh@nvidia.com>
Date:   Tue Dec 3 23:34:56 2019 -0800

    usb: gadget: fix wrong endpoint desc
    
    [ Upstream commit e5b5da96da50ef30abb39cb9f694e99366404d24 ]
    
    Gadget driver should always use config_ep_by_speed() to initialize
    usb_ep struct according to usb device's operating speed. Otherwise,
    usb_ep struct may be wrong if usb devcie's operating speed is changed.
    
    The key point in this patch is that we want to make sure the desc pointer
    in usb_ep struct will be set to NULL when gadget is disconnected.
    This will force it to call config_ep_by_speed() to correctly initialize
    usb_ep struct based on the new operating speed when gadget is
    re-connected later.
    
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: EJ Hsu <ejh@nvidia.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f7cb06912f63c9f9585d694e77585008e1731db
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Dec 10 12:15:44 2019 +1000

    drm/nouveau/kms/nv50-: fix panel scaling
    
    [ Upstream commit 3d1890ef8023e61934e070021b06cc9f417260c0 ]
    
    Under certain circumstances, encoder atomic_check() can be entered
    without adjusted_mode having been reset to the same as mode, which
    confuses the scaling logic and can lead to a misprogrammed display.
    
    Fix this by checking against the user-provided mode directly.
    
    Link: https://bugs.freedesktop.org/show_bug.cgi?id=108615
    Link: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/464
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcfa071bfeaa54fec44d819305d877d7b8a14b3c
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 24 10:52:53 2019 +0200

    drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 hardware
    
    [ Upstream commit 64d17f25dcad518461ccf0c260544e1e379c5b35 ]
    
    We do not support atomic modesetting on pre-nv50 hardware, but until now
    our connector code was setting drm_connector->state on pre-nv50 hardware.
    
    This causes the core to enter atomic modesetting paths in at least:
    
    1. drm_connector_get_encoder(), returning connector->state->best_encoder
    which is always 0, causing us to always report 0 as encoder_id in
    the drmModeConnector struct returned by drmModeGetConnector().
    
    2. drm_encoder_get_crtc(), returning NULL because uses_atomic get set,
    causing us to always report 0 as crtc_id in the drmModeEncoder struct
    returned by drmModeGetEncoder()
    
    Which in turn confuses userspace, at least plymouth thinks that the pipe
    has changed because of this and tries to reconfigure it unnecessarily.
    
    More in general we should not set drm_connector->state in the non-atomic
    code as this violates the drm-core's expectations.
    
    This commit fixes this by using a nouveau_conn_atom struct embedded in the
    nouveau_connector struct for property handling in the non-atomic case.
    
    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1706557
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29da513a3300f54981a6fbef1dfcb7c37978d42f
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 24 10:52:52 2019 +0200

    drm/nouveau: Move the declaration of struct nouveau_conn_atom up a bit
    
    [ Upstream commit 37a68eab4cd92b507c9e8afd760fdc18e4fecac6 ]
    
    Place the declaration of struct nouveau_conn_atom above that of
    struct nouveau_connector. This commit makes no changes to the moved
    block what so ever, it just moves it up a bit.
    
    This is a preparation patch to fix some issues with connector handling
    on pre nv50 displays (which do not use atomic modesetting).
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 742d03aff89bd63f487219150c077fe446edeed2
Author: Kay Friedrich <kay.friedrich@fau.de>
Date:   Wed Nov 27 12:24:57 2019 +0100

    staging/wlan-ng: add CRC32 dependency in Kconfig
    
    [ Upstream commit 2740bd3351cd5a4351f458aabaa1c9b77de3867b ]
    
    wlan-ng uses the function crc32_le,
    but CRC32 wasn't a dependency of wlan-ng
    
    Co-developed-by: Michael Kupfer <michael.kupfer@fau.de>
    Signed-off-by: Michael Kupfer <michael.kupfer@fau.de>
    Signed-off-by: Kay Friedrich <kay.friedrich@fau.de>
    Link: https://lore.kernel.org/r/20191127112457.2301-1-kay.friedrich@fau.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d45a91713822e18f66348a10edea35f85dcef9ae
Author: Bo Wu <wubo40@huawei.com>
Date:   Wed Nov 20 13:26:17 2019 +0000

    scsi: iscsi: Avoid potential deadlock in iscsi_if_rx func
    
    [ Upstream commit bba340c79bfe3644829db5c852fdfa9e33837d6d ]
    
    In iscsi_if_rx func, after receiving one request through
    iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to
    reply to the request in a do-while loop.  If the iscsi_if_send_reply
    function keeps returning -EAGAIN, a deadlock will occur.
    
    For example, a client only send msg without calling recvmsg func, then
    it will result in the watchdog soft lockup.  The details are given as
    follows:
    
            sock_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ISCSI);
            retval = bind(sock_fd, (struct sock addr*) & src_addr, sizeof(src_addr);
            while (1) {
                    state_msg = sendmsg(sock_fd, &msg, 0);
                    //Note: recvmsg(sock_fd, &msg, 0) is not processed here.
            }
            close(sock_fd);
    
    watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [netlink_test:253305] Sample time: 4000897528 ns(HZ: 250) Sample stat:
    curr: user: 675503481560, nice: 321724050, sys: 448689506750, idle: 4654054240530, iowait: 40885550700, irq: 14161174020, softirq: 8104324140, st: 0
    deta: user: 0, nice: 0, sys: 3998210100, idle: 0, iowait: 0, irq: 1547170, softirq: 242870, st: 0 Sample softirq:
             TIMER:        992
             SCHED:          8
    Sample irqstat:
             irq    2: delta       1003, curr:    3103802, arch_timer
    CPU: 7 PID: 253305 Comm: netlink_test Kdump: loaded Tainted: G           OE
    Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
    pstate: 40400005 (nZcv daif +PAN -UAO)
    pc : __alloc_skb+0x104/0x1b0
    lr : __alloc_skb+0x9c/0x1b0
    sp : ffff000033603a30
    x29: ffff000033603a30 x28: 00000000000002dd
    x27: ffff800b34ced810 x26: ffff800ba7569f00
    x25: 00000000ffffffff x24: 0000000000000000
    x23: ffff800f7c43f600 x22: 0000000000480020
    x21: ffff0000091d9000 x20: ffff800b34eff200
    x19: ffff800ba7569f00 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000
    x15: 0000000000000000 x14: 0001000101000100
    x13: 0000000101010000 x12: 0101000001010100
    x11: 0001010101010001 x10: 00000000000002dd
    x9 : ffff000033603d58 x8 : ffff800b34eff400
    x7 : ffff800ba7569200 x6 : ffff800b34eff400
    x5 : 0000000000000000 x4 : 00000000ffffffff
    x3 : 0000000000000000 x2 : 0000000000000001
    x1 : ffff800b34eff2c0 x0 : 0000000000000300 Call trace:
    __alloc_skb+0x104/0x1b0
    iscsi_if_rx+0x144/0x12bc [scsi_transport_iscsi]
    netlink_unicast+0x1e0/0x258
    netlink_sendmsg+0x310/0x378
    sock_sendmsg+0x4c/0x70
    sock_write_iter+0x90/0xf0
    __vfs_write+0x11c/0x190
    vfs_write+0xac/0x1c0
    ksys_write+0x6c/0xd8
    __arm64_sys_write+0x24/0x30
    el0_svc_common+0x78/0x130
    el0_svc_handler+0x38/0x78
    el0_svc+0x8/0xc
    
    Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6915E3D4D2@dggeml505-mbx.china.huawei.com
    Signed-off-by: Bo Wu <wubo40@huawei.com>
    Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55c89290c7948e62ceac9eb3ffe6dd1555aa38d6
Author: Jason Yan <yanaijie@huawei.com>
Date:   Fri Dec 6 09:11:18 2019 +0800

    scsi: libsas: stop discovering if oob mode is disconnected
    
    [ Upstream commit f70267f379b5e5e11bdc5d72a56bf17e5feed01f ]
    
    The discovering of sas port is driven by workqueue in libsas. When libsas
    is processing port events or phy events in workqueue, new events may rise
    up and change the state of some structures such as asd_sas_phy.  This may
    cause some problems such as follows:
    
    ==>thread 1                       ==>thread 2
    
                                      ==>phy up
                                      ==>phy_up_v3_hw()
                                        ==>oob_mode = SATA_OOB_MODE;
                                      ==>phy down quickly
                                      ==>hisi_sas_phy_down()
                                        ==>sas_ha->notify_phy_event()
                                        ==>sas_phy_disconnected()
                                          ==>oob_mode = OOB_NOT_CONNECTED
    ==>workqueue wakeup
    ==>sas_form_port()
      ==>sas_discover_domain()
        ==>sas_get_port_device()
          ==>oob_mode is OOB_NOT_CONNECTED and device
             is wrongly taken as expander
    
    This at last lead to the panic when libsas trying to issue a command to
    discover the device.
    
    [183047.614035] Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000058
    [183047.622896] Mem abort info:
    [183047.625762]   ESR = 0x96000004
    [183047.628893]   Exception class = DABT (current EL), IL = 32 bits
    [183047.634888]   SET = 0, FnV = 0
    [183047.638015]   EA = 0, S1PTW = 0
    [183047.641232] Data abort info:
    [183047.644189]   ISV = 0, ISS = 0x00000004
    [183047.648100]   CM = 0, WnR = 0
    [183047.651145] user pgtable: 4k pages, 48-bit VAs, pgdp =
    00000000b7df67be
    [183047.657834] [0000000000000058] pgd=0000000000000000
    [183047.662789] Internal error: Oops: 96000004 [#1] SMP
    [183047.667740] Process kworker/u16:2 (pid: 31291, stack limit =
    0x00000000417c4974)
    [183047.675208] CPU: 0 PID: 3291 Comm: kworker/u16:2 Tainted: G
    W  OE 4.19.36-vhulk1907.1.0.h410.eulerosv2r8.aarch64 #1
    [183047.687015] Hardware name: N/A N/A/Kunpeng Desktop Board D920S10,
    BIOS 0.15 10/22/2019
    [183047.695007] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
    [183047.700999] pstate: 20c00009 (nzCv daif +PAN +UAO)
    [183047.705864] pc : prep_ata_v3_hw+0xf8/0x230 [hisi_sas_v3_hw]
    [183047.711510] lr : prep_ata_v3_hw+0xb0/0x230 [hisi_sas_v3_hw]
    [183047.717153] sp : ffff00000f28ba60
    [183047.720541] x29: ffff00000f28ba60 x28: ffff8026852d7228
    [183047.725925] x27: ffff8027dba3e0a8 x26: ffff8027c05fc200
    [183047.731310] x25: 0000000000000000 x24: ffff8026bafa8dc0
    [183047.736695] x23: ffff8027c05fc218 x22: ffff8026852d7228
    [183047.742079] x21: ffff80007c2f2940 x20: ffff8027c05fc200
    [183047.747464] x19: 0000000000f80800 x18: 0000000000000010
    [183047.752848] x17: 0000000000000000 x16: 0000000000000000
    [183047.758232] x15: ffff000089a5a4ff x14: 0000000000000005
    [183047.763617] x13: ffff000009a5a50e x12: ffff8026bafa1e20
    [183047.769001] x11: ffff0000087453b8 x10: ffff00000f28b870
    [183047.774385] x9 : 0000000000000000 x8 : ffff80007e58f9b0
    [183047.779770] x7 : 0000000000000000 x6 : 000000000000003f
    [183047.785154] x5 : 0000000000000040 x4 : ffffffffffffffe0
    [183047.790538] x3 : 00000000000000f8 x2 : 0000000002000007
    [183047.795922] x1 : 0000000000000008 x0 : 0000000000000000
    [183047.801307] Call trace:
    [183047.803827]  prep_ata_v3_hw+0xf8/0x230 [hisi_sas_v3_hw]
    [183047.809127]  hisi_sas_task_prep+0x750/0x888 [hisi_sas_main]
    [183047.814773]  hisi_sas_task_exec.isra.7+0x88/0x1f0 [hisi_sas_main]
    [183047.820939]  hisi_sas_queue_command+0x28/0x38 [hisi_sas_main]
    [183047.826757]  smp_execute_task_sg+0xec/0x218
    [183047.831013]  smp_execute_task+0x74/0xa0
    [183047.834921]  sas_discover_expander.part.7+0x9c/0x5f8
    [183047.839959]  sas_discover_root_expander+0x90/0x160
    [183047.844822]  sas_discover_domain+0x1b8/0x1e8
    [183047.849164]  process_one_work+0x1b4/0x3f8
    [183047.853246]  worker_thread+0x54/0x470
    [183047.856981]  kthread+0x134/0x138
    [183047.860283]  ret_from_fork+0x10/0x18
    [183047.863931] Code: f9407a80 528000e2 39409281 72a04002 (b9405800)
    [183047.870097] kernel fault(0x1) notification starting on CPU 0
    [183047.875828] kernel fault(0x1) notification finished on CPU 0
    [183047.881559] Modules linked in: unibsp(OE) hns3(OE) hclge(OE)
    hnae3(OE) mem_drv(OE) hisi_sas_v3_hw(OE) hisi_sas_main(OE)
    [183047.892418] ---[ end trace 4cc26083fc11b783  ]---
    [183047.897107] Kernel panic - not syncing: Fatal exception
    [183047.902403] kernel fault(0x5) notification starting on CPU 0
    [183047.908134] kernel fault(0x5) notification finished on CPU 0
    [183047.913865] SMP: stopping secondary CPUs
    [183047.917861] Kernel Offset: disabled
    [183047.921422] CPU features: 0x2,a2a00a38
    [183047.925243] Memory Limit: none
    [183047.928372] kernel reboot(0x2) notification starting on CPU 0
    [183047.934190] kernel reboot(0x2) notification finished on CPU 0
    [183047.940008] ---[ end Kernel panic - not syncing: Fatal exception
    ]---
    
    Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
    Link: https://lore.kernel.org/r/20191206011118.46909-1-yanaijie@huawei.com
    Reported-by: Gao Chuan <gaochuan4@huawei.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Jason Yan <yanaijie@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 505eead5e56938501cf8a76b34128b0780c0dc8f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Dec 3 12:45:09 2019 +0300

    scsi: iscsi: qla4xxx: fix double free in probe
    
    [ Upstream commit fee92f25777789d73e1936b91472e9c4644457c8 ]
    
    On this error path we call qla4xxx_mem_free() and then the caller also
    calls qla4xxx_free_adapter() which calls qla4xxx_mem_free().  It leads to a
    couple double frees:
    
    drivers/scsi/qla4xxx/ql4_os.c:8856 qla4xxx_probe_adapter() warn: 'ha->chap_dma_pool' double freed
    drivers/scsi/qla4xxx/ql4_os.c:8856 qla4xxx_probe_adapter() warn: 'ha->fw_ddb_dma_pool' double freed
    
    Fixes: afaf5a2d341d ("[SCSI] Initial Commit of qla4xxx")
    Link: https://lore.kernel.org/r/20191203094421.hw7ex7qr3j2rbsmx@kili.mountain
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68204b46da46b8fae902285557fd9d7c524d9f18
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:57:01 2019 +0300

    scsi: qla2xxx: Ignore PORT UPDATE after N2N PLOGI
    
    [ Upstream commit af22f0c7b052c5c203207f1e5ebd6aa65f87c538 ]
    
    PORT UPDATE asynchronous event is generated on the host that issues PLOGI
    ELS (in the case of higher WWPN). In that case, the event shouldn't be
    handled as it sets unwanted DPC flags (i.e. LOOP_RESYNC_NEEDED) that
    trigger link flap.
    
    Ignore the event if the host has higher WWPN, but handle otherwise.
    
    Cc: Quinn Tran <qutran@marvell.com>
    Link: https://lore.kernel.org/r/20191125165702.1013-13-r.bolshakov@yadro.com
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7497032b17a8fb5e3e8eff05dc4e601a619bdfe4
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:57:00 2019 +0300

    scsi: qla2xxx: Don't defer relogin unconditonally
    
    [ Upstream commit dabc5ec915f3a2c657ecfb529cd3d4ec303a4412 ]
    
    qla2x00_configure_local_loop sets RELOGIN_NEEDED bit and calls
    qla24xx_fcport_handle_login to perform the login. This bit triggers a wake
    up of DPC later after a successful login.
    
    The deferred call is not needed if login succeeds, and it's set in
    qla24xx_fcport_handle_login in case of errors, hence it should be safe to
    drop.
    
    Link: https://lore.kernel.org/r/20191125165702.1013-12-r.bolshakov@yadro.com
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Acked-by: Quinn Tran <qutran@marvell.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 944e01086e0ef71771ce6db05d046621e1768b42
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:56:59 2019 +0300

    scsi: qla2xxx: Send Notify ACK after N2N PLOGI
    
    [ Upstream commit 5e6b01d84b9d20bcd77fc7c4733a2a4149bf220a ]
    
    qlt_handle_login schedules session for deletion even if a login is in
    progress. That causes login bouncing, i.e. a few logins are made before it
    settles down.
    
    Complete the first login by sending Notify Acknowledge IOCB via
    qlt_plogi_ack_unref if the session is pending login completion.
    
    Fixes: 9cd883f07a54 ("scsi: qla2xxx: Fix session cleanup for N2N")
    Cc: Krishna Kant <krishna.kant@purestorage.com>
    Cc: Alexei Potashnik <alexei@purestorage.com>
    Link: https://lore.kernel.org/r/20191125165702.1013-11-r.bolshakov@yadro.com
    Acked-by: Quinn Tran <qutran@marvell.com>
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 610ab9d567f8d6b9c8879029aeb90097f628ee0e
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:56:58 2019 +0300

    scsi: qla2xxx: Configure local loop for N2N target
    
    [ Upstream commit fd1de5830a5abaf444cc4312871e02c41e24fdc1 ]
    
    qla2x00_configure_local_loop initializes PLOGI payload for PLOGI ELS using
    Get Parameters mailbox command.
    
    In the case when the driver is running in target mode, the topology is N2N
    and the target port has higher WWPN, LOCAL_LOOP_UPDATE bit is cleared too
    early and PLOGI payload is not initialized by the Get Parameters
    command. That causes a failure of ELS IOCB carrying the PLOGI with 0x15 aka
    Data Underrun error.
    
    LOCAL_LOOP_UPDATE has to be set to initialize PLOGI payload.
    
    Fixes: 48acad099074 ("scsi: qla2xxx: Fix N2N link re-connect")
    Link: https://lore.kernel.org/r/20191125165702.1013-10-r.bolshakov@yadro.com
    Acked-by: Quinn Tran <qutran@marvell.com>
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97345ea931e5fbd2a082c972109ef90e4a0f6f3a
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:56:57 2019 +0300

    scsi: qla2xxx: Fix PLOGI payload and ELS IOCB dump length
    
    [ Upstream commit 0334cdea1fba36fad8bdf9516f267ce01de625f7 ]
    
    The size of the buffer is hardcoded as 0x70 or 112 bytes, while the size of
    ELS IOCB is 0x40 and the size of PLOGI payload returned by Get Parameters
    command is 0x74.
    
    Cc: Quinn Tran <qutran@marvell.com>
    Link: https://lore.kernel.org/r/20191125165702.1013-9-r.bolshakov@yadro.com
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e56964da84f9f5100d148f050df2d538aa3b57c
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:56:56 2019 +0300

    scsi: qla2xxx: Don't call qlt_async_event twice
    
    [ Upstream commit 2c2f4bed9b6299e6430a65a29b5d27b8763fdf25 ]
    
    MBA_PORT_UPDATE generates duplicate log lines in target mode because
    qlt_async_event is called twice. Drop the calls within the case as the
    function will be called right after the switch statement.
    
    Cc: Quinn Tran <qutran@marvell.com>
    Link: https://lore.kernel.org/r/20191125165702.1013-8-r.bolshakov@yadro.com
    Acked-by: Himanshu Madhani <hmadhani@marvel.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ad67d0ec1442cf643ba9fe34cf081a0fab5284d
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date:   Mon Nov 25 19:56:53 2019 +0300

    scsi: qla2xxx: Drop superfluous INIT_WORK of del_work
    
    [ Upstream commit 600954e6f2df695434887dfc6a99a098859990cf ]
    
    del_work is already initialized inside qla2x00_alloc_fcport, there's no
    need to overwrite it. Indeed, it might prevent complete traversal of
    workqueue list.
    
    Fixes: a01c77d2cbc45 ("scsi: qla2xxx: Move session delete to driver work queue")
    Cc: Quinn Tran <qutran@marvell.com>
    Link: https://lore.kernel.org/r/20191125165702.1013-5-r.bolshakov@yadro.com
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99a1bdf6ae39501f5678c29bff6cb80906227519
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Nov 25 19:56:51 2019 +0300

    scsi: qla2xxx: Use explicit LOGO in target mode
    
    [ Upstream commit 86196a8fa8a84af1395a28ea0548f2ce6ae9bc22 ]
    
    Target makes implicit LOGO on session teardown. LOGO ELS is not send on the
    wire and initiator is not aware that target no longer wants talking to
    it. Initiator keeps sending I/O requests, target responds with BA_RJT, they
    time out and then initiator sends ABORT TASK (ABTS-LS).
    
    Current behaviour incurs unneeded I/O timeout and can be fixed for some
    initiators by making explicit LOGO on session deletion.
    
    Link: https://lore.kernel.org/r/20191125165702.1013-3-r.bolshakov@yadro.com
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f327fb083c6836c8bbad077305bb74b848d901db
Author: Bo Wu <wubo40@huawei.com>
Date:   Sat Dec 7 03:22:46 2019 +0000

    scsi: lpfc: Fix memory leak on lpfc_bsg_write_ebuf_set func
    
    [ Upstream commit 9a1b0b9a6dab452fb0e39fe96880c4faf3878369 ]
    
    When phba->mbox_ext_buf_ctx.seqNum != phba->mbox_ext_buf_ctx.numBuf,
    dd_data should be freed before return SLI_CONFIG_HANDLED.
    
    When lpfc_sli_issue_mbox func return fails, pmboxq should be also freed in
    job_error tag.
    
    Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6915E7A966@DGGEML525-MBS.china.huawei.com
    Signed-off-by: Bo Wu <wubo40@huawei.com>
    Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Reviewed-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aff98343bd9a59dc64b9335197d58152636badb8
Author: Steve Wise <larrystevenwise@gmail.com>
Date:   Mon Dec 2 20:03:20 2019 -0600

    rxe: correctly calculate iCRC for unaligned payloads
    
    [ Upstream commit 2030abddec6884aaf5892f5724c48fc340e6826f ]
    
    If RoCE PDUs being sent or received contain pad bytes, then the iCRC
    is miscalculated, resulting in PDUs being emitted by RXE with an incorrect
    iCRC, as well as ingress PDUs being dropped due to erroneously detecting
    a bad iCRC in the PDU.  The fix is to include the pad bytes, if any,
    in iCRC computations.
    
    Note: This bug has caused broken on-the-wire compatibility with actual
    hardware RoCE devices since the soft-RoCE driver was first put into the
    mainstream kernel.  Fixing it will create an incompatibility with the
    original soft-RoCE devices, but is necessary to be compatible with real
    hardware devices.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Signed-off-by: Steve Wise <larrystevenwise@gmail.com>
    Link: https://lore.kernel.org/r/20191203020319.15036-2-larrystevenwise@gmail.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 438e26506d39bbd71604e16ebab92ac718aff5a4
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Fri Dec 6 09:24:26 2019 +0800

    RDMA/cma: add missed unregister_pernet_subsys in init failure
    
    [ Upstream commit 44a7b6759000ac51b92715579a7bba9e3f9245c2 ]
    
    The driver forgets to call unregister_pernet_subsys() in the error path
    of cma_init().
    Add the missed call to fix it.
    
    Fixes: 4be74b42a6d0 ("IB/cma: Separate port allocation to network namespaces")
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Reviewed-by: Parav Pandit <parav@mellanox.com>
    Link: https://lore.kernel.org/r/20191206012426.12744-1-hslester96@gmail.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec81b123abbf31bb48070e336082de2d30074c82
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 9 15:04:45 2019 +0000

    afs: Fix SELinux setting security label on /afs
    
    [ Upstream commit bcbccaf2edcf1b76f73f890e968babef446151a4 ]
    
    Make the AFS dynamic root superblock R/W so that SELinux can set the
    security label on it.  Without this, upgrades to, say, the Fedora
    filesystem-afs RPM fail if afs is mounted on it because the SELinux label
    can't be (re-)applied.
    
    It might be better to make it possible to bypass the R/O check for LSM
    label application through setxattr.
    
    Fixes: 4d673da14533 ("afs: Support the AFS dynamic root")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: selinux@vger.kernel.org
    cc: linux-security-module@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79ce91d278498c3445a8d7007fa4dca82148edce
Author: Marc Dionne <marc.dionne@auristor.com>
Date:   Mon Dec 9 15:04:43 2019 +0000

    afs: Fix afs_find_server lookups for ipv4 peers
    
    [ Upstream commit 9bd0160d12370a076e44f8d1320cde9c83f2c647 ]
    
    afs_find_server tries to find a server that has an address that
    matches the transport address of an rxrpc peer.  The code assumes
    that the transport address is always ipv6, with ipv4 represented
    as ipv4 mapped addresses, but that's not the case.  If the transport
    family is AF_INET, srx->transport.sin6.sin6_addr.s6_addr32[] will
    be beyond the actual ipv4 address and will always be 0, and all
    ipv4 addresses will be seen as matching.
    
    As a result, the first ipv4 address seen on any server will be
    considered a match, and the server returned may be the wrong one.
    
    One of the consequences is that callbacks received over ipv4 will
    only be correctly applied for the server that happens to have the
    first ipv4 address on the fs_addresses4 list.  Callbacks over ipv4
    from all other servers are dropped, causing the client to serve stale
    data.
    
    This is fixed by looking at the transport family, and comparing ipv4
    addresses based on a sockaddr_in structure rather than a sockaddr_in6.
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33191a1bd6327e20b074dae2d9f997543092f485
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Thu Nov 14 01:21:31 2019 +0200

    PM / devfreq: Don't fail devfreq_dev_release if not in list
    
    [ Upstream commit 42a6b25e67df6ee6675e8d1eaf18065bd73328ba ]
    
    Right now devfreq_dev_release will print a warning and abort the rest of
    the cleanup if the devfreq instance is not part of the global
    devfreq_list. But this is a valid scenario, for example it can happen if
    the governor can't be found or on any other init error that happens
    after device_register.
    
    Initialize devfreq->node to an empty list head in devfreq_add_device so
    that list_del becomes a safe noop inside devfreq_dev_release and we can
    continue the rest of the cleanup.
    
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43894f3ae380f18e206d2dd496633fbe5f0a6806
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Thu Oct 31 23:34:19 2019 +0200

    PM / devfreq: Set scaling_max_freq to max on OPP notifier error
    
    [ Upstream commit e7cc792d00049c874010b398a27c3cc7bc8fef34 ]
    
    The devfreq_notifier_call functions will update scaling_min_freq and
    scaling_max_freq when the OPP table is updated.
    
    If fetching the maximum frequency fails then scaling_max_freq remains
    set to zero which is confusing. Set to ULONG_MAX instead so we don't
    need special handling for this case in other places.
    
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eae25dfc30249cf540a045365587a32e6bc9ca6a
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Thu Oct 31 23:34:18 2019 +0200

    PM / devfreq: Fix devfreq_notifier_call returning errno
    
    [ Upstream commit e876e710ede23f670494331e062d643928e4142a ]
    
    Notifier callbacks shouldn't return negative errno but one of the
    NOTIFY_OK/DONE/BAD values.
    
    The OPP core will ignore return values from notifiers but returning a
    value that matches NOTIFY_STOP_MASK will stop the notification chain.
    
    Fix by always returning NOTIFY_OK.
    
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8db2bb9681b5c426b0fe2d3fde505ba779cf00aa
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Dec 2 09:55:46 2019 +0100

    iio: adc: max9611: Fix too short conversion time delay
    
    [ Upstream commit 9fd229c478fbf77c41c8528aa757ef14210365f6 ]
    
    As of commit b9ddd5091160793e ("iio: adc: max9611: Fix temperature
    reading in probe"), max9611 initialization sometimes fails on the
    Salvator-X(S) development board with:
    
        max9611 4-007f: Invalid value received from ADC 0x8000: aborting
        max9611: probe of 4-007f failed with error -5
    
    The max9611 driver tests communications with the chip by reading the die
    temperature during the probe function, which returns an invalid value.
    
    According to the datasheet, the typical ADC conversion time is 2 ms, but
    no minimum or maximum values are provided.  Maxim Technical Support
    confirmed this was tested with temperature Ta=25 degreeC, and promised
    to inform me if a maximum/minimum value is available (they didn't get
    back to me, so I assume it is not).
    
    However, the driver assumes a 1 ms conversion time.  Usually the
    usleep_range() call returns after more than 1.8 ms, hence it succeeds.
    When it returns earlier, the data register may be read too early, and
    the previous measurement value will be returned.  After boot, this is
    the temperature POR (power-on reset) value, causing the failure above.
    
    Fix this by increasing the delay from 1000-2000 µs to 3000-3300 µs.
    
    Note that this issue has always been present, but it was exposed by the
    aformentioned commit.
    
    Fixes: 69780a3bbc0b1e7e ("iio: adc: Add Maxim max9611 ADC driver")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7a667db91266dba9c868618e8020aa19daf0b7d
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon Nov 11 11:21:15 2019 +0800

    iio: st_accel: Fix unused variable warning
    
    [ Upstream commit 0163c1c521ff8b09cd8ca395003cc00178161d77 ]
    
    drivers/iio/accel/st_accel_core.c:1005:44: warning:
     mount_matrix_ext_info defined but not used [-Wunused-const-variable=]
    
    Using stub helper while CONFIG_ACPI is disabled to fix it.
    
    Suggested-by: Ladislav Michl <ladis@linux-mips.org>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a6cec43ba680a20d6ec94d35dee625be3d486c8
Author: Keith Busch <kbusch@kernel.org>
Date:   Fri Dec 6 08:11:17 2019 +0900

    nvme/pci: Fix read queue count
    
    [ Upstream commit 7e4c6b9a5d22485acf009b3c3510a370f096dd54 ]
    
    If nvme.write_queues equals the number of CPUs, the driver had decreased
    the number of interrupts available such that there could only be one read
    queue even if the controller could support more. Remove the interrupt
    count reduction in this case. The driver wouldn't request more IRQs than
    it wants queues anyway.
    
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29cfb7940e63b314f4842a3d12e219c056dccacf
Author: Keith Busch <kbusch@kernel.org>
Date:   Sat Dec 7 01:51:54 2019 +0900

    nvme/pci: Fix write and poll queue types
    
    [ Upstream commit 3f68baf706ec68c4120867c25bc439c845fe3e17 ]
    
    The number of poll or write queues should never be negative. Use unsigned
    types so that it's not possible to break have the driver not allocate
    any queues.
    
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7376dbde76af6c3ca7e905b56f0cef1e395a6ad1
Author: Eric Yang <Eric.Yang2@amd.com>
Date:   Fri Nov 15 12:04:25 2019 -0500

    drm/amd/display: update dispclk and dppclk vco frequency
    
    [ Upstream commit 44ce6c3dc8479bb3ed68df13b502b0901675e7d6 ]
    
    Value obtained from DV is not allowing 8k60 CTA mode with DSC to
    pass, after checking real value being used in hw, find out that
    correct value is 3600, which will allow that mode.
    
    Signed-off-by: Eric Yang <Eric.Yang2@amd.com>
    Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit baa4cd587a100318d0657eab94b87cb46128aabd
Author: Nikola Cornij <nikola.cornij@amd.com>
Date:   Mon Nov 11 18:03:59 2019 -0500

    drm/amd/display: Reset steer fifo before unblanking the stream
    
    [ Upstream commit 87de6cb2f28153bc74d0a001ca099c29453e145f ]
    
    [why]
    During mode transition steer fifo could overflow. Quite often it
    recovers by itself, but sometimes it doesn't.
    
    [how]
    Add steer fifo reset before unblanking the stream. Also add a short
    delay when resetting dig resync fifo to make sure register writes
    don't end up back-to-back, in which case the HW might miss the reset
    request.
    
    Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
    Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d950e9dc11dd38a64d91bdc57ae051ffdb907980
Author: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Date:   Thu Nov 7 16:30:04 2019 -0500

    drm/amd/display: Change the delay time before enabling FEC
    
    [ Upstream commit 28fa24ad14e8f7d23c62283eaf9c79b4fd165c16 ]
    
    [why]
    DP spec requires 1000 symbols delay between the end of link training
    and enabling FEC in the stream. Currently we are using 1 miliseconds
    delay which is not accurate.
    
    [how]
    One lane RBR should have the maximum time for transmitting 1000 LL
    codes which is 6.173 us. So using 7 microseconds delay instead of
    1 miliseconds.
    
    Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
    Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
    Reviewed-by: Nikola Cornij <Nikola.Cornij@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3abd3c9d993be875d205d25a904468c31f7e81a
Author: David Galiffi <David.Galiffi@amd.com>
Date:   Thu Nov 7 17:18:20 2019 -0500

    drm/amd/display: Fixed kernel panic when booting with DP-to-HDMI dongle
    
    [ Upstream commit a51d9f8fe756beac51ce26ef54195da00a260d13 ]
    
    [Why]
    In dc_link_is_dp_sink_present, if dal_ddc_open fails, then
    dal_gpio_destroy_ddc is called, destroying pin_data and pin_clock. They
    are created only on dc_construct, and next aux access will cause a panic.
    
    [How]
    Instead of calling dal_gpio_destroy_ddc, call dal_ddc_close.
    
    Signed-off-by: David Galiffi <David.Galiffi@amd.com>
    Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 225a3070cf4dfd16686dd2f2eca7512c4e758ca2
Author: Nikola Cornij <nikola.cornij@amd.com>
Date:   Thu Nov 7 13:06:48 2019 -0500

    drm/amd/display: Map DSC resources 1-to-1 if numbers of OPPs and DSCs are equal
    
    [ Upstream commit a1fc44b609b4e9c0941f0e4a1fc69d367af5ab69 ]
    
    [why]
    On ASICs where number of DSCs is the same as OPPs there's no need
    for DSC resource management. Mappping 1-to-1 fixes mode-set- or S3-
    -related issues for such platforms.
    
    [how]
    Map DSC resources 1-to-1 to pipes only if number of OPPs is the same
    as number of DSCs. This will still keep other ASICs working.
    A follow-up patch to fix mode-set issues on those ASICs will be
    required if testing shows issues with mode set.
    
    Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
    Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 361d1d13fd2b41a785ba7c688f85778d62a8b115
Author: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Date:   Thu Nov 28 12:08:58 2019 +0100

    drm/amdgpu: add cache flush workaround to gfx8 emit_fence
    
    [ Upstream commit bf26da927a1cd57c9deb2db29ae8cf276ba8b17b ]
    
    The same workaround is used for gfx7.
    Both PAL and Mesa use it for gfx8 too, so port this commit to
    gfx_v8_0_ring_emit_fence_gfx.
    
    Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8caa4267a222d3c46289662253b66d15e603627
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Dec 4 22:07:49 2019 -0500

    drm/amdgpu: add header line for power profile on Arcturus
    
    [ Upstream commit 14891c316ca7e15d81dba78f30fb630e3f9ee2c9 ]
    
    So the output is consistent with other asics.
    
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 731a0f0d0d50ae2b8a8e4ffe65923c05e616cd4f
Author: Guchun Chen <guchun.chen@amd.com>
Date:   Wed Dec 4 15:51:16 2019 +0800

    drm/amdgpu: add check before enabling/disabling broadcast mode
    
    [ Upstream commit 6e807535dae5dbbd53bcc5e81047a20bf5eb08ea ]
    
    When security violation from new vbios happens, data fabric is
    risky to stop working. So prevent the direct access to DF
    mmFabricConfigAccessControl from the new vbios and onwards.
    
    Signed-off-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afde69ecda83083ac3267571e7d09ca63f36be28
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Nov 21 09:59:37 2019 -0800

    nvme-fc: fix double-free scenarios on hw queues
    
    [ Upstream commit c869e494ef8b5846d9ba91f1e922c23cd444f0c1 ]
    
    If an error occurs on one of the ios used for creating an
    association, the creating routine has error paths that are
    invoked by the command failure and the error paths will free
    up the controller resources created to that point.
    
    But... the io was ultimately determined by an asynchronous
    completion routine that detected the error and which
    unconditionally invokes the error_recovery path which calls
    delete_association. Delete association deletes all outstanding
    io then tears down the controller resources. So the
    create_association thread can be running in parallel with
    the error_recovery thread. What was seen was the LLDD received
    a call to delete a queue, causing the LLDD to do a free of a
    resource, then the transport called the delete queue again
    causing the driver to repeat the free call. The second free
    routine corrupted the allocator. The transport shouldn't be
    making the duplicate call, and the delete queue is just one
    of the resources being freed.
    
    To fix, it is realized that the create_association path is
    completely serialized with one command at a time. So the
    failed io completion will always be seen by the create_association
    path and as of the failure, there are no ios to terminate and there
    is no reason to be manipulating queue freeze states, etc.
    The serialized condition stays true until the controller is
    transitioned to the LIVE state. Thus the fix is to change the
    error recovery path to check the controller state and only
    invoke the teardown path if not already in the CONNECTING state.
    
    Reviewed-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b49a5a9eb46ffa3b07ad14fe62e117a09787cae
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Nov 14 15:15:26 2019 -0800

    nvme_fc: add module to ops template to allow module references
    
    [ Upstream commit 863fbae929c7a5b64e96b8a3ffb34a29eefb9f8f ]
    
    In nvme-fc: it's possible to have connected active controllers
    and as no references are taken on the LLDD, the LLDD can be
    unloaded.  The controller would enter a reconnect state and as
    long as the LLDD resumed within the reconnect timeout, the
    controller would resume.  But if a namespace on the controller
    is the root device, allowing the driver to unload can be problematic.
    To reload the driver, it may require new io to the boot device,
    and as it's no longer connected we get into a catch-22 that
    eventually fails, and the system locks up.
    
    Fix this issue by taking a module reference for every connected
    controller (which is what the core layer did to the transport
    module). Reference is cleared when the controller is removed.
    
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8fe0af636c54074c293b8c553e05614420e91e3
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon Nov 18 14:02:52 2019 +0100

    drm/mcde: dsi: Fix invalid pointer dereference if panel cannot be found
    
    [ Upstream commit c131280c03bd1c225c2e64e9ef75873ffca3d96e ]
    
    The "panel" pointer is not reset to NULL if of_drm_find_panel()
    returns an error. Therefore we later assume that a panel was found,
    and try to dereference the error pointer, resulting in:
    
        mcde-dsi a0351000.dsi: failed to find panel try bridge (4294966779)
        Unable to handle kernel paging request at virtual address fffffe03
        PC is at drm_panel_bridge_add.part.0+0x10/0x5c
        LR is at mcde_dsi_bind+0x120/0x464
        ...
    
    Reset "panel" to NULL to avoid this problem.
    Also change the format string of the error to %ld to print
    the negative errors correctly. The crash above then becomes:
    
        mcde-dsi a0351000.dsi: failed to find panel try bridge (-517)
        mcde-dsi a0351000.dsi: no panel or bridge
        ...
    
    Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191118130252.170324-1-stephan@gerhold.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>