commit cb1f9a169a0e197f93816ace48a6520e8640809d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 9 10:19:10 2020 +0100

    Linux 4.19.94

commit 78880475f7006b2143848f9b680be0a38a6e9f0c
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 87d43527edf0e2ebd5ed8c86ac35d395a1a8b5b0
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 a5011c7890314eedd491e1ebcd0b58a629cae751
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 7764ed0b7274a0c34db53170c7b77915bdf5501a
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 bc5fc4a6099ee46ebc7f4e75f03fd716ee558f87
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 58a4661896d2017c09df2fc8127013fd5cd11c23
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 6dc835dbe6a2ea9e79893ac1e5e5f00f4b92287a
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 f10bcc6bddd98d391024a248b9f6b4425fcfdb32
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 a2e065542a7568e62f6174bb0991cf71f5688b30
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Oct 21 18:47:50 2019 +0000

    net: core: limit nested device depth
    
    [ Upstream commit 5343da4c17429efaa5fb1594ea96aee1a283e694 ]
    
    Current code doesn't limit the number of nested devices.
    Nested devices would be handled recursively and this needs huge stack
    memory. So, unlimited nested devices could make stack overflow.
    
    This patch adds upper_level and lower_level, they are common variables
    and represent maximum lower/upper depth.
    When upper/lower device is attached or dettached,
    {lower/upper}_level are updated. and if maximum depth is bigger than 8,
    attach routine fails and returns -EMLINK.
    
    In addition, this patch converts recursive routine of
    netdev_walk_all_{lower/upper} to iterator routine.
    
    Test commands:
        ip link add dummy0 type dummy
        ip link add link dummy0 name vlan1 type vlan id 1
        ip link set vlan1 up
    
        for i in {2..55}
        do
                let A=$i-1
    
                ip link add vlan$i link vlan$A type vlan id $i
        done
        ip link del dummy0
    
    Splat looks like:
    [  155.513226][  T908] BUG: KASAN: use-after-free in __unwind_start+0x71/0x850
    [  155.514162][  T908] Write of size 88 at addr ffff8880608a6cc0 by task ip/908
    [  155.515048][  T908]
    [  155.515333][  T908] CPU: 0 PID: 908 Comm: ip Not tainted 5.4.0-rc3+ #96
    [  155.516147][  T908] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    [  155.517233][  T908] Call Trace:
    [  155.517627][  T908]
    [  155.517918][  T908] Allocated by task 0:
    [  155.518412][  T908] (stack is not available)
    [  155.518955][  T908]
    [  155.519228][  T908] Freed by task 0:
    [  155.519885][  T908] (stack is not available)
    [  155.520452][  T908]
    [  155.520729][  T908] The buggy address belongs to the object at ffff8880608a6ac0
    [  155.520729][  T908]  which belongs to the cache names_cache of size 4096
    [  155.522387][  T908] The buggy address is located 512 bytes inside of
    [  155.522387][  T908]  4096-byte region [ffff8880608a6ac0, ffff8880608a7ac0)
    [  155.523920][  T908] The buggy address belongs to the page:
    [  155.524552][  T908] page:ffffea0001822800 refcount:1 mapcount:0 mapping:ffff88806c657cc0 index:0x0 compound_mapcount:0
    [  155.525836][  T908] flags: 0x100000000010200(slab|head)
    [  155.526445][  T908] raw: 0100000000010200 ffffea0001813808 ffffea0001a26c08 ffff88806c657cc0
    [  155.527424][  T908] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
    [  155.528429][  T908] page dumped because: kasan: bad access detected
    [  155.529158][  T908]
    [  155.529410][  T908] Memory state around the buggy address:
    [  155.530060][  T908]  ffff8880608a6b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  155.530971][  T908]  ffff8880608a6c00: fb fb fb fb fb f1 f1 f1 f1 00 f2 f2 f2 f3 f3 f3
    [  155.531889][  T908] >ffff8880608a6c80: f3 fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  155.532806][  T908]                                            ^
    [  155.533509][  T908]  ffff8880608a6d00: fb fb fb fb fb fb fb fb fb f1 f1 f1 f1 00 00 00
    [  155.534436][  T908]  ffff8880608a6d80: f2 f3 f3 f3 f3 fb fb fb 00 00 00 00 00 00 00 00
    [ ... ]
    
    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 67f028acac5f380464ea73cf57a62dd09fd16722
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 10 20:17:39 2019 -0700

    tcp: annotate tp->rcv_nxt lockless reads
    
    [ Upstream commit dba7d9b8c739df27ff3a234c81d6c6b23e3986fa ]
    
    There are few places where we fetch tp->rcv_nxt while
    this field can change from IRQ or other cpu.
    
    We need to add READ_ONCE() annotations, and also make
    sure write sides use corresponding WRITE_ONCE() to avoid
    store-tearing.
    
    Note that tcp_inq_hint() was already using READ_ONCE(tp->rcv_nxt)
    
    syzbot reported :
    
    BUG: KCSAN: data-race in tcp_poll / tcp_queue_rcv
    
    write to 0xffff888120425770 of 4 bytes by interrupt on cpu 0:
     tcp_rcv_nxt_update net/ipv4/tcp_input.c:3365 [inline]
     tcp_queue_rcv+0x180/0x380 net/ipv4/tcp_input.c:4638
     tcp_rcv_established+0xbf1/0xf50 net/ipv4/tcp_input.c:5616
     tcp_v4_do_rcv+0x381/0x4e0 net/ipv4/tcp_ipv4.c:1542
     tcp_v4_rcv+0x1a03/0x1bf0 net/ipv4/tcp_ipv4.c:1923
     ip_protocol_deliver_rcu+0x51/0x470 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:5004
     __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118
     netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208
     napi_skb_finish net/core/dev.c:5671 [inline]
     napi_gro_receive+0x28f/0x330 net/core/dev.c:5704
     receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
    
    read to 0xffff888120425770 of 4 bytes by task 7254 on cpu 1:
     tcp_stream_is_readable net/ipv4/tcp.c:480 [inline]
     tcp_poll+0x204/0x6b0 net/ipv4/tcp.c:554
     sock_poll+0xed/0x250 net/socket.c:1256
     vfs_poll include/linux/poll.h:90 [inline]
     ep_item_poll.isra.0+0x90/0x190 fs/eventpoll.c:892
     ep_send_events_proc+0x113/0x5c0 fs/eventpoll.c:1749
     ep_scan_ready_list.constprop.0+0x189/0x500 fs/eventpoll.c:704
     ep_send_events fs/eventpoll.c:1793 [inline]
     ep_poll+0xe3/0x900 fs/eventpoll.c:1930
     do_epoll_wait+0x162/0x180 fs/eventpoll.c:2294
     __do_sys_epoll_pwait fs/eventpoll.c:2325 [inline]
     __se_sys_epoll_pwait fs/eventpoll.c:2311 [inline]
     __x64_sys_epoll_pwait+0xcd/0x170 fs/eventpoll.c:2311
     do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 7254 Comm: syz-fuzzer Not tainted 5.3.0+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    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 d9f4d60a233607aa148e7414173fbed21a0eaa8f
Author: David Howells <dhowells@redhat.com>
Date:   Thu Oct 10 15:52:34 2019 +0100

    rxrpc: Fix possible NULL pointer access in ICMP handling
    
    [ Upstream commit f0308fb0708078d6c1d8a4d533941a7a191af634 ]
    
    If an ICMP packet comes in on the UDP socket backing an AF_RXRPC socket as
    the UDP socket is being shut down, rxrpc_error_report() may get called to
    deal with it after sk_user_data on the UDP socket has been cleared, leading
    to a NULL pointer access when this local endpoint record gets accessed.
    
    Fix this by just returning immediately if sk_user_data was NULL.
    
    The oops looks like the following:
    
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    ...
    RIP: 0010:rxrpc_error_report+0x1bd/0x6a9
    ...
    Call Trace:
     ? sock_queue_err_skb+0xbd/0xde
     ? __udp4_lib_err+0x313/0x34d
     __udp4_lib_err+0x313/0x34d
     icmp_unreach+0x1ee/0x207
     icmp_rcv+0x25b/0x28f
     ip_protocol_deliver_rcu+0x95/0x10e
     ip_local_deliver+0xe9/0x148
     __netif_receive_skb_one_core+0x52/0x6e
     process_backlog+0xdc/0x177
     net_rx_action+0xf9/0x270
     __do_softirq+0x1b6/0x39a
     ? smpboot_register_percpu_thread+0xce/0xce
     run_ksoftirqd+0x1d/0x42
     smpboot_thread_fn+0x19e/0x1b3
     kthread+0xf1/0xf6
     ? kthread_delayed_work_timer_fn+0x83/0x83
     ret_from_fork+0x24/0x30
    
    Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
    Reported-by: syzbot+611164843bd48cc2190c@syzkaller.appspotmail.com
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2118e6e0dc0e7401eb8b5739a78301d1a63523b
Author: Michael Roth <mdroth@linux.vnet.ibm.com>
Date:   Wed Sep 11 17:31:55 2019 -0500

    KVM: PPC: Book3S HV: use smp_mb() when setting/clearing host_ipi flag
    
    [ Upstream commit 3a83f677a6eeff65751b29e3648d7c69c3be83f3 ]
    
    On a 2-socket Power9 system with 32 cores/128 threads (SMT4) and 1TB
    of memory running the following guest configs:
    
      guest A:
        - 224GB of memory
        - 56 VCPUs (sockets=1,cores=28,threads=2), where:
          VCPUs 0-1 are pinned to CPUs 0-3,
          VCPUs 2-3 are pinned to CPUs 4-7,
          ...
          VCPUs 54-55 are pinned to CPUs 108-111
    
      guest B:
        - 4GB of memory
        - 4 VCPUs (sockets=1,cores=4,threads=1)
    
    with the following workloads (with KSM and THP enabled in all):
    
      guest A:
        stress --cpu 40 --io 20 --vm 20 --vm-bytes 512M
    
      guest B:
        stress --cpu 4 --io 4 --vm 4 --vm-bytes 512M
    
      host:
        stress --cpu 4 --io 4 --vm 2 --vm-bytes 256M
    
    the below soft-lockup traces were observed after an hour or so and
    persisted until the host was reset (this was found to be reliably
    reproducible for this configuration, for kernels 4.15, 4.18, 5.0,
    and 5.3-rc5):
    
      [ 1253.183290] rcu: INFO: rcu_sched self-detected stall on CPU
      [ 1253.183319] rcu:     124-....: (5250 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=1941
      [ 1256.287426] watchdog: BUG: soft lockup - CPU#105 stuck for 23s! [CPU 52/KVM:19709]
      [ 1264.075773] watchdog: BUG: soft lockup - CPU#24 stuck for 23s! [worker:19913]
      [ 1264.079769] watchdog: BUG: soft lockup - CPU#31 stuck for 23s! [worker:20331]
      [ 1264.095770] watchdog: BUG: soft lockup - CPU#45 stuck for 23s! [worker:20338]
      [ 1264.131773] watchdog: BUG: soft lockup - CPU#64 stuck for 23s! [avocado:19525]
      [ 1280.408480] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
      [ 1316.198012] rcu: INFO: rcu_sched self-detected stall on CPU
      [ 1316.198032] rcu:     124-....: (21003 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=8243
      [ 1340.411024] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
      [ 1379.212609] rcu: INFO: rcu_sched self-detected stall on CPU
      [ 1379.212629] rcu:     124-....: (36756 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=14714
      [ 1404.413615] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
      [ 1442.227095] rcu: INFO: rcu_sched self-detected stall on CPU
      [ 1442.227115] rcu:     124-....: (52509 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=21403
      [ 1455.111787] INFO: task worker:19907 blocked for more than 120 seconds.
      [ 1455.111822]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.111833] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.111884] INFO: task worker:19908 blocked for more than 120 seconds.
      [ 1455.111905]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.111925] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.111966] INFO: task worker:20328 blocked for more than 120 seconds.
      [ 1455.111986]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.111998] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.112048] INFO: task worker:20330 blocked for more than 120 seconds.
      [ 1455.112068]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.112097] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.112138] INFO: task worker:20332 blocked for more than 120 seconds.
      [ 1455.112159]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.112179] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.112210] INFO: task worker:20333 blocked for more than 120 seconds.
      [ 1455.112231]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.112242] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.112282] INFO: task worker:20335 blocked for more than 120 seconds.
      [ 1455.112303]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
      [ 1455.112332] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1455.112372] INFO: task worker:20336 blocked for more than 120 seconds.
      [ 1455.112392]       Tainted: G             L    5.3.0-rc5-mdr-vanilla+ #1
    
    CPUs 45, 24, and 124 are stuck on spin locks, likely held by
    CPUs 105 and 31.
    
    CPUs 105 and 31 are stuck in smp_call_function_many(), waiting on
    target CPU 42. For instance:
    
      # CPU 105 registers (via xmon)
      R00 = c00000000020b20c   R16 = 00007d1bcd800000
      R01 = c00000363eaa7970   R17 = 0000000000000001
      R02 = c0000000019b3a00   R18 = 000000000000006b
      R03 = 000000000000002a   R19 = 00007d537d7aecf0
      R04 = 000000000000002a   R20 = 60000000000000e0
      R05 = 000000000000002a   R21 = 0801000000000080
      R06 = c0002073fb0caa08   R22 = 0000000000000d60
      R07 = c0000000019ddd78   R23 = 0000000000000001
      R08 = 000000000000002a   R24 = c00000000147a700
      R09 = 0000000000000001   R25 = c0002073fb0ca908
      R10 = c000008ffeb4e660   R26 = 0000000000000000
      R11 = c0002073fb0ca900   R27 = c0000000019e2464
      R12 = c000000000050790   R28 = c0000000000812b0
      R13 = c000207fff623e00   R29 = c0002073fb0ca808
      R14 = 00007d1bbee00000   R30 = c0002073fb0ca800
      R15 = 00007d1bcd600000   R31 = 0000000000000800
      pc  = c00000000020b260 smp_call_function_many+0x3d0/0x460
      cfar= c00000000020b270 smp_call_function_many+0x3e0/0x460
      lr  = c00000000020b20c smp_call_function_many+0x37c/0x460
      msr = 900000010288b033   cr  = 44024824
      ctr = c000000000050790   xer = 0000000000000000   trap =  100
    
    CPU 42 is running normally, doing VCPU work:
    
      # CPU 42 stack trace (via xmon)
      [link register   ] c00800001be17188 kvmppc_book3s_radix_page_fault+0x90/0x2b0 [kvm_hv]
      [c000008ed3343820] c000008ed3343850 (unreliable)
      [c000008ed33438d0] c00800001be11b6c kvmppc_book3s_hv_page_fault+0x264/0xe30 [kvm_hv]
      [c000008ed33439d0] c00800001be0d7b4 kvmppc_vcpu_run_hv+0x8dc/0xb50 [kvm_hv]
      [c000008ed3343ae0] c00800001c10891c kvmppc_vcpu_run+0x34/0x48 [kvm]
      [c000008ed3343b00] c00800001c10475c kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
      [c000008ed3343b90] c00800001c0f5a78 kvm_vcpu_ioctl+0x470/0x7c8 [kvm]
      [c000008ed3343d00] c000000000475450 do_vfs_ioctl+0xe0/0xc70
      [c000008ed3343db0] c0000000004760e4 ksys_ioctl+0x104/0x120
      [c000008ed3343e00] c000000000476128 sys_ioctl+0x28/0x80
      [c000008ed3343e20] c00000000000b388 system_call+0x5c/0x70
      --- Exception: c00 (System Call) at 00007d545cfd7694
      SP (7d53ff7edf50) is in userspace
    
    It was subsequently found that ipi_message[PPC_MSG_CALL_FUNCTION]
    was set for CPU 42 by at least 1 of the CPUs waiting in
    smp_call_function_many(), but somehow the corresponding
    call_single_queue entries were never processed by CPU 42, causing the
    callers to spin in csd_lock_wait() indefinitely.
    
    Nick Piggin suggested something similar to the following sequence as
    a possible explanation (interleaving of CALL_FUNCTION/RESCHEDULE
    IPI messages seems to be most common, but any mix of CALL_FUNCTION and
    !CALL_FUNCTION messages could trigger it):
    
        CPU
          X: smp_muxed_ipi_set_message():
          X:   smp_mb()
          X:   message[RESCHEDULE] = 1
          X: doorbell_global_ipi(42):
          X:   kvmppc_set_host_ipi(42, 1)
          X:   ppc_msgsnd_sync()/smp_mb()
          X:   ppc_msgsnd() -> 42
         42: doorbell_exception(): // from CPU X
         42:   ppc_msgsync()
        105: smp_muxed_ipi_set_message():
        105:   smb_mb()
             // STORE DEFERRED DUE TO RE-ORDERING
      --105:   message[CALL_FUNCTION] = 1
      | 105: doorbell_global_ipi(42):
      | 105:   kvmppc_set_host_ipi(42, 1)
      |  42:   kvmppc_set_host_ipi(42, 0)
      |  42: smp_ipi_demux_relaxed()
      |  42: // returns to executing guest
      |      // RE-ORDERED STORE COMPLETES
      ->105:   message[CALL_FUNCTION] = 1
        105:   ppc_msgsnd_sync()/smp_mb()
        105:   ppc_msgsnd() -> 42
         42: local_paca->kvm_hstate.host_ipi == 0 // IPI ignored
        105: // hangs waiting on 42 to process messages/call_single_queue
    
    This can be prevented with an smp_mb() at the beginning of
    kvmppc_set_host_ipi(), such that stores to message[<type>] (or other
    state indicated by the host_ipi flag) are ordered vs. the store to
    to host_ipi.
    
    However, doing so might still allow for the following scenario (not
    yet observed):
    
        CPU
          X: smp_muxed_ipi_set_message():
          X:   smp_mb()
          X:   message[RESCHEDULE] = 1
          X: doorbell_global_ipi(42):
          X:   kvmppc_set_host_ipi(42, 1)
          X:   ppc_msgsnd_sync()/smp_mb()
          X:   ppc_msgsnd() -> 42
         42: doorbell_exception(): // from CPU X
         42:   ppc_msgsync()
             // STORE DEFERRED DUE TO RE-ORDERING
      -- 42:   kvmppc_set_host_ipi(42, 0)
      |  42: smp_ipi_demux_relaxed()
      | 105: smp_muxed_ipi_set_message():
      | 105:   smb_mb()
      | 105:   message[CALL_FUNCTION] = 1
      | 105: doorbell_global_ipi(42):
      | 105:   kvmppc_set_host_ipi(42, 1)
      |      // RE-ORDERED STORE COMPLETES
      -> 42:   kvmppc_set_host_ipi(42, 0)
         42: // returns to executing guest
        105:   ppc_msgsnd_sync()/smp_mb()
        105:   ppc_msgsnd() -> 42
         42: local_paca->kvm_hstate.host_ipi == 0 // IPI ignored
        105: // hangs waiting on 42 to process messages/call_single_queue
    
    Fixing this scenario would require an smp_mb() *after* clearing
    host_ipi flag in kvmppc_set_host_ipi() to order the store vs.
    subsequent processing of IPI messages.
    
    To handle both cases, this patch splits kvmppc_set_host_ipi() into
    separate set/clear functions, where we execute smp_mb() prior to
    setting host_ipi flag, and after clearing host_ipi flag. These
    functions pair with each other to synchronize the sender and receiver
    sides.
    
    With that change in place the above workload ran for 20 hours without
    triggering any lock-ups.
    
    Fixes: 755563bc79c7 ("powerpc/powernv: Fixes for hypervisor doorbell handling") # v4.0
    Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
    Acked-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20190911223155.16045-1-mdroth@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 107726ad0479655d84e020ef077fbf9310d3f4f2
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Jun 17 16:02:28 2019 +0200

    selftests: rtnetlink: add addresses with fixed life time
    
    [ Upstream commit 3cfa148826e3c666da1cc2a43fbe8689e2650636 ]
    
    This exercises kernel code path that deal with addresses that have
    a limited lifetime.
    
    Without previous fix, this triggers following crash on net-next:
     BUG: KASAN: null-ptr-deref in check_lifetime+0x403/0x670
     Read of size 8 at addr 0000000000000010 by task kworker [..]
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d14b83e71b233b32166ebf55fce7821135742c4
Author: Daniel Axtens <dja@axtens.net>
Date:   Mon Jun 3 16:56:57 2019 +1000

    powerpc/pseries/hvconsole: Fix stack overread via udbg
    
    [ Upstream commit 934bda59f286d0221f1a3ebab7f5156a996cc37d ]
    
    While developing KASAN for 64-bit book3s, I hit the following stack
    over-read.
    
    It occurs because the hypercall to put characters onto the terminal
    takes 2 longs (128 bits/16 bytes) of characters at a time, and so
    hvc_put_chars() would unconditionally copy 16 bytes from the argument
    buffer, regardless of supplied length. However, udbg_hvc_putc() can
    call hvc_put_chars() with a single-byte buffer, leading to the error.
    
      ==================================================================
      BUG: KASAN: stack-out-of-bounds in hvc_put_chars+0xdc/0x110
      Read of size 8 at addr c0000000023e7a90 by task swapper/0
    
      CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.0-rc2-next-20190528-02824-g048a6ab4835b #113
      Call Trace:
        dump_stack+0x104/0x154 (unreliable)
        print_address_description+0xa0/0x30c
        __kasan_report+0x20c/0x224
        kasan_report+0x18/0x30
        __asan_report_load8_noabort+0x24/0x40
        hvc_put_chars+0xdc/0x110
        hvterm_raw_put_chars+0x9c/0x110
        udbg_hvc_putc+0x154/0x200
        udbg_write+0xf0/0x240
        console_unlock+0x868/0xd30
        register_console+0x970/0xe90
        register_early_udbg_console+0xf8/0x114
        setup_arch+0x108/0x790
        start_kernel+0x104/0x784
        start_here_common+0x1c/0x534
    
      Memory state around the buggy address:
       c0000000023e7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       c0000000023e7a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
      >c0000000023e7a80: f1 f1 01 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
                               ^
       c0000000023e7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       c0000000023e7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
    
    Document that a 16-byte buffer is requred, and provide it in udbg.
    
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efa13b328e6a0138b1d5d9655c0f00a1dcb17bcd
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri May 24 00:24:33 2019 +0300

    drm/mst: Fix MST sideband up-reply failure handling
    
    [ Upstream commit d8fd3722207f154b53c80eee2cf4977c3fc25a92 ]
    
    Fix the breakage resulting in the stacktrace below, due to tx queue
    being full when trying to send an up-reply. txmsg->seqno is -1 in this
    case leading to a corruption of the mstb object by
    
            txmsg->dst->tx_slots[txmsg->seqno] = NULL;
    
    in process_single_up_tx_qlock().
    
    [  +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]] set_hdr_from_dst_qlock: failed to find slot
    [  +0,000015] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]] failed to send msg in q -11
    [  +0,000939] BUG: kernel NULL pointer dereference, address: 00000000000005a0
    [  +0,006982] #PF: supervisor write access in kernel mode
    [  +0,005223] #PF: error_code(0x0002) - not-present page
    [  +0,005135] PGD 0 P4D 0
    [  +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
    [  +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted: G     U            5.2.0-rc1+ #410
    [  +0,008433] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 04/26/2019
    [  +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
    [  +0,005676] RIP: 0010:queue_work_on+0x19/0x70
    [  +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 <f0> 48 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
    [  +0,018750] RSP: 0018:ffffc900007dfc50 EFLAGS: 00010006
    [  +0,005222] RAX: 0000000000000046 RBX: 00000000000005a0 RCX: 0000000000000001
    [  +0,007133] RDX: 000000000001b608 RSI: 0000000000000000 RDI: ffffffff82121972
    [  +0,007129] RBP: 0000000000000202 R08: 0000000000000000 R09: 0000000000000001
    [  +0,007129] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88847bfa5096
    [  +0,007131] R13: 0000000000000010 R14: ffff88849c08f3f8 R15: 0000000000000000
    [  +0,007128] FS:  0000000000000000(0000) GS:ffff88849dc80000(0000) knlGS:0000000000000000
    [  +0,008083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  +0,005749] CR2: 00000000000005a0 CR3: 0000000005210006 CR4: 0000000000760ee0
    [  +0,007128] PKRU: 55555554
    [  +0,002722] Call Trace:
    [  +0,002458]  drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
    [  +0,006197]  ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
    [  +0,005764]  drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
    [  +0,005623]  ? intel_dp_hpd_pulse+0x205/0x370 [i915]
    [  +0,005018]  intel_dp_hpd_pulse+0x205/0x370 [i915]
    [  +0,004836]  i915_digport_work_func+0xbb/0x140 [i915]
    [  +0,005108]  process_one_work+0x245/0x610
    [  +0,004027]  worker_thread+0x37/0x380
    [  +0,003684]  ? process_one_work+0x610/0x610
    [  +0,004184]  kthread+0x119/0x130
    [  +0,003240]  ? kthread_park+0x80/0x80
    [  +0,003668]  ret_from_fork+0x24/0x50
    
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190523212433.9058-1-imre.deak@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 359a3d6fc2829e114375331b319f0601b7cc5196
Author: Chad Dupuis <cdupuis@marvell.com>
Date:   Tue Mar 26 00:38:33 2019 -0700

    scsi: qedf: Do not retry ELS request if qedf_alloc_cmd fails
    
    [ Upstream commit f1c43590365bac054d753d808dbbd207d09e088d ]
    
    If we cannot allocate an ELS middlepath request, simply fail instead of
    trying to delay and then reallocate.  This delay logic is causing soft
    lockup messages:
    
    NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:1:7639]
    Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter dm_service_time vfat fat rpcrdma sunrpc ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm
    irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support qedr(OE) ib_core joydev ipmi_ssif pcspkr hpilo hpwdt sg ipmi_si ipmi_devintf ipmi_msghandler ioatdma shpchp lpc_ich wmi dca acpi_power_meter dm_multipath ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic qedf(OE) libfcoe mgag200 libfc i2c_algo_bit drm_kms_helper scsi_transport_fc qede(OE) syscopyarea sysfillrect sysimgblt fb_sys_fops ttm qed(OE) drm crct10dif_pclmul e1000e crct10dif_common crc32c_intel scsi_tgt hpsa i2c_core ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod
    CPU: 2 PID: 7639 Comm: kworker/2:1 Kdump: loaded Tainted: G           OEL ------------   3.10.0-861.el7.x86_64 #1
    Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 07/21/2016
    Workqueue: qedf_2_dpc qedf_handle_rrq [qedf]
    task: ffff959edd628fd0 ti: ffff959ed6f08000 task.ti: ffff959ed6f08000
    RIP: 0010:[<ffffffff8355913a>]  [<ffffffff8355913a>] delay_tsc+0x3a/0x60
    RSP: 0018:ffff959ed6f0bd30  EFLAGS: 00000246
    RAX: 000000008ef5f791 RBX: 5f646d635f666465 RCX: 0000025b8ededa2f
    RDX: 000000000000025b RSI: 0000000000000002 RDI: 0000000000217d1e
    RBP: ffff959ed6f0bd30 R08: ffffffffc079aae8 R09: 0000000000000200
    R10: ffffffffc07952c6 R11: 0000000000000000 R12: 6c6c615f66646571
    R13: ffff959ed6f0bcc8 R14: ffff959ed6f0bd08 R15: ffff959e00000028
    FS:  0000000000000000(0000) GS:ffff959eff480000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f4117fa1eb0 CR3: 0000002039e66000 CR4: 00000000003607e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    [<ffffffff8355907d>] __const_udelay+0x2d/0x30
    [<ffffffffc079444a>] qedf_initiate_els+0x13a/0x450 [qedf]
    [<ffffffffc0794210>] ? qedf_srr_compl+0x2a0/0x2a0 [qedf]
    [<ffffffffc0795337>] qedf_send_rrq+0x127/0x230 [qedf]
    [<ffffffffc078ed55>] qedf_handle_rrq+0x15/0x20 [qedf]
    [<ffffffff832b2dff>] process_one_work+0x17f/0x440
    [<ffffffff832b3ac6>] worker_thread+0x126/0x3c0
    [<ffffffff832b39a0>] ? manage_workers.isra.24+0x2a0/0x2a0
    [<ffffffff832bae31>] kthread+0xd1/0xe0
    [<ffffffff832bad60>] ? insert_kthread_work+0x40/0x40
    [<ffffffff8391f637>] ret_from_fork_nospec_begin+0x21/0x21
    [<ffffffff832bad60>] ? insert_kthread_work+0x40/0x40
    
    Signed-off-by: Chad Dupuis <cdupuis@marvell.com>
    Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a06ee0d2ff92af03f12675d0969ba2de0e98f27d
Author: Jan Kara <jack@suse.cz>
Date:   Mon Oct 21 10:38:00 2019 +0200

    bdev: Refresh bdev size for disks without partitioning
    
    commit cba22d86e0a10b7070d2e6a7379dbea51aa0883c upstream.
    
    Currently, block device size in not updated on second and further open
    for block devices where partition scan is disabled. This is particularly
    annoying for example for DVD drives as that means block device size does
    not get updated once the media is inserted into a drive if the device is
    already open when inserting the media. This is actually always the case
    for example when pktcdvd is in use.
    
    Fix the problem by revalidating block device size on every open even for
    devices with partition scan disabled.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a5b5131487b65d68f3c46a6217d6fb5baaf631b
Author: Jan Kara <jack@suse.cz>
Date:   Mon Oct 21 10:37:59 2019 +0200

    bdev: Factor out bdev revalidation into a common helper
    
    commit 731dc4868311ee097757b8746eaa1b4f8b2b4f1c upstream.
    
    Factor out code handling revalidation of bdev on disk change into a
    common helper.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e7dd198aa84fec3906e725a0f76617699175c7f
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 2db81976ca1121df8c0c8ad1f95b6af6c529149a
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 679d4ed5ea02773d8885b9bb36187549bd5dff3f
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 f6aa433c8f3b85f81863a18df432189e75e73dd2
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 d933de8115f3263fd50cf3b1f1dac2faff02fd89
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 50b55230ed93fca1872b09d347a12900288c8ed4
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 51ebfce1170eb784b344fca2c9ce6346eeabbcc8
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 dfde3147c6a705b663175c0545efc34929a55ee5
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 cf223ff1a2a55143c8fb5abe440fcbb2e2ffb0f4
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 a0a5f3d36b04d53acb351e898adced3f199d79ec
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 b1ecf978fadf406b5ab3cecc08cffe8feb194980
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 e1ceceb494825f3df0f17182b112caf4635bf923
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 dba77370ad88dda246741fadfa0fba6b7bad1bae
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 9d8338627207e29436e0751f67ab4ee48ec18196
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 58f7525f62ef576ab769bfd3a8e3d733ba75ca9b
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 ac57e1605822ec7dd23e3ad5a3a2719168b32c69
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 062ec830fd7610d369f0dc138f830a179f52da0c
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 010a7e846d4beaf34384c40ff18d5de10106d9b4
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 d89a351b082e52c44e1c6537c7ef75fd8c901bde
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 b9227aacdc14d8eae8ee0148543ed6310be678da
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 aa94893fdbb8a860276366fcb9bfb8a4a4c7f8af
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 8f093a2152ca2943d0e50febd891478e816e7c20
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 f3248d6dce684a98641bd69e14a5efc8dc4b4593
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 1c662483c563edd63c302c372ec774686b39a925
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 0c815959304bee255034c8ba9f3668a1ae380f86
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 8595e2aaddd8c35db02aa2f35eab8e04d8b0f39d
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 0e48d030e3326c03697db617cb09e53ef291bbec
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 349e05e9c9b3f80302e513e37ba56ca1441dd32e
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 ac8e28a9b2ffa4667bfe1b1d2712d0bb8954bee8
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 316a9a84dbaf628b74d30fd3e1a5dac739e125ed
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 c89e7917a2144f97d30255ed9e62d23bba7555c9
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 07c0735e85397f5f7efc18dc21be03aab8ba8ee2
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 12567657a7dd9101945d772b8d261695d4e0885e
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 46a746f026bca14de7cd3552551724e66210698c
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Mon Oct 1 10:33:00 2018 -0700

    ata: ahci_brcm: Allow optional reset controller to be used
    
    commit 2b2c47d9e1fe90311b725125d6252a859ee87a79 upstream.
    
    On BCM63138, we need to reset the AHCI core prior to start utilizing it,
    grab the reset controller device cookie and do that.
    
    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 d6d821712bf7ac3ebf09b33983b405aa4af3e00f
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 4ccf3f6f80ddc94eb88a2195dba44d30e14d9a03
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 a95d032abe875b7323c1698a64a7fa7aee157d4c
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 fc982b8fbd1022886534393dc71eaff08b659350
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 2f7db098b1e267ec37212bc713766cbb7471d9d5
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 0211f27ac1df13e3f670ac84232719a2f8930bfc
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 903065d53f2df8c9253b64ed51aff4e87e5495e2
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 146a44da6e23ca0ddebb92011b78faf688436ad5
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 3b677f75434a27aa1b71b79d30d028681a80d71c
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 b9fffe57eaaa8a1b03a8bd5be74d6a7607d74c68
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 d8961949a27bc0496d6aadd3a15d92ef58bb6a90
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 cdcf9c99212e4d8b89101f2492963db5b3d0463e
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 ffbcee5097adf4f5029f0c44e45bce96148180c7
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 76373a85c19abb9c3cc42ec845a352ba75bb63fe
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 9b8a065de9a5dc5b1bbf2f7df8f2b2ee6084dd73
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 a128928262499b0ec39ff8b7abbc4cca2e527549
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 973f2e4389123aaf90b969de90308ba1ba308a26
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 9884a8d03973c70b193f6ef0e59816424c140209
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 70986b20f631c497414a4a840b818d61ff70fc8e
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 fb6b15324d2ff8910c096424f1b78e709e542c63
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 da7504b07cc266dc60225a07900f730310da3de7
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 85b1e127aa577f7035b998b8c712bb6a36f02b14
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 4 16:52:37 2019 -0800

    drm: limit to INT_MAX in create_blob ioctl
    
    [ Upstream commit 5bf8bec3f4ce044a223c40cbce92590d938f0e9c ]
    
    The hardened usercpy code is too paranoid ever since commit 6a30afa8c1fb
    ("uaccess: disallow > INT_MAX copy sizes")
    
    Code itself should have been fine as-is.
    
    Link: http://lkml.kernel.org/r/20191106164755.31478-1-daniel.vetter@ffwll.ch
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Reported-by: syzbot+fb77e97ebf0612ee6914@syzkaller.appspotmail.com
    Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes")
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    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 95c4742b1f00b4c64af224552af58d290d3fa26d
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 d47137ce79f92acf9e7eea5bb1341c458b2dfc10
Author: Brian Foster <bfoster@redhat.com>
Date:   Tue Dec 3 07:53:15 2019 -0800

    xfs: fix mount failure crash on invalid iclog memory access
    
    [ Upstream commit 798a9cada4694ca8d970259f216cec47e675bfd5 ]
    
    syzbot (via KASAN) reports a use-after-free in the error path of
    xlog_alloc_log(). Specifically, the iclog freeing loop doesn't
    handle the case of a fully initialized ->l_iclog linked list.
    Instead, it assumes that the list is partially constructed and NULL
    terminated.
    
    This bug manifested because there was no possible error scenario
    after iclog list setup when the original code was added.  Subsequent
    code and associated error conditions were added some time later,
    while the original error handling code was never updated. Fix up the
    error loop to terminate either on a NULL iclog or reaching the end
    of the list.
    
    Reported-by: syzbot+c732f8644185de340492@syzkaller.appspotmail.com
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e465e1b4ea2e87d011cfd2c3215f2ce425a9004
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 af38a3e7d298c28aecb4796e3819191f4920deff
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 09361acd5ca1c220de33c01947ce867daf6a6e82
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 76548ddc1b7e2e86da2ac054937904466de89c68
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 71d955cdbbc4df078a5d4175156cf66d05f91b24
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 240d1a8b7d965bf54be1d00e310d572e25db364d
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 d66e67b62ef0a9f860d929a31e16e37cb27bfe3f
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 d93412f23423a21c829ba603c7a92e53be1a492f
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 fbf01d59bcf8778c4fd14276b6d9334f53472fa4
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 25fb38550cb1119807f31b8030ed3de02c927a4d
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 ec322d9884f4d111f663dccb894c3826de00fdf8
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 281c1b305274851ae9304345a0f47c2670eb73d2
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 b280f0ea1c8332a1dc10542064d2f2e934ccf7e0
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 9d5b54cfe0afe4e5de2f27dc6213a49a509f4e2a
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 60dee18d2ce454b3bdefc6494b593b4296ef1c5c
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 8b9bf467061bc89ccf4a43be637e08d8a70fd76d
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 9e46af40e4d585180efbf3fdd9a4b1286dba70d3
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 b8ca74b9ff68ff3ca13e5d1889944a5871d41e81
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 b0cb3b4889775d7c9fef9d835e171f6e93c5494f
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 ec00e0e02b8041d979e8916fbd4b64d20318a697
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 0ef1cf777a4428650c3176a910bb3e97cb558785
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 b6a21efb23dd0d962125a55ea026e76bfb3dbebb
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 afda7bde3c45ae6ca546add50512835b7a7c09dd
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 b57221a273aeb1e44b4bda540f1052cd999d0267
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 71427eda272bdff856d2c9db9abf0302b2577f49
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 e295e82a43045f85a6eda1b2668c47c916f0092d
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 0d0940a9b099a58c1b4fcc9bd5925fbfd6b84705
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 4075bd35bc32f9766a8ec74681f8b0eabaf577bb
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 6c3986b6b55267381de378792277d6d48c141429
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 56f1c5108d674776bb493383ede28005edf41104
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 6b2c3bb311f3e7f90ede18adad0f5c153f67517b
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 346812c25f75b145942ef034542974c6da977afe
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 12fefecbcb4dfefd62995fd0e4cf8f30edd64926
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 a073ae477701fd19e73e4285199cfc419ebd94b8
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 3517664ad07ce796d786082b1f890fcad5e7af47
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 25d87eebc7125c2f764e57834bee7db4d5790ccb
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 6c786e656cd9d46d4d54f2afa824dae7721607b4
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>