commit 4f0eaca39dd14d3492f6bbdd02b9657a180e6c03
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Feb 11 20:03:59 2020 +0000

    Linux 3.16.82

commit 3617d0109265dd2f070cc4b358b7588ddb1af343
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Feb 6 15:17:16 2020 +0000

    s390: Fix unmatched preempt_disable() on exit
    
    exit_thread_runtime_instr() may return with preemption disabled,
    leading to the following lockdep splat:
    
    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
    in_atomic(): 1, irqs_disabled(): 0, pid: 565, name: kworker/u2:0
    no locks held by kworker/u2:0/565.
    CPU: 0 PID: 565 Comm: kworker/u2:0 Not tainted 3.16.81-00145-gafe1c874fa44 #1
           00000000025dbbd8 00000000025dbbe8 0000000000000002 0000000000000000
           00000000025dbc78 00000000025dbbf0 00000000025dbbf0 000000000098c55c
           0000000000000000 00000000025d05b8 00000000025d1590 0000000000000000
           0000000000000000 000000000000000c 00000000025dbbd8 0000000000000070
           00000000009b7220 000000000098c55c 00000000025dbbd8 00000000025dbc20
    Call Trace:
    ([<000000000098c4ce>] show_trace+0xb6/0xd8)
     [<000000000098c592>] show_stack+0xa2/0xd8
     [<0000000000992c04>] dump_stack+0xc4/0x118
     [<0000000000191e20>] __might_sleep+0x230/0x238
     [<000000000099fbb0>] mutex_lock_nested+0x48/0x3d8
     [<000000000025e33e>] perf_event_exit_task+0x36/0x398
     [<0000000000158536>] do_exit+0x3ae/0xca0
     [<0000000000175826>] ____call_usermodehelper+0x136/0x148
     [<00000000009a550a>] kernel_thread_starter+0x6/0xc
     [<00000000009a5504>] kernel_thread_starter+0x0/0xc
    
    This was fixed by commit 8d9047f8b967 "s390/runtime instrumentation:
    simplify task exit handling" upstream, but that won't apply here.
    
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ce4b5294541cecb68d1b72f346569e9412c265a
Author: Paul Osmialowski <p.osmialowsk@samsung.com>
Date:   Wed Feb 4 10:16:59 2015 +0100

    mmc: sdhci-s3c: solve problem with sleeping in atomic context
    
    commit 017210d1c0dc2e2d3b142985cb31d90b98dc0f0f upstream.
    
    This change addresses following problem:
    
    [    2.560726] ------------[ cut here ]------------
    [    2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744 lockdep_trace_alloc+0xec/0x118()
    [    2.574439] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
    [    2.579821] Modules linked in:
    [    2.583038] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.0-next-20141216-00002-g4ff197fc1902-dirty #1318
    [    2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    [    2.599892] [<c0014c44>] (unwind_backtrace) from [<c0011bbc>] (show_stack+0x10/0x14)
    [    2.607612] [<c0011bbc>] (show_stack) from [<c04953b8>] (dump_stack+0x70/0xbc)
    [    2.614822] [<c04953b8>] (dump_stack) from [<c0023444>] (warn_slowpath_common+0x74/0xb0)
    [    2.622885] [<c0023444>] (warn_slowpath_common) from [<c0023514>] (warn_slowpath_fmt+0x30/0x40)
    [    2.631569] [<c0023514>] (warn_slowpath_fmt) from [<c0063644>] (lockdep_trace_alloc+0xec/0x118)
    [    2.640246] [<c0063644>] (lockdep_trace_alloc) from [<c00df52c>] (__kmalloc+0x3c/0x1cc)
    [    2.648240] [<c00df52c>] (__kmalloc) from [<c0394970>] (clk_fetch_parent_index+0xb8/0xd4)
    [    2.656390] [<c0394970>] (clk_fetch_parent_index) from [<c0394a6c>] (clk_calc_new_rates+0xe0/0x1fc)
    [    2.665415] [<c0394a6c>] (clk_calc_new_rates) from [<c0394b40>] (clk_calc_new_rates+0x1b4/0x1fc)
    [    2.674181] [<c0394b40>] (clk_calc_new_rates) from [<c0395408>] (clk_set_rate+0x50/0xc8)
    [    2.682265] [<c0395408>] (clk_set_rate) from [<c0377708>] (sdhci_cmu_set_clock+0x68/0x16c)
    [    2.690503] [<c0377708>] (sdhci_cmu_set_clock) from [<c03735cc>] (sdhci_do_set_ios+0xf0/0x64c)
    [    2.699095] [<c03735cc>] (sdhci_do_set_ios) from [<c0373b48>] (sdhci_set_ios+0x20/0x2c)
    [    2.707080] [<c0373b48>] (sdhci_set_ios) from [<c035ddf0>] (mmc_power_up+0x118/0x1fc)
    [    2.714889] [<c035ddf0>] (mmc_power_up) from [<c035ecd0>] (mmc_start_host+0x44/0x6c)
    [    2.722615] [<c035ecd0>] (mmc_start_host) from [<c035fd60>] (mmc_add_host+0x58/0x7c)
    [    2.730341] [<c035fd60>] (mmc_add_host) from [<c037454c>] (sdhci_add_host+0x968/0xd94)
    [    2.738240] [<c037454c>] (sdhci_add_host) from [<c0377b60>] (sdhci_s3c_probe+0x354/0x52c)
    [    2.746406] [<c0377b60>] (sdhci_s3c_probe) from [<c0283b58>] (platform_drv_probe+0x48/0xa4)
    [    2.754733] [<c0283b58>] (platform_drv_probe) from [<c02824e8>] (driver_probe_device+0x13c/0x37c)
    [    2.763585] [<c02824e8>] (driver_probe_device) from [<c02827bc>] (__driver_attach+0x94/0x98)
    [    2.772003] [<c02827bc>] (__driver_attach) from [<c0280a60>] (bus_for_each_dev+0x54/0x88)
    [    2.780163] [<c0280a60>] (bus_for_each_dev) from [<c0281b48>] (bus_add_driver+0xe4/0x200)
    [    2.788322] [<c0281b48>] (bus_add_driver) from [<c0282dfc>] (driver_register+0x78/0xf4)
    [    2.796308] [<c0282dfc>] (driver_register) from [<c00089b0>] (do_one_initcall+0xac/0x1f0)
    [    2.804473] [<c00089b0>] (do_one_initcall) from [<c0673d94>] (kernel_init_freeable+0x10c/0x1d8)
    [    2.813153] [<c0673d94>] (kernel_init_freeable) from [<c0490058>] (kernel_init+0x28/0x108)
    [    2.821398] [<c0490058>] (kernel_init) from [<c000f268>] (ret_from_fork+0x14/0x2c)
    [    2.828939] ---[ end trace 03cc00e539849d1f ]---
    
    clk_set_rate() tries to take clk's prepare_lock mutex while being in atomic
    context entered in sdhci_do_set_ios().
    
    The solution is inspired by similar situation in sdhci_set_power() also called
    from sdhci_do_set_ios():
    
                    spin_unlock_irq(&host->lock);
                    mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
                    spin_lock_irq(&host->lock);
    
    Note that since sdhci_s3c_set_clock() sets SDHCI_CLOCK_CARD_EN, proposed change
    first resets this bit. It is reset anyway (by setting SDHCI_CLOCK_INT_EN bit
    only) after call to clk_set_rate() in order to wait for the clock to stabilize
    and is set again as soon as the clock becomes stable.
    
    Signed-off-by: Paul Osmialowski <p.osmialowsk@samsung.com>
    Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
    Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cddbf120b280582defabe3b0b34a62bba2c51520
Author: Mark Brown <broonie@linaro.org>
Date:   Tue Nov 4 12:26:42 2014 +0000

    mmc: sdhci-s3c: Check if clk_set_rate() succeeds
    
    commit cd0cfdd2485e6252b3c69284bf09d06c4d303116 upstream.
    
    It is possible that we may fail to set the clock rate, if we do so then
    log the failure and don't bother reprogramming the IP.
    
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a7dc6ab46c5164a69c51e53440af20fe158f3b3d
Author: Asbjoern Sloth Toennesen <asbjorn@asbjorn.biz>
Date:   Sun Oct 5 17:43:18 2014 +0000

    deb-pkg: remove obsolete -isp option to dpkg-gencontrol
    
    commit 4204111c028d492019e4440d12e9e3d062db4283 upstream.
    
    The -isp option has been deprecated, after it became the default
    behaviour back in 2006.
    
    Since dpkg 1.17.11, dpkg-gencontrol emits a warning on -isp usage.
    
    References: https://bugs.debian.org/215233
    Signed-off-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.biz>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 31664e11ce11b1bfb7507c5c5ca745ddee9cd1a3
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Dec 5 20:43:46 2019 -0800

    inet: protect against too small mtu values.
    
    commit 501a90c945103e8627406763dac418f20f3837b2 upstream.
    
    syzbot was once again able to crash a host by setting a very small mtu
    on loopback device.
    
    Let's make inetdev_valid_mtu() available in include/net/ip.h,
    and use it in ip_setup_cork(), so that we protect both ip_append_page()
    and __ip_append_data()
    
    Also add a READ_ONCE() when the device mtu is read.
    
    Pairs this lockless read with one WRITE_ONCE() in __dev_set_mtu(),
    even if other code paths might write over this field.
    
    Add a big comment in include/linux/netdevice.h about dev->mtu
    needing READ_ONCE()/WRITE_ONCE() annotations.
    
    Hopefully we will add the missing ones in followup patches.
    
    [1]
    
    refcount_t: saturated; leaking memory.
    WARNING: CPU: 0 PID: 9464 at lib/refcount.c:22 refcount_warn_saturate+0x138/0x1f0 lib/refcount.c:22
    Kernel panic - not syncing: panic_on_warn set ...
    CPU: 0 PID: 9464 Comm: syz-executor850 Not tainted 5.4.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x197/0x210 lib/dump_stack.c:118
     panic+0x2e3/0x75c kernel/panic.c:221
     __warn.cold+0x2f/0x3e kernel/panic.c:582
     report_bug+0x289/0x300 lib/bug.c:195
     fixup_bug arch/x86/kernel/traps.c:174 [inline]
     fixup_bug arch/x86/kernel/traps.c:169 [inline]
     do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
     do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
     invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
    RIP: 0010:refcount_warn_saturate+0x138/0x1f0 lib/refcount.c:22
    Code: 06 31 ff 89 de e8 c8 f5 e6 fd 84 db 0f 85 6f ff ff ff e8 7b f4 e6 fd 48 c7 c7 e0 71 4f 88 c6 05 56 a6 a4 06 01 e8 c7 a8 b7 fd <0f> 0b e9 50 ff ff ff e8 5c f4 e6 fd 0f b6 1d 3d a6 a4 06 31 ff 89
    RSP: 0018:ffff88809689f550 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff815e4336 RDI: ffffed1012d13e9c
    RBP: ffff88809689f560 R08: ffff88809c50a3c0 R09: fffffbfff15d31b1
    R10: fffffbfff15d31b0 R11: ffffffff8ae98d87 R12: 0000000000000001
    R13: 0000000000040100 R14: ffff888099041104 R15: ffff888218d96e40
     refcount_add include/linux/refcount.h:193 [inline]
     skb_set_owner_w+0x2b6/0x410 net/core/sock.c:1999
     sock_wmalloc+0xf1/0x120 net/core/sock.c:2096
     ip_append_page+0x7ef/0x1190 net/ipv4/ip_output.c:1383
     udp_sendpage+0x1c7/0x480 net/ipv4/udp.c:1276
     inet_sendpage+0xdb/0x150 net/ipv4/af_inet.c:821
     kernel_sendpage+0x92/0xf0 net/socket.c:3794
     sock_sendpage+0x8b/0xc0 net/socket.c:936
     pipe_to_sendpage+0x2da/0x3c0 fs/splice.c:458
     splice_from_pipe_feed fs/splice.c:512 [inline]
     __splice_from_pipe+0x3ee/0x7c0 fs/splice.c:636
     splice_from_pipe+0x108/0x170 fs/splice.c:671
     generic_splice_sendpage+0x3c/0x50 fs/splice.c:842
     do_splice_from fs/splice.c:861 [inline]
     direct_splice_actor+0x123/0x190 fs/splice.c:1035
     splice_direct_to_actor+0x3b4/0xa30 fs/splice.c:990
     do_splice_direct+0x1da/0x2a0 fs/splice.c:1078
     do_sendfile+0x597/0xd00 fs/read_write.c:1464
     __do_sys_sendfile64 fs/read_write.c:1525 [inline]
     __se_sys_sendfile64 fs/read_write.c:1511 [inline]
     __x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
     do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x441409
    Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fffb64c4f78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441409
    RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000005
    RBP: 0000000000073b8a R08: 0000000000000010 R09: 0000000000000010
    R10: 0000000000010001 R11: 0000000000000246 R12: 0000000000402180
    R13: 0000000000402210 R14: 0000000000000000 R15: 0000000000000000
    Kernel Offset: disabled
    Rebooting in 86400 seconds..
    
    Fixes: 1470ddf7f8ce ("inet: Remove explicit write references to sk/inet in ip_append_data")
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16:
     - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()
     - Keep using literal 68 instead of IPV4_MIN_MTU
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b995856122c2bba50525892afa9ec3ee939768b
Author: Guillaume Nault <gnault@redhat.com>
Date:   Fri Dec 6 12:38:49 2019 +0100

    tcp: Protect accesses to .ts_recent_stamp with {READ,WRITE}_ONCE()
    
    commit 721c8dafad26ccfa90ff659ee19755e3377b829d upstream.
    
    Syncookies borrow the ->rx_opt.ts_recent_stamp field to store the
    timestamp of the last synflood. Protect them with READ_ONCE() and
    WRITE_ONCE() since reads and writes aren't serialised.
    
    Use of .rx_opt.ts_recent_stamp for storing the synflood timestamp was
    introduced by a0f82f64e269 ("syncookies: remove last_synq_overflow from
    struct tcp_sock"). But unprotected accesses were already there when
    timestamp was stored in .last_synq_overflow.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 043bceeefbd0550f8a31f1086eac8829f7cebf0d
Author: Guillaume Nault <gnault@redhat.com>
Date:   Fri Dec 6 12:38:36 2019 +0100

    tcp: fix rejected syncookies due to stale timestamps
    
    commit 04d26e7b159a396372646a480f4caa166d1b6720 upstream.
    
    If no synflood happens for a long enough period of time, then the
    synflood timestamp isn't refreshed and jiffies can advance so much
    that time_after32() can't accurately compare them any more.
    
    Therefore, we can end up in a situation where time_after32(now,
    last_overflow + HZ) returns false, just because these two values are
    too far apart. In that case, the synflood timestamp isn't updated as
    it should be, which can trick tcp_synq_no_recent_overflow() into
    rejecting valid syncookies.
    
    For example, let's consider the following scenario on a system
    with HZ=1000:
    
      * The synflood timestamp is 0, either because that's the timestamp
        of the last synflood or, more commonly, because we're working with
        a freshly created socket.
    
      * We receive a new SYN, which triggers synflood protection. Let's say
        that this happens when jiffies == 2147484649 (that is,
        'synflood timestamp' + HZ + 2^31 + 1).
    
      * Then tcp_synq_overflow() doesn't update the synflood timestamp,
        because time_after32(2147484649, 1000) returns false.
        With:
          - 2147484649: the value of jiffies, aka. 'now'.
          - 1000: the value of 'last_overflow' + HZ.
    
      * A bit later, we receive the ACK completing the 3WHS. But
        cookie_v[46]_check() rejects it because tcp_synq_no_recent_overflow()
        says that we're not under synflood. That's because
        time_after32(2147484649, 120000) returns false.
        With:
          - 2147484649: the value of jiffies, aka. 'now'.
          - 120000: the value of 'last_overflow' + TCP_SYNCOOKIE_VALID.
    
        Of course, in reality jiffies would have increased a bit, but this
        condition will last for the next 119 seconds, which is far enough
        to accommodate for jiffie's growth.
    
    Fix this by updating the overflow timestamp whenever jiffies isn't
    within the [last_overflow, last_overflow + HZ] range. That shouldn't
    have any performance impact since the update still happens at most once
    per second.
    
    Now we're guaranteed to have fresh timestamps while under synflood, so
    tcp_synq_no_recent_overflow() can safely use it with time_after32() in
    such situations.
    
    Stale timestamps can still make tcp_synq_no_recent_overflow() return
    the wrong verdict when not under synflood. This will be handled in the
    next patch.
    
    For 64 bits architectures, the problem was introduced with the
    conversion of ->tw_ts_recent_stamp to 32 bits integer by commit
    cca9bab1b72c ("tcp: use monotonic timestamps for PAWS").
    The problem has always been there on 32 bits architectures.
    
    Fixes: cca9bab1b72c ("tcp: use monotonic timestamps for PAWS")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1299bc57c7a72353518a0fd696f6da6fcbfe3ec4
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 14 14:26:56 2015 -0700

    tcp: syncookies: extend validity range
    
    commit 264ea103a7473f51aced838e68ed384ea2c759f5 upstream.
    
    Now we allow storing more request socks per listener, we might
    hit syncookie mode less often and hit following bug in our stack :
    
    When we send a burst of syncookies, then exit this mode,
    tcp_synq_no_recent_overflow() can return false if the ACK packets coming
    from clients are coming three seconds after the end of syncookie
    episode.
    
    This is a way too strong requirement and conflicts with rest of
    syncookie code which allows ACK to be aged up to 2 minutes.
    
    Perfectly valid ACK packets are dropped just because clients might be
    in a crowded wifi environment or on another planet.
    
    So let's fix this, and also change tcp_synq_overflow() to not
    dirty a cache line for every syncookie we send, as we are under attack.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 17c53c934f97c792515b5f854a4ba3836b3df9db
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Dec 5 10:10:15 2019 -0800

    tcp: md5: fix potential overestimation of TCP option space
    
    commit 9424e2e7ad93ffffa88f882c9bc5023570904b55 upstream.
    
    Back in 2008, Adam Langley fixed the corner case of packets for flows
    having all of the following options : MD5 TS SACK
    
    Since MD5 needs 20 bytes, and TS needs 12 bytes, no sack block
    can be cooked from the remaining 8 bytes.
    
    tcp_established_options() correctly sets opts->num_sack_blocks
    to zero, but returns 36 instead of 32.
    
    This means TCP cooks packets with 4 extra bytes at the end
    of options, containing unitialized bytes.
    
    Fixes: 33ad798c924b ("tcp: options clean up")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7f190e499442ae16028f2e4bddbfff37877c3bf
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 4 15:48:24 2019 +0100

    ALSA: pcm: oss: Avoid potential buffer overflows
    
    commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream.
    
    syzkaller reported an invalid access in PCM OSS read, and this seems
    to be an overflow of the internal buffer allocated for a plugin.
    Since the rate plugin adjusts its transfer size dynamically, the
    calculation for the chained plugin might be bigger than the given
    buffer size in some extreme cases, which lead to such an buffer
    overflow as caught by KASAN.
    
    Fix it by limiting the max transfer size properly by checking against
    the destination size in each plugin transfer callback.
    
    Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9b3c5a65b7eaf8b6da97e4ddf74fa44be1064248
Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
Date:   Mon Dec 2 07:57:29 2019 +0000

    powerpc: Fix vDSO clock_getres()
    
    commit 552263456215ada7ee8700ce022d12b0cffe4802 upstream.
    
    clock_getres in the vDSO library has to preserve the same behaviour
    of posix_get_hrtimer_res().
    
    In particular, posix_get_hrtimer_res() does:
        sec = 0;
        ns = hrtimer_resolution;
    and hrtimer_resolution depends on the enablement of the high
    resolution timers that can happen either at compile or at run time.
    
    Fix the powerpc vdso implementation of clock_getres keeping a copy of
    hrtimer_resolution in vdso data and using that directly.
    
    Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
    Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    [chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES]
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr
    [bwh: Backported to 3.16:
     - In asm-offsets.c, use DEFINE() instead of OFFSET()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2c2d6d5f193b96780a287695634a283331426e02
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Apr 14 21:08:27 2015 +0000

    hrtimer: Get rid of the resolution field in hrtimer_clock_base
    
    commit 398ca17fb54b212cdc9da7ff4a17a35c48dd2103 upstream.
    
    The field has no value because all clock bases have the same
    resolution. The resolution only changes when we switch to high
    resolution timer mode. We can evaluate that from a single static
    variable as well. In the !HIGHRES case its simply a constant.
    
    Export the variable, so we can simplify the usage sites.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Link: http://lkml.kernel.org/r/20150414203500.645454122@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.16 as dependency of commit 552263456215
     "powerpc: Fix vDSO clock_getres()":
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

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

    xen/blkback: Avoid unmapping unmapped grant pages
    
    commit f9bd84a8a845d82f9b5a081a7ae68c98a11d2e84 upstream.
    
    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: Ben Hutchings <ben@decadent.org.uk>

commit 3e49a58c9a2085abeb4720ba7d329864b4a19231
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Nov 26 09:41:46 2019 -0500

    drm/radeon: fix r1xx/r2xx register checker for POT textures
    
    commit 008037d4d972c9c47b273e40e52ae34f9d9e33e7 upstream.
    
    Shift and mask were reversed.  Noticed by chance.
    
    Tested-by: Meelis Roos <mroos@linux.ee>
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ead07ae47a9347bb5cd1556dcb2631860e6a4a4c
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Tue Dec 3 16:48:06 2019 +0200

    net: bridge: deny dev_set_mac_address() when unregistering
    
    commit c4b4c421857dc7b1cf0dccbd738472360ff2cd70 upstream.
    
    We have an interesting memory leak in the bridge when it is being
    unregistered and is a slave to a master device which would change the
    mac of its slaves on unregister (e.g. bond, team). This is a very
    unusual setup but we do end up leaking 1 fdb entry because
    dev_set_mac_address() would cause the bridge to insert the new mac address
    into its table after all fdbs are flushed, i.e. after dellink() on the
    bridge has finished and we call NETDEV_UNREGISTER the bond/team would
    release it and will call dev_set_mac_address() to restore its original
    address and that in turn will add an fdb in the bridge.
    One fix is to check for the bridge dev's reg_state in its
    ndo_set_mac_address callback and return an error if the bridge is not in
    NETREG_REGISTERED.
    
    Easy steps to reproduce:
     1. add bond in mode != A/B
     2. add any slave to the bond
     3. add bridge dev as a slave to the bond
     4. destroy the bridge device
    
    Trace:
     unreferenced object 0xffff888035c4d080 (size 128):
       comm "ip", pid 4068, jiffies 4296209429 (age 1413.753s)
       hex dump (first 32 bytes):
         41 1d c9 36 80 88 ff ff 00 00 00 00 00 00 00 00  A..6............
         d2 19 c9 5e 3f d7 00 00 00 00 00 00 00 00 00 00  ...^?...........
       backtrace:
         [<00000000ddb525dc>] kmem_cache_alloc+0x155/0x26f
         [<00000000633ff1e0>] fdb_create+0x21/0x486 [bridge]
         [<0000000092b17e9c>] fdb_insert+0x91/0xdc [bridge]
         [<00000000f2a0f0ff>] br_fdb_change_mac_address+0xb3/0x175 [bridge]
         [<000000001de02dbd>] br_stp_change_bridge_id+0xf/0xff [bridge]
         [<00000000ac0e32b1>] br_set_mac_address+0x76/0x99 [bridge]
         [<000000006846a77f>] dev_set_mac_address+0x63/0x9b
         [<00000000d30738fc>] __bond_release_one+0x3f6/0x455 [bonding]
         [<00000000fc7ec01d>] bond_netdev_event+0x2f2/0x400 [bonding]
         [<00000000305d7795>] notifier_call_chain+0x38/0x56
         [<0000000028885d4a>] call_netdevice_notifiers+0x1e/0x23
         [<000000008279477b>] rollback_registered_many+0x353/0x6a4
         [<0000000018ef753a>] unregister_netdevice_many+0x17/0x6f
         [<00000000ba854b7a>] rtnl_delete_link+0x3c/0x43
         [<00000000adf8618d>] rtnl_dellink+0x1dc/0x20a
         [<000000009b6395fd>] rtnetlink_rcv_msg+0x23d/0x268
    
    Fixes: 43598813386f ("bridge: add local MAC address to forwarding table (v2)")
    Reported-by: syzbot+2add91c08eb181fea1bf@syzkaller.appspotmail.com
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 52b17295552a288d4910477770fee67c1b1c5540
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Wed Nov 27 16:18:39 2019 -0800

    CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks
    
    commit 6f582b273ec23332074d970a7fb25bef835df71f upstream.
    
    Currently when the client creates a cifsFileInfo structure for
    a newly opened file, it allocates a list of byte-range locks
    with a pointer to the new cfile and attaches this list to the
    inode's lock list. The latter happens before initializing all
    other fields, e.g. cfile->tlink. Thus a partially initialized
    cifsFileInfo structure becomes available to other threads that
    walk through the inode's lock list. One example of such a thread
    may be an oplock break worker thread that tries to push all
    cached byte-range locks. This causes NULL-pointer dereference
    in smb2_push_mandatory_locks() when accessing cfile->tlink:
    
    [598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038
    ...
    [598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs]
    [598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs]
    ...
    [598428.945834] Call Trace:
    [598428.945870]  ? cifs_revalidate_mapping+0x45/0x90 [cifs]
    [598428.945901]  cifs_oplock_break+0x13d/0x450 [cifs]
    [598428.945909]  process_one_work+0x1db/0x380
    [598428.945914]  worker_thread+0x4d/0x400
    [598428.945921]  kthread+0x104/0x140
    [598428.945925]  ? process_one_work+0x380/0x380
    [598428.945931]  ? kthread_park+0x80/0x80
    [598428.945937]  ret_from_fork+0x35/0x40
    
    Fix this by reordering initialization steps of the cifsFileInfo
    structure: initialize all the fields first and then add the new
    byte-range lock list to the inode's lock list.
    
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b4f0b955c41356c8e22464c9a2a7086fda46cdd
Author: Dave Wysochanski <dwysocha@redhat.com>
Date:   Wed Oct 23 05:02:33 2019 -0400

    cifs: Fix cifsInodeInfo lock_sem deadlock when reconnect occurs
    
    commit d46b0da7a33dd8c99d969834f682267a45444ab3 upstream.
    
    There's a deadlock that is possible and can easily be seen with
    a test where multiple readers open/read/close of the same file
    and a disruption occurs causing reconnect.  The deadlock is due
    a reader thread inside cifs_strict_readv calling down_read and
    obtaining lock_sem, and then after reconnect inside
    cifs_reopen_file calling down_read a second time.  If in
    between the two down_read calls, a down_write comes from
    another process, deadlock occurs.
    
            CPU0                    CPU1
            ----                    ----
    cifs_strict_readv()
     down_read(&cifsi->lock_sem);
                                   _cifsFileInfo_put
                                      OR
                                   cifs_new_fileinfo
                                    down_write(&cifsi->lock_sem);
    cifs_reopen_file()
     down_read(&cifsi->lock_sem);
    
    Fix the above by changing all down_write(lock_sem) calls to
    down_write_trylock(lock_sem)/msleep() loop, which in turn
    makes the second down_read call benign since it will never
    block behind the writer while holding lock_sem.
    
    Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
    Suggested-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed--by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d21c1d923294f1a9cc96a90849dc1fae59de6fa7
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Sun Dec 1 18:41:25 2019 +0100

    openvswitch: remove another BUG_ON()
    
    commit 8a574f86652a4540a2433946ba826ccb87f398cc upstream.
    
    If we can't build the flow del notification, we can simply delete
    the flow, no need to crash the kernel. Still keep a WARN_ON to
    preserve debuggability.
    
    Note: the BUG_ON() predates the Fixes tag, but this change
    can be applied only after the mentioned commit.
    
    v1 -> v2:
     - do not leak an skb on error
    
    Fixes: aed067783e50 ("openvswitch: Minimize ovs_flow_cmd_del critical section.")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2584c958c3ee1b4a6b1a7052418c29029c56f7ec
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Sun Dec 1 18:41:24 2019 +0100

    openvswitch: drop unneeded BUG_ON() in ovs_flow_cmd_build_info()
    
    commit 8ffeb03fbba3b599690b361467bfd2373e8c450f upstream.
    
    All the callers of ovs_flow_cmd_build_info() already deal with
    error return code correctly, so we can handle the error condition
    in a more gracefull way. Still dump a warning to preserve
    debuggability.
    
    v1 -> v2:
     - clarify the commit message
     - clean the skb and report the error (DaveM)
    
    Fixes: ccb1352e76cf ("net: Add Open vSwitch kernel components.")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b62dc7c8374c5f3da14319d94376272e3d72d25
Author: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
Date:   Thu Nov 28 15:58:29 2019 +0530

    ACPI: bus: Fix NULL pointer check in acpi_bus_get_private_data()
    
    commit 627ead724eff33673597216f5020b72118827de4 upstream.
    
    kmemleak reported backtrace:
        [<bbee0454>] kmem_cache_alloc_trace+0x128/0x260
        [<6677f215>] i2c_acpi_install_space_handler+0x4b/0xe0
        [<1180f4fc>] i2c_register_adapter+0x186/0x400
        [<6083baf7>] i2c_add_adapter+0x4e/0x70
        [<a3ddf966>] intel_gmbus_setup+0x1a2/0x2c0 [i915]
        [<84cb69ae>] i915_driver_probe+0x8d8/0x13a0 [i915]
        [<81911d4b>] i915_pci_probe+0x48/0x160 [i915]
        [<4b159af1>] pci_device_probe+0xdc/0x160
        [<b3c64704>] really_probe+0x1ee/0x450
        [<bc029f5a>] driver_probe_device+0x142/0x1b0
        [<d8829d20>] device_driver_attach+0x49/0x50
        [<de71f045>] __driver_attach+0xc9/0x150
        [<df33ac83>] bus_for_each_dev+0x56/0xa0
        [<80089bba>] driver_attach+0x19/0x20
        [<cc73f583>] bus_add_driver+0x177/0x220
        [<7b29d8c7>] driver_register+0x56/0xf0
    
    In i2c_acpi_remove_space_handler(), a leak occurs whenever the
    "data" parameter is initialized to 0 before being passed to
    acpi_bus_get_private_data().
    
    This is because the NULL pointer check in acpi_bus_get_private_data()
    (condition->if(!*data)) returns EINVAL and, in consequence, memory is
    never freed in i2c_acpi_remove_space_handler().
    
    Fix the NULL pointer check in acpi_bus_get_private_data() to follow
    the analogous check in acpi_get_data_full().
    
    Signed-off-by: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
    [ rjw: Subject & changelog ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd7c02519cfc643486dd5fa232dc8d8ba73e35a7
Author: Francesco Ruggeri <fruggeri@arista.com>
Date:   Tue Nov 19 21:47:27 2019 -0800

    ACPI: OSL: only free map once in osl.c
    
    commit 833a426cc471b6088011b3d67f1dc4e147614647 upstream.
    
    acpi_os_map_cleanup checks map->refcount outside of acpi_ioremap_lock
    before freeing the map. This creates a race condition the can result
    in the map being freed more than once.
    A panic can be caused by running
    
    for ((i=0; i<10; i++))
    do
            for ((j=0; j<100000; j++))
            do
                    cat /sys/firmware/acpi/tables/data/BERT >/dev/null
            done &
    done
    
    This patch makes sure that only the process that drops the reference
    to 0 does the freeing.
    
    Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c")
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 329ad5bb5cabf1be91e9fc4c51e137d5ddb8aca8
Author: Konstantin Khlebnikov <koct9i@gmail.com>
Date:   Sun Nov 9 13:53:37 2014 +0400

    ACPI / osl: speedup grace period in acpi_os_map_cleanup
    
    commit 74b51ee152b6d99e61ba329799a039453fb9438f upstream.
    
    ACPI maintains cache of ioremap regions to speed up operations and
    access to them from irq context where ioremap() calls aren't allowed.
    This code abuses synchronize_rcu() on unmap path for synchronization
    with fast-path in acpi_os_read/write_memory which uses this cache.
    
    Since v3.10 CPUs are allowed to enter idle state even if they have RCU
    callbacks queued, see commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
    ("rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks").
    That change caused problems with nvidia proprietary driver which calls
    acpi_os_map/unmap_generic_address several times during initialization.
    Each unmap calls synchronize_rcu and adds significant delay. Totally
    initialization is slowed for a couple of seconds and that is enough to
    trigger timeout in hardware, gpu decides to "fell off the bus". Widely
    spread workaround is reducing "rcu_idle_gp_delay" from 4 to 1 jiffy.
    
    This patch replaces synchronize_rcu() with synchronize_rcu_expedited()
    which is much faster.
    
    Link: https://devtalk.nvidia.com/default/topic/567297/linux/linux-3-10-driver-crash/
    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
    Reported-and-tested-by: Alexander Monakov <amonakov@gmail.com>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8670838e08177d5b82d8ecea6301c7106d022885
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Wed Nov 27 10:13:34 2019 -0300

    perf regs: Make perf_reg_name() return "unknown" instead of NULL
    
    commit 5b596e0ff0e1852197d4c82d3314db5e43126bf7 upstream.
    
    To avoid breaking the build on arches where this is not wired up, at
    least all the other features should be made available and when using
    this specific routine, the "unknown" should point the user/developer to
    the need to wire this up on this particular hardware architecture.
    
    Detected in a container mipsel debian cross build environment, where it
    shows up as:
    
      In file included from /usr/mipsel-linux-gnu/include/stdio.h:867,
                       from /git/linux/tools/perf/lib/include/perf/cpumap.h:6,
                       from util/session.c:13:
      In function 'printf',
          inlined from 'regs_dump__printf' at util/session.c:1103:3,
          inlined from 'regs__printf' at util/session.c:1131:2:
      /usr/mipsel-linux-gnu/include/bits/stdio2.h:107:10: error: '%-5s' directive argument is null [-Werror=format-overflow=]
        107 |   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
            |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    cross compiler details:
    
      mipsel-linux-gnu-gcc (Debian 9.2.1-8) 9.2.1 20190909
    
    Also on mips64:
    
      In file included from /usr/mips64-linux-gnuabi64/include/stdio.h:867,
                       from /git/linux/tools/perf/lib/include/perf/cpumap.h:6,
                       from util/session.c:13:
      In function 'printf',
          inlined from 'regs_dump__printf' at util/session.c:1103:3,
          inlined from 'regs__printf' at util/session.c:1131:2,
          inlined from 'regs_user__printf' at util/session.c:1139:3,
          inlined from 'dump_sample' at util/session.c:1246:3,
          inlined from 'machines__deliver_event' at util/session.c:1421:3:
      /usr/mips64-linux-gnuabi64/include/bits/stdio2.h:107:10: error: '%-5s' directive argument is null [-Werror=format-overflow=]
        107 |   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
            |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      In function 'printf',
          inlined from 'regs_dump__printf' at util/session.c:1103:3,
          inlined from 'regs__printf' at util/session.c:1131:2,
          inlined from 'regs_intr__printf' at util/session.c:1147:3,
          inlined from 'dump_sample' at util/session.c:1249:3,
          inlined from 'machines__deliver_event' at util/session.c:1421:3:
      /usr/mips64-linux-gnuabi64/include/bits/stdio2.h:107:10: error: '%-5s' directive argument is null [-Werror=format-overflow=]
        107 |   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
            |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    cross compiler details:
    
      mips64-linux-gnuabi64-gcc (Debian 9.2.1-8) 9.2.1 20190909
    
    Fixes: 2bcd355b71da ("perf tools: Add interface to arch registers sets")
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lkml.kernel.org/n/tip-95wjyv4o65nuaeweq31t7l1s@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b427ef7f3020f5879ce677b06a89d7efd568c1e1
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Wed Nov 13 13:18:31 2019 -0800

    xtensa: fix TLB sanity checker
    
    commit 36de10c4788efc6efe6ff9aa10d38cb7eea4c818 upstream.
    
    Virtual and translated addresses retrieved by the xtensa TLB sanity
    checker must be consistent, i.e. correspond to the same state of the
    checked TLB entry. KASAN shadow memory is mapped dynamically using
    auto-refill TLB entries and thus may change TLB state between the
    virtual and translated address retrieval, resulting in false TLB
    insanity report.
    Move read_xtlb_translation close to read_xtlb_virtual to make sure that
    read values are consistent.
    
    Fixes: a99e07ee5e88 ("xtensa: check TLB sanity on return to userspace")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cc40a10cc4e0b8a961af16db5435fc7dd939208f
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Tue Oct 8 11:42:39 2019 +0800

    PCI/MSI: Fix incorrect MSI-X masking on resume
    
    commit e045fa29e89383c717e308609edd19d2fd29e1be upstream.
    
    When a driver enables MSI-X, msix_program_entries() reads the MSI-X Vector
    Control register for each vector and saves it in desc->masked.  Each
    register is 32 bits and bit 0 is the actual Mask bit.
    
    When we restored these registers during resume, we previously set the Mask
    bit if *any* bit in desc->masked was set instead of when the Mask bit
    itself was set:
    
      pci_restore_state
        pci_restore_msi_state
          __pci_restore_msix_state
            for_each_pci_msi_entry
              msix_mask_irq(entry, entry->masked)   <-- entire u32 word
                __pci_msix_desc_mask_irq(desc, flag)
                  mask_bits = desc->masked & ~PCI_MSIX_ENTRY_CTRL_MASKBIT
                  if (flag)       <-- testing entire u32, not just bit 0
                    mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT
                  writel(mask_bits, desc_addr + PCI_MSIX_ENTRY_VECTOR_CTRL)
    
    This means that after resume, MSI-X vectors were masked when they shouldn't
    be, which leads to timeouts like this:
    
      nvme nvme0: I/O 978 QID 3 timeout, completion polled
    
    On resume, set the Mask bit only when the saved Mask bit from suspend was
    set.
    
    This should remove the need for 19ea025e1d28 ("nvme: Add quirk for Kingston
    NVME SSD running FW E8FK11.T").
    
    [bhelgaas: commit log, move fix to __pci_msix_desc_mask_irq()]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=204887
    Link: https://lore.kernel.org/r/20191008034238.2503-1-jian-hong@endlessm.com
    Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b1f4d5ce80ae31212cc792fa2b4dedacfb99b9c9
Author: Menglong Dong <dong.menglong@zte.com.cn>
Date:   Mon Nov 25 16:58:09 2019 +0800

    macvlan: schedule bc_work even if error
    
    commit 1d7ea55668878bb350979c377fc72509dd6f5b21 upstream.
    
    While enqueueing a broadcast skb to port->bc_queue, schedule_work()
    is called to add port->bc_work, which processes the skbs in
    bc_queue, to "events" work queue. If port->bc_queue is full, the
    skb will be discarded and schedule_work(&port->bc_work) won't be
    called. However, if port->bc_queue is full and port->bc_work is not
    running or pending, port->bc_queue will keep full and schedule_work()
    won't be called any more, and all broadcast skbs to macvlan will be
    discarded. This case can happen:
    
    macvlan_process_broadcast() is the pending function of port->bc_work,
    it moves all the skbs in port->bc_queue to the queue "list", and
    processes the skbs in "list". During this, new skbs will keep being
    added to port->bc_queue in macvlan_broadcast_enqueue(), and
    port->bc_queue may already full when macvlan_process_broadcast()
    return. This may happen, especially when there are a lot of real-time
    threads and the process is preempted.
    
    Fix this by calling schedule_work(&port->bc_work) even if
    port->bc_work is full in macvlan_broadcast_enqueue().
    
    Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
    Signed-off-by: Menglong Dong <dong.menglong@zte.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 16510ed27cc4cca247551cbccca40db86968edfd
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Nov 22 19:56:41 2019 +0100

    platform/x86: hp-wmi: Fix ACPI errors caused by passing 0 as input size
    
    commit f3e4f3fc8ee9729c4b1b27a478c68b713df53c0c upstream.
    
    The AML code implementing the WMI methods creates a variable length
    field to hold the input data we pass like this:
    
            CreateDWordField (Arg1, 0x0C, DSZI)
            Local5 = DSZI /* \HWMC.DSZI */
            CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN)
    
    If we pass 0 as bios_args.datasize argument then (Local5 * 0x08)
    is 0 which results in these errors:
    
    [   71.973305] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20190816/dsopcode-133)
    [   71.973332] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529)
    [   71.973413] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529)
    
    And in our HPWMI_WIRELESS2_QUERY calls always failing. for read commands
    like HPWMI_WIRELESS2_QUERY the DSZI value is not used / checked, except for
    read commands where extra input is needed to specify exactly what to read.
    
    So for HPWMI_WIRELESS2_QUERY we can safely pass the size of the expected
    output as insize to hp_wmi_perform_query(), as we are already doing for all
    other HPWMI_READ commands we send. Doing so fixes these errors.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 11f97e6857d3368fa5fb33578185a8048767148c
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Nov 22 19:56:40 2019 +0100

    platform/x86: hp-wmi: Fix ACPI errors caused by too small buffer
    
    commit 16245db1489cd9aa579506f64afeeeb13d825a93 upstream.
    
    The HP WMI calls may take up to 128 bytes of data as input, and
    the AML methods implementing the WMI calls, declare a couple of fields for
    accessing input in different sizes, specifycally the HWMC method contains:
    
            CreateField (Arg1, 0x80, 0x0400, D128)
    
    Even though we do not use any of the WMI command-types which need a buffer
    of this size, the APCI interpreter still tries to create it as it is
    declared in generoc code at the top of the HWMC method which runs before
    the code looks at which command-type is requested.
    
    This results in many of these errors on many different HP laptop models:
    
    [   14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (20170303/dsopcode-236)
    [   14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (20170303/psparse-543)
    [   14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (20170303/psparse-543)
    
    This commit increases the size of the data element of the bios_args struct
    to 128 bytes fixing these errors.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d73e26a36c073c2922d2d2926c7b35ed269571cb
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Thu Oct 31 14:18:57 2019 -0700

    CIFS: Fix SMB2 oplock break processing
    
    commit fa9c2362497fbd64788063288dc4e74daf977ebb upstream.
    
    Even when mounting modern protocol version the server may be
    configured without supporting SMB2.1 leases and the client
    uses SMB2 oplock to optimize IO performance through local caching.
    
    However there is a problem in oplock break handling that leads
    to missing a break notification on the client who has a file
    opened. It latter causes big latencies to other clients that
    are trying to open the same file.
    
    The problem reproduces when there are multiple shares from the
    same server mounted on the client. The processing code tries to
    match persistent and volatile file ids from the break notification
    with an open file but it skips all share besides the first one.
    Fix this by looking up in all shares belonging to the server that
    issued the oplock break.
    
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 97c39ca8cf497077e063a821a03e58dece77ae8c
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Tue Nov 12 17:16:35 2019 -0800

    CIFS: Respect O_SYNC and O_DIRECT flags during reconnect
    
    commit 44805b0e62f15e90d233485420e1847133716bdc upstream.
    
    Currently the client translates O_SYNC and O_DIRECT flags
    into corresponding SMB create options when openning a file.
    The problem is that on reconnect when the file is being
    re-opened the client doesn't set those flags and it causes
    a server to reject re-open requests because create options
    don't match. The latter means that any subsequent system
    call against that open file fail until a share is re-mounted.
    
    Fix this by properly setting SMB create options when
    re-openning files after reconnects.
    
    Fixes: 1013e760d10e6: ("SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags")
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 970405d201c855ba4ace20bbf548c5ee6e69ef28
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Nov 22 12:42:20 2019 -0800

    tty: vt: keyboard: reject invalid keycodes
    
    commit b2b2dd71e0859436d4e05b2f61f86140250ed3f8 upstream.
    
    Do not try to handle keycodes that are too big, otherwise we risk doing
    out-of-bounds writes:
    
    BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
    BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
    BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
    Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
    ...
     kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
     kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
     input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
     input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
     input_pass_values drivers/input/input.c:949 [inline]
     input_set_keycode+0x290/0x320 drivers/input/input.c:954
     evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
     evdev_do_ioctl drivers/input/evdev.c:1150 [inline]
    
    In this case we were dealing with a fuzzed HID device that declared over
    12K buttons, and while HID layer should not be reporting to us such big
    keycodes, we should also be defensive and reject invalid data ourselves as
    well.
    
    Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-ws
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit eb565a29ebb8de0388c16752da9d6fb457b18fa9
Author: Sam Bobroff <sbobroff@linux.ibm.com>
Date:   Mon Nov 18 10:53:53 2019 +1100

    drm/radeon: fix bad DMA from INTERRUPT_CNTL2
    
    commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 upstream.
    
    The INTERRUPT_CNTL2 register expects a valid DMA address, but is
    currently set with a GPU MC address.  This can cause problems on
    systems that detect the resulting DMA read from an invalid address
    (found on a Power8 guest).
    
    Instead, use the DMA address of the dummy page because it will always
    be safe.
    
    Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)")
    Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
    Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
    Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e469c106b969bd935447e915e4e8232dd3981249
Author: Hewenliang <hewenliang4@huawei.com>
Date:   Mon Nov 18 20:44:15 2019 -0500

    libtraceevent: Fix memory leakage in copy_filter_type
    
    commit 10992af6bf46a2048ad964985a5b77464e5563b1 upstream.
    
    It is necessary to free the memory that we have allocated when error occurs.
    
    Fixes: ef3072cd1d5c ("tools lib traceevent: Get rid of die in add_filter_type()")
    Signed-off-by: Hewenliang <hewenliang4@huawei.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Tzvetomir Stoyanov <tstoyanov@vmware.com>
    Link: http://lore.kernel.org/lkml/20191119014415.57210-1-hewenliang4@huawei.com
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 989ea7dea02853674281bb2c063848097c109edc
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: Ben Hutchings <ben@decadent.org.uk>

commit 0994f528245bfb6afe6ec76deb63e5287f1ebc50
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Sep 2 22:52:52 2019 +0800

    x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect
    
    commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream.
    
    The AMD FCH USB XHCI Controller advertises support for generating PME#
    while in D0.  When in D0, it does signal PME# for USB 3.0 connect events,
    but not for USB 2.0 or USB 1.1 connect events, which means the controller
    doesn't wake correctly for those events.
    
      00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
            Subsystem: Dell FCH USB XHCI Controller [1028:087e]
            Capabilities: [50] Power Management version 3
                    Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
    
    Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not
    assert PME# from D0 so we don't rely on it.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
    Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 11795d4863bd64c348b7b6388ef6f6c0804902b7
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Nov 18 12:23:00 2019 -0500

    KVM: x86: do not modify masked bits of shared MSRs
    
    commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream.
    
    "Shared MSRs" are guest MSRs that are written to the host MSRs but
    keep their value until the next return to userspace.  They support
    a mask, so that some bits keep the host value, but this mask is
    only used to skip an unnecessary MSR write and the value written
    to the MSR is always the guest MSR.
    
    Fix this and, while at it, do not update smsr->values[slot].curr if
    for whatever reason the wrmsr fails.  This should only happen due to
    reserved bits, so the value written to smsr->values[slot].curr
    will not match when the user-return notifier and the host value will
    always be restored.  However, it is untidy and in rare cases this
    can actually avoid spurious WRMSRs on return to userspace.
    
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Tested-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6398f8c938d3eb074b5108a32d80c56f7a91b5c1
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Nov 18 18:58:26 2019 +0100

    KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES
    
    commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream.
    
    KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented
    to the guests.  It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR &&
    !RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not
    hidden (it actually was), yet the value says that TSX is not vulnerable
    to microarchitectural data sampling.  Fix both.
    
    Tested-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 653eb6d0723998fbea0d64b4231368df1d722f96
Author: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date:   Wed Nov 20 23:18:53 2019 +0800

    serial: serial_core: Perform NULL checks for break_ctl ops
    
    commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream.
    
    Doing fuzz test on sbsa uart device, causes a kernel crash
    due to NULL pointer dereference:
    
    ------------[ cut here ]------------
    Unable to handle kernel paging request at virtual address fffffffffffffffc
    pgd = ffffffe331723000
    [fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000
    Internal error: Oops: 96000005 [#1] PREEMPT SMP
    Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O)
    Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O)
    hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O)
    mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O)
    uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4
    iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd
    usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid
    ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod
    yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand
    nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe
    cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry
    nfsv3 nfs nfs_acl lockd sunrpc grace autofs4
    CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G           O    4.4.193 #1
    task: ffffffe32b23f110 task.stack: ffffffe32bda4000
    PC is at uart_break_ctl+0x44/0x84
    LR is at uart_break_ctl+0x34/0x84
    pc : [<ffffff8393196098>] lr : [<ffffff8393196088>] pstate: 80000005
    sp : ffffffe32bda7cc0
    x29: ffffffe32bda7cc0 x28: ffffffe32b23f110
    x27: ffffff8393402000 x26: 0000000000000000
    x25: ffffffe32b233f40 x24: ffffffc07a8ec680
    x23: 0000000000005425 x22: 00000000ffffffff
    x21: ffffffe33ed73c98 x20: 0000000000000000
    x19: ffffffe33ed94168 x18: 0000000000000004
    x17: 0000007f92ae9d30 x16: ffffff8392fa6064
    x15: 0000000000000010 x14: 0000000000000000
    x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000020 x10: 0000007ffdac1708
    x9 : 0000000000000078 x8 : 000000000000001d
    x7 : 0000000052a64887 x6 : ffffffe32bda7e08
    x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000
    x3 : ffffff83938d5018 x2 : 0000000000000080
    x1 : ffffffe32b23c040 x0 : ffffff83934428f8
    virtual start addr offset is 38ac00000
    module base offset is 2cd4cf1000
    linear region base offset is : 0
    Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000)
    Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000)
    7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054
    7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c
    7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600
    7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425
    7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003
    7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e
    7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600
    7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410
    7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978
    7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc
    7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
    7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0
    7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
    7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78
    7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c
    7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425
    7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014
    7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078
    7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000
    7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30
    7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0
    7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840
    7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000
    7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d
    7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    Call trace:
    Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0)
    7aa0:                                   0000000000001000 0000007fffffffff
    7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025
    7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c
    7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20
    7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000
    7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110
    7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600
    7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018
    7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887
    7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020
    7be0: 0000000000000000 0000000000000000
    [<ffffff8393196098>] uart_break_ctl+0x44/0x84
    [<ffffff8393177718>] send_break+0xa0/0x114
    [<ffffff8393179a1c>] tty_ioctl+0xc50/0xe84
    [<ffffff8392fa5a40>] do_vfs_ioctl+0xc4/0x6e8
    [<ffffff8392fa60cc>] SyS_ioctl+0x68/0x9c
    [<ffffff8392e02e78>] __sys_trace_return+0x0/0x4
    Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280)
    ---[ end trace 8606094f1960c5e0 ]---
    Kernel panic - not syncing: Fatal exception
    
    Fix this problem by adding NULL checks prior to calling break_ctl ops.
    
    Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
    Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89993c305905e3e567b1a9ed41e97a74b9af8224
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Nov 5 14:50:32 2019 +0100

    iwlwifi: check kasprintf() return value
    
    commit 5974fbb5e10b018fdbe3c3b81cb4cc54e1105ab9 upstream.
    
    kasprintf() can fail, we should check the return value.
    
    Fixes: 5ed540aecc2a ("iwlwifi: use mac80211 throughput trigger")
    Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    [bwh: Backported to 3.16: adjust filenames]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4b1da8a318536694e47749390373320095526fb8
Author: Pan Bian <bianpan2016@163.com>
Date:   Wed Nov 6 20:32:21 2019 +0800

    scsi: bnx2i: fix potential use after free
    
    commit 29d28f2b8d3736ac61c28ef7e20fda63795b74d9 upstream.
    
    The member hba->pcidev may be used after its reference is dropped. Move the
    put function to where it is never used to avoid potential use after free
    issues.
    
    Fixes: a77171806515 ("[SCSI] bnx2i: Removed the reference to the netdev->base_addr")
    Link: https://lore.kernel.org/r/1573043541-19126-1-git-send-email-bianpan2016@163.com
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 62a7877f9496c8aecfe78d4807bc8e55d8373104
Author: Pan Bian <bianpan2016@163.com>
Date:   Tue Nov 5 17:25:27 2019 +0800

    scsi: qla4xxx: fix double free bug
    
    commit 3fe3d2428b62822b7b030577cd612790bdd8c941 upstream.
    
    The variable init_fw_cb is released twice, resulting in a double free
    bug. The call to the function dma_free_coherent() before goto is removed to
    get rid of potential double free.
    
    Fixes: 2a49a78ed3c8 ("[SCSI] qla4xxx: added IPv6 support.")
    Link: https://lore.kernel.org/r/1572945927-27796-1-git-send-email-bianpan2016@163.com
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 75b201c2fdfb3cecc3eb6a1dc85b87055de642e9
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Nov 11 22:18:13 2019 -0500

    ext4: work around deleting a file with i_nlink == 0 safely
    
    commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream.
    
    If the file system is corrupted such that a file's i_links_count is
    too small, then it's possible that when unlinking that file, i_nlink
    will already be zero.  Previously we were working around this kind of
    corruption by forcing i_nlink to one; but we were doing this before
    trying to delete the directory entry --- and if the file system is
    corrupted enough that ext4_delete_entry() fails, then we exit with
    i_nlink elevated, and this causes the orphan inode list handling to be
    FUBAR'ed, such that when we unmount the file system, the orphan inode
    list can get corrupted.
    
    A better way to fix this is to simply skip trying to call drop_nlink()
    if i_nlink is already zero, thus moving the check to the place where
    it makes the most sense.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=205433
    
    Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    [bwh: Backported to 3.16: Log message and function are different]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 40157c9cda553903a1fe333d71a27dc60f5d9005
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: Ben Hutchings <ben@decadent.org.uk>

commit 938f7b5376449e3e7e7c134c94e2413216875128
Author: Kars de Jong <jongk@linux-m68k.org>
Date:   Sat Nov 16 12:05:48 2019 +0100

    rtc: msm6242: Fix reading of 10-hour digit
    
    commit e34494c8df0cd96fc432efae121db3212c46ae48 upstream.
    
    The driver was reading the wrong register as the 10-hour digit due to
    a misplaced ')'. It was in fact reading the 1-second digit register due
    to this bug.
    
    Also remove the use of a magic number for the hour mask and use the define
    for it which was already present.
    
    Fixes: 4f9b9bba1dd1 ("rtc: Add an RTC driver for the Oki MSM6242")
    Tested-by: Kars de Jong <jongk@linux-m68k.org>
    Signed-off-by: Kars de Jong <jongk@linux-m68k.org>
    Link: https://lore.kernel.org/r/20191116110548.8562-1-jongk@linux-m68k.org
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 444b7f77614e3a07ddfaf5f0109b874962377711
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Mon Nov 18 10:48:33 2019 +0800

    serial: ifx6x60: add missed pm_runtime_disable
    
    commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream.
    
    The driver forgets to call pm_runtime_disable in remove.
    Add the missed calls to fix it.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2ce5f201744ae2245e6bd8587826a031789c6702
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue Sep 24 16:50:43 2019 -0400

    btrfs: check page->mapping when loading free space cache
    
    commit 3797136b626ad4b6582223660c041efdea8f26b2 upstream.
    
    While testing 5.2 we ran into the following panic
    
    [52238.017028] BUG: kernel NULL pointer dereference, address: 0000000000000001
    [52238.105608] RIP: 0010:drop_buffers+0x3d/0x150
    [52238.304051] Call Trace:
    [52238.308958]  try_to_free_buffers+0x15b/0x1b0
    [52238.317503]  shrink_page_list+0x1164/0x1780
    [52238.325877]  shrink_inactive_list+0x18f/0x3b0
    [52238.334596]  shrink_node_memcg+0x23e/0x7d0
    [52238.342790]  ? do_shrink_slab+0x4f/0x290
    [52238.350648]  shrink_node+0xce/0x4a0
    [52238.357628]  balance_pgdat+0x2c7/0x510
    [52238.365135]  kswapd+0x216/0x3e0
    [52238.371425]  ? wait_woken+0x80/0x80
    [52238.378412]  ? balance_pgdat+0x510/0x510
    [52238.386265]  kthread+0x111/0x130
    [52238.392727]  ? kthread_create_on_node+0x60/0x60
    [52238.401782]  ret_from_fork+0x1f/0x30
    
    The page we were trying to drop had a page->private, but had no
    page->mapping and so called drop_buffers, assuming that we had a
    buffer_head on the page, and then panic'ed trying to deref 1, which is
    our page->private for data pages.
    
    This is happening because we're truncating the free space cache while
    we're trying to load the free space cache.  This isn't supposed to
    happen, and I'll fix that in a followup patch.  However we still
    shouldn't allow those sort of mistakes to result in messing with pages
    that do not belong to us.  So add the page->mapping check to verify that
    we still own this page after dropping and re-acquiring the page lock.
    
    This page being unlocked as:
    btrfs_readpage
      extent_read_full_page
        __extent_read_full_page
          __do_readpage
            if (!nr)
               unlock_page  <-- nr can be 0 only if submit_extent_page
                                returns an error
    
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    [ add callchain ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9efc9109d30e41e9857bd11759a35ad0e0769784
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Oct 11 16:41:20 2019 +0100

    Btrfs: fix negative subv_writers counter and data space leak after buffered write
    
    commit a0e248bb502d5165b3314ac3819e888fdcdf7d9f upstream.
    
    When doing a buffered write it's possible to leave the subv_writers
    counter of the root, used for synchronization between buffered nocow
    writers and snapshotting. This happens in an exceptional case like the
    following:
    
    1) We fail to allocate data space for the write, since there's not
       enough available data space nor enough unallocated space for allocating
       a new data block group;
    
    2) Because of that failure, we try to go to NOCOW mode, which succeeds
       and therefore we set the local variable 'only_release_metadata' to true
       and set the root's sub_writers counter to 1 through the call to
       btrfs_start_write_no_snapshotting() made by check_can_nocow();
    
    3) The call to btrfs_copy_from_user() returns zero, which is very unlikely
       to happen but not impossible;
    
    4) No pages are copied because btrfs_copy_from_user() returned zero;
    
    5) We call btrfs_end_write_no_snapshotting() which decrements the root's
       subv_writers counter to 0;
    
    6) We don't set 'only_release_metadata' back to 'false' because we do
       it only if 'copied', the value returned by btrfs_copy_from_user(), is
       greater than zero;
    
    7) On the next iteration of the while loop, which processes the same
       page range, we are now able to allocate data space for the write (we
       got enough data space released in the meanwhile);
    
    8) After this if we fail at btrfs_delalloc_reserve_metadata(), because
       now there isn't enough free metadata space, or in some other place
       further below (prepare_pages(), lock_and_cleanup_extent_if_need(),
       btrfs_dirty_pages()), we break out of the while loop with
       'only_release_metadata' having a value of 'true';
    
    9) Because 'only_release_metadata' is 'true' we end up decrementing the
       root's subv_writers counter to -1 (through a call to
       btrfs_end_write_no_snapshotting()), and we also end up not releasing the
       data space previously reserved through btrfs_check_data_free_space().
       As a consequence the mechanism for synchronizing NOCOW buffered writes
       with snapshotting gets broken.
    
    Fix this by always setting 'only_release_metadata' to false at the start
    of each iteration.
    
    Fixes: 8257b2dc3c1a ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume")
    Fixes: 7ee9e4405f26 ("Btrfs: check if we can nocow if we don't have data space")
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3c4af5633b6772ff51de77dd7343418b7ab109f0
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 12:27:58 2019 +0100

    USB: documentation: flags on usb-storage versus UAS
    
    commit 65cc8bf99349f651a0a2cee69333525fe581f306 upstream.
    
    Document which flags work storage, UAS or both
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20191114112758.32747-4-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: Drop change relating to ALWAYS_SYNC]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6cd822acecf0cd336c2d32efe88e776aae975582
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 12:27:57 2019 +0100

    USB: uas: heed CAPACITY_HEURISTICS
    
    commit 335cbbd5762d5e5c67a8ddd6e6362c2aa42a328f upstream.
    
    There is no need to ignore this flag. We should be as close
    to storage in that regard as makes sense, so honor flags whose
    cost is tiny.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20191114112758.32747-3-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0a03f954ad5dc950ac927b03ee5c8b0e865264ef
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 12:27:56 2019 +0100

    USB: uas: honor flag to avoid CAPACITY16
    
    commit bff000cae1eec750d62e265c4ba2db9af57b17e1 upstream.
    
    Copy the support over from usb-storage to get feature parity
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20191114112758.32747-2-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1cb8156858bfeefb25da84d7e8c7eba285377f26
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Nov 18 10:21:19 2019 +0100

    usb-serial: cp201x: support Mark-10 digital force gauge
    
    commit 347bc8cb26388791c5881a3775cb14a3f765a674 upstream.
    
    Add support for the Mark-10 digital force gauge device to the cp201x
    driver.
    
    Based on a report and a larger patch from Joel Jennings
    
    Reported-by: Joel Jennings <joel.jennings@makeitlabs.com>
    Acked-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 96eb38505a660125aaed335c4db3b097e047355a
Author: Waiman Long <longman@redhat.com>
Date:   Fri Nov 15 11:14:44 2019 -0500

    x86/speculation: Fix incorrect MDS/TAA mitigation status
    
    commit 64870ed1b12e235cfca3f6c6da75b542c973ff78 upstream.
    
    For MDS vulnerable processors with TSX support, enabling either MDS or
    TAA mitigations will enable the use of VERW to flush internal processor
    buffers at the right code path. IOW, they are either both mitigated
    or both not. However, if the command line options are inconsistent,
    the vulnerabilites sysfs files may not report the mitigation status
    correctly.
    
    For example, with only the "mds=off" option:
    
      vulnerabilities/mds:Vulnerable; SMT vulnerable
      vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable
    
    The mds vulnerabilities file has wrong status in this case. Similarly,
    the taa vulnerability file will be wrong with mds mitigation on, but
    taa off.
    
    Change taa_select_mitigation() to sync up the two mitigation status
    and have them turned off if both "mds=off" and "tsx_async_abort=off"
    are present.
    
    Update documentation to emphasize the fact that both "mds=off" and
    "tsx_async_abort=off" have to be specified together for processors that
    are affected by both TAA and MDS to be effective.
    
     [ bp: Massage and add kernel-parameters.txt change too. ]
    
    Fixes: 1b42f017415b ("x86/speculation/taa: Add mitigation for TSX Async Abort")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: linux-doc@vger.kernel.org
    Cc: Mark Gross <mgross@linux.intel.com>
    Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Tyler Hicks <tyhicks@canonical.com>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/20191115161445.30809-2-longman@redhat.com
    [bwh: Backported to 3.16: adjust filenames]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8dd558881e0f4d6942c19bd8f7b1a7c19becb59e
Author: Yang Tao <yang.tao172@zte.com.cn>
Date:   Wed Nov 6 22:55:35 2019 +0100

    futex: Prevent robust futex exit race
    
    commit ca16d5bee59807bf04deaab0a8eccecd5061528c upstream.
    
    Robust futexes utilize the robust_list mechanism to allow the kernel to
    release futexes which are held when a task exits. The exit can be voluntary
    or caused by a signal or fault. This prevents that waiters block forever.
    
    The futex operations in user space store a pointer to the futex they are
    either locking or unlocking in the op_pending member of the per task robust
    list.
    
    After a lock operation has succeeded the futex is queued in the robust list
    linked list and the op_pending pointer is cleared.
    
    After an unlock operation has succeeded the futex is removed from the
    robust list linked list and the op_pending pointer is cleared.
    
    The robust list exit code checks for the pending operation and any futex
    which is queued in the linked list. It carefully checks whether the futex
    value is the TID of the exiting task. If so, it sets the OWNER_DIED bit and
    tries to wake up a potential waiter.
    
    This is race free for the lock operation but unlock has two race scenarios
    where waiters might not be woken up. These issues can be observed with
    regular robust pthread mutexes. PI aware pthread mutexes are not affected.
    
    (1) Unlocking task is killed after unlocking the futex value in user space
        before being able to wake a waiter.
    
            pthread_mutex_unlock()
                    |
                    V
            atomic_exchange_rel (&mutex->__data.__lock, 0)
                            <------------------------killed
                lll_futex_wake ()                   |
                                                    |
                                                    |(__lock = 0)
                                                    |(enter kernel)
                                                    |
                                                    V
                                                do_exit()
                                                exit_mm()
                                              mm_release()
                                            exit_robust_list()
                                            handle_futex_death()
                                                    |
                                                    |(__lock = 0)
                                                    |(uval = 0)
                                                    |
                                                    V
            if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr))
                    return 0;
    
        The sanity check which ensures that the user space futex is owned by
        the exiting task prevents the wakeup of waiters which in consequence
        block infinitely.
    
    (2) Waiting task is killed after a wakeup and before it can acquire the
        futex in user space.
    
            OWNER                         WAITER
                                    futex_wait()
       pthread_mutex_unlock()               |
                    |                       |
                    |(__lock = 0)           |
                    |                       |
                    V                       |
             futex_wake() ------------>  wakeup()
                                            |
                                            |(return to userspace)
                                            |(__lock = 0)
                                            |
                                            V
                            oldval = mutex->__data.__lock
                                              <-----------------killed
        atomic_compare_and_exchange_val_acq (&mutex->__data.__lock,  |
                            id | assume_other_futex_waiters, 0)      |
                                                                     |
                                                                     |
                                                       (enter kernel)|
                                                                     |
                                                                     V
                                                             do_exit()
                                                            |
                                                            |
                                                            V
                                            handle_futex_death()
                                            |
                                            |(__lock = 0)
                                            |(uval = 0)
                                            |
                                            V
            if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr))
                    return 0;
    
        The sanity check which ensures that the user space futex is owned
        by the exiting task prevents the wakeup of waiters, which seems to
        be correct as the exiting task does not own the futex value, but
        the consequence is that other waiters wont be woken up and block
        infinitely.
    
    In both scenarios the following conditions are true:
    
       - task->robust_list->list_op_pending != NULL
       - user space futex value == 0
       - Regular futex (not PI)
    
    If these conditions are met then it is reasonably safe to wake up a
    potential waiter in order to prevent the above problems.
    
    As this might be a false positive it can cause spurious wakeups, but the
    waiter side has to handle other types of unrelated wakeups, e.g. signals
    gracefully anyway. So such a spurious wakeup will not affect the
    correctness of these operations.
    
    This workaround must not touch the user space futex value and cannot set
    the OWNER_DIED bit because the lock value is 0, i.e. uncontended. Setting
    OWNER_DIED in this case would result in inconsistent state and subsequently
    in malfunction of the owner died handling in user space.
    
    The rest of the user space state is still consistent as no other task can
    observe the list_op_pending entry in the exiting tasks robust list.
    
    The eventually woken up waiter will observe the uncontended lock value and
    take it over.
    
    [ tglx: Massaged changelog and comment. Made the return explicit and not
            depend on the subsequent check and added constants to hand into
            handle_futex_death() instead of plain numbers. Fixed a few coding
            style issues. ]
    
    Fixes: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core")
    Signed-off-by: Yang Tao <yang.tao172@zte.com.cn>
    Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/1573010582-35297-1-git-send-email-wang.yi59@zte.com.cn
    Link: https://lkml.kernel.org/r/20191106224555.943191378@linutronix.de
    [bwh: Backported to 3.16: Implementation is split between futex.c and
     futex_compat.c, with common definitions in <linux/futex.h>]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fcfd497726f084c9cabd71546329cd1ae7ec32f9
Author: Fabio D'Urso <fabiodurso@hotmail.it>
Date:   Thu Nov 14 01:30:53 2019 +0000

    USB: serial: ftdi_sio: add device IDs for U-Blox C099-F9P
    
    commit c1a1f273d0825774c80896b8deb1c9ea1d0b91e3 upstream.
    
    This device presents itself as a USB hub with three attached devices:
     - An ACM serial port connected to the GPS module (not affected by this
       commit)
     - An FTDI serial port connected to the GPS module (1546:0502)
     - Another FTDI serial port connected to the ODIN-W2 radio module
       (1546:0503)
    
    This commit registers U-Blox's VID and the PIDs of the second and third
    devices.
    
    Datasheet: https://www.u-blox.com/sites/default/files/C099-F9P-AppBoard-Mbed-OS3-FW_UserGuide_%28UBX-18063024%29.pdf
    
    Signed-off-by: Fabio D'Urso <fabiodurso@hotmail.it>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d66ce4236969253689654d0b177e135cfde98523
Author: Jann Horn <jannh@google.com>
Date:   Fri Oct 18 22:56:31 2019 +0200

    binder: Handle start==NULL in binder_update_page_range()
    
    commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream.
    
    The old loop wouldn't stop when reaching `start` if `start==NULL`, instead
    continuing backwards to index -1 and crashing.
    
    Luckily you need to be highly privileged to map things at NULL, so it's not
    a big problem.
    
    Fix it by adjusting the loop so that the loop variable is always in bounds.
    
    This patch is deliberately minimal to simplify backporting, but IMO this
    function could use a refactor. The jump labels in the second loop body are
    horrible (the error gotos should be jumping to free_range instead), and
    both loops would look nicer if they just iterated upwards through indices.
    And the up_read()+mmput() shouldn't be duplicated like that.
    
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Link: https://lore.kernel.org/r/20191018205631.248274-3-jannh@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: There is no continue statement in the loop,
     so we only need to check the exit condition at the bottom]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 318d6e448f95a07d903f017339a129828d5fac6f
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Nov 5 13:46:32 2019 -0800

    RDMA/srpt: Report the SCSI residual to the initiator
    
    commit e88982ad1bb12db699de96fbc07096359ef6176c upstream.
    
    The code added by this patch is similar to the code that already exists in
    ibmvscsis_determine_resid(). This patch has been tested by running the
    following command:
    
    strace sg_raw -r 1k /dev/sdb 12 00 00 00 60 00 -o inquiry.bin |&
        grep resid=
    
    Link: https://lore.kernel.org/r/20191105214632.183302-1-bvanassche@acm.org
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Acked-by: Honggang Li <honli@redhat.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2e08b136c519d0fc2b7fbca5945c5580f1edc85c
Author: Peng Fan <peng.fan@nxp.com>
Date:   Wed Nov 13 05:37:42 2019 +0000

    tty: serial: pch_uart: correct usage of dma_unmap_sg
    
    commit 74887542fdcc92ad06a48c0cca17cdf09fc8aa00 upstream.
    
    Per Documentation/DMA-API-HOWTO.txt,
    To unmap a scatterlist, just call:
            dma_unmap_sg(dev, sglist, nents, direction);
    
    .. note::
    
            The 'nents' argument to the dma_unmap_sg call must be
            the _same_ one you passed into the dma_map_sg call,
            it should _NOT_ be the 'count' value _returned_ from the
            dma_map_sg call.
    
    However in the driver, priv->nent is directly assigned with value
    returned from dma_map_sg, and dma_unmap_sg use priv->nent for unmap,
    this breaks the API usage.
    
    So introduce a new entry orig_nent to remember 'nents'.
    
    Fixes: da3564ee027e ("pch_uart: add multi-scatter processing")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/1573623259-6339-1-git-send-email-peng.fan@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 861a5cb690b406aef255f728b551b91fc8729f1e
Author: Peng Fan <peng.fan@nxp.com>
Date:   Thu Nov 7 06:42:53 2019 +0000

    tty: serial: imx: use the sg count from dma_map_sg
    
    commit 596fd8dffb745afcebc0ec6968e17fe29f02044c upstream.
    
    The dmaengine_prep_slave_sg needs to use sg count returned
    by dma_map_sg, not use sport->dma_tx_nents, because the return
    value of dma_map_sg is not always same with "nents".
    
    Fixes: b4cdc8f61beb ("serial: imx: add DMA support for imx6q")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/1573108875-26530-1-git-send-email-peng.fan@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4d2553bdba0e55750a773c768f2d8b155bc63912
Author: James Smart <jsmart2021@gmail.com>
Date:   Mon Nov 11 15:03:57 2019 -0800

    scsi: lpfc: fix: Coverity: lpfc_cmpl_els_rsp(): Null pointer dereferences
    
    commit 6c6d59e0fe5b86cf273d6d744a6a9768c4ecc756 upstream.
    
    Coverity reported the following:
    
    *** CID 101747:  Null pointer dereferences  (FORWARD_NULL)
    /drivers/scsi/lpfc/lpfc_els.c: 4439 in lpfc_cmpl_els_rsp()
    4433                            kfree(mp);
    4434                    }
    4435                    mempool_free(mbox, phba->mbox_mem_pool);
    4436            }
    4437     out:
    4438            if (ndlp && NLP_CHK_NODE_ACT(ndlp)) {
    vvv     CID 101747:  Null pointer dereferences  (FORWARD_NULL)
    vvv     Dereferencing null pointer "shost".
    4439                    spin_lock_irq(shost->host_lock);
    4440                    ndlp->nlp_flag &= ~(NLP_ACC_REGLOGIN | NLP_RM_DFLT_RPI);
    4441                    spin_unlock_irq(shost->host_lock);
    4442
    4443                    /* If the node is not being used by another discovery thread,
    4444                     * and we are sending a reject, we are done with it.
    
    Fix by adding a check for non-null shost in line 4438.
    The scenario when shost is set to null is when ndlp is null.
    As such, the ndlp check present was sufficient. But better safe
    than sorry so add the shost check.
    
    Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
    Addresses-Coverity-ID: 101747 ("Null pointer dereferences")
    Fixes: 2e0fef85e098 ("[SCSI] lpfc: NPIV: split ports")
    
    CC: James Bottomley <James.Bottomley@SteelEye.com>
    CC: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
    CC: linux-next@vger.kernel.org
    Link: https://lore.kernel.org/r/20191111230401.12958-3-jsmart2021@gmail.com
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fcc4ea89f22ec73f79796effb3ac038056eae5f6
Author: Pawel Harlozinski <pawel.harlozinski@linux.intel.com>
Date:   Tue Nov 12 14:02:36 2019 +0100

    ASoC: Jack: Fix NULL pointer dereference in snd_soc_jack_report
    
    commit 8f157d4ff039e03e2ed4cb602eeed2fd4687a58f upstream.
    
    Check for existance of jack before tracing.
    NULL pointer dereference has been reported by KASAN while unloading
    machine driver (snd_soc_cnl_rt274).
    
    Signed-off-by: Pawel Harlozinski <pawel.harlozinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20191112130237.10141-1-pawel.harlozinski@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 675ed04ec6599b0ad1233111cd1ec1f10432565c
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Nov 12 11:49:04 2019 +0100

    fuse: verify nlink
    
    commit c634da718db9b2fac201df2ae1b1b095344ce5eb upstream.
    
    When adding a new hard link, make sure that i_nlink doesn't overflow.
    
    Fixes: ac45d61357e8 ("fuse: fix nlink after unlink")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9767e04c1124eb66aed6e3f6e5edf4fea7b2c8a7
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Nov 12 11:49:04 2019 +0100

    fuse: verify attributes
    
    commit eb59bd17d2fa6e5e84fba61a5ebdea984222e6d5 upstream.
    
    If a filesystem returns negative inode sizes, future reads on the file were
    causing the cpu to spin on truncate_pagecache.
    
    Create a helper to validate the attributes.  This now does two things:
    
     - check the file mode
     - check if the file size fits in i_size without overflowing
    
    Reported-by: Arijit Banerjee <arijit@rubrik.com>
    Fixes: d8a5ba45457e ("[PATCH] FUSE - core")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 222ba5d8fc9df44eecf85fcaf2bcde1e31aa5aba
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 7 14:21:19 2019 +0100

    USB: serial: mos7840: fix remote wakeup
    
    commit 92fe35fb9c70a00d8fbbf5bd6172c921dd9c7815 upstream.
    
    The driver was setting the device remote-wakeup feature during probe in
    violation of the USB specification (which says it should only be set
    just prior to suspending the device). This could potentially waste
    power during suspend as well as lead to spurious wakeups.
    
    Note that USB core would clear the remote-wakeup feature at first
    resume.
    
    Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 67d0ccacbd36ef3d85cfbe4eff5b0e5909b87327
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 7 14:21:18 2019 +0100

    USB: serial: mos7720: fix remote wakeup
    
    commit ea422312a462696093b5db59d294439796cba4ad upstream.
    
    The driver was setting the device remote-wakeup feature during probe in
    violation of the USB specification (which says it should only be set
    just prior to suspending the device). This could potentially waste
    power during suspend as well as lead to spurious wakeups.
    
    Note that USB core would clear the remote-wakeup feature at first
    resume.
    
    Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6a33a47caa502fb246a6aff7d0a53419c418515e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Nov 11 13:32:03 2019 +0000

    drm/i915/userptr: Try to acquire the page lock around set_page_dirty()
    
    commit cee7fb437edcdb2f9f8affa959e274997f5dca4d upstream.
    
    set_page_dirty says:
    
            For pages with a mapping this should be done under the page lock
            for the benefit of asynchronous memory errors who prefer a
            consistent dirty state. This rule can be broken in some special
            cases, but should be better not to.
    
    Under those rules, it is only safe for us to use the plain set_page_dirty
    calls for shmemfs/anonymous memory. Userptr may be used with real
    mappings and so needs to use the locked version (set_page_dirty_lock).
    
    However, following a try_to_unmap() we may want to remove the userptr and
    so call put_pages(). However, try_to_unmap() acquires the page lock and
    so we must avoid recursively locking the pages ourselves -- which means
    that we cannot safely acquire the lock around set_page_dirty(). Since we
    can't be sure of the lock, we have to risk skip dirtying the page, or
    else risk calling set_page_dirty() without a lock and so risk fs
    corruption.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012
    Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
    References: cb6d7c7dc7ff ("drm/i915/userptr: Acquire the page lock around set_page_dirty()")
    References: 505a8ec7e11a ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"")
    References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk
    (cherry picked from commit 0d4bbe3d407f79438dc4f87943db21f7134cfc65)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 82caf4a6e0beba9a2f44e151ce68e24d8b14d297
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Mon Oct 28 17:33:49 2019 +0100

    iio: adis16480: Add debugfs_reg_access entry
    
    commit 4c35b7a51e2f291471f7221d112c6a45c63e83bc upstream.
    
    The driver is defining debugfs entries by calling
    `adis16480_debugfs_init()`. However, those entries are attached to the
    iio_dev debugfs entry which won't exist if no debugfs_reg_access
    callback is provided.
    
    Fixes: 2f3abe6cbb6c ("iio:imu: Add support for the ADIS16480 and similar IMUs")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b3e113e8b253025b06efa07bc194ccf0db4bc26
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Nov 7 10:30:42 2019 -0800

    inetpeer: fix data-race in inet_putpeer / inet_putpeer
    
    commit 71685eb4ce80ae9c49eff82ca4dd15acab215de9 upstream.
    
    We need to explicitely forbid read/store tearing in inet_peer_gc()
    and inet_putpeer().
    
    The following syzbot report reminds us about inet_putpeer()
    running without a lock held.
    
    BUG: KCSAN: data-race in inet_putpeer / inet_putpeer
    
    write to 0xffff888121fb2ed0 of 4 bytes by interrupt on cpu 0:
     inet_putpeer+0x37/0xa0 net/ipv4/inetpeer.c:240
     ip4_frag_free+0x3d/0x50 net/ipv4/ip_fragment.c:102
     inet_frag_destroy_rcu+0x58/0x80 net/ipv4/inet_fragment.c:228
     __rcu_reclaim kernel/rcu/rcu.h:222 [inline]
     rcu_do_batch+0x256/0x5b0 kernel/rcu/tree.c:2157
     rcu_core+0x369/0x4d0 kernel/rcu/tree.c:2377
     rcu_core_si+0x12/0x20 kernel/rcu/tree.c:2386
     __do_softirq+0x115/0x33f kernel/softirq.c:292
     invoke_softirq kernel/softirq.c:373 [inline]
     irq_exit+0xbb/0xe0 kernel/softirq.c:413
     exiting_irq arch/x86/include/asm/apic.h:536 [inline]
     smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
     apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
     native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
     arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
     default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
     cpuidle_idle_call kernel/sched/idle.c:154 [inline]
     do_idle+0x1af/0x280 kernel/sched/idle.c:263
    
    write to 0xffff888121fb2ed0 of 4 bytes by interrupt on cpu 1:
     inet_putpeer+0x37/0xa0 net/ipv4/inetpeer.c:240
     ip4_frag_free+0x3d/0x50 net/ipv4/ip_fragment.c:102
     inet_frag_destroy_rcu+0x58/0x80 net/ipv4/inet_fragment.c:228
     __rcu_reclaim kernel/rcu/rcu.h:222 [inline]
     rcu_do_batch+0x256/0x5b0 kernel/rcu/tree.c:2157
     rcu_core+0x369/0x4d0 kernel/rcu/tree.c:2377
     rcu_core_si+0x12/0x20 kernel/rcu/tree.c:2386
     __do_softirq+0x115/0x33f kernel/softirq.c:292
     run_ksoftirqd+0x46/0x60 kernel/softirq.c:603
     smpboot_thread_fn+0x37d/0x4a0 kernel/smpboot.c:165
     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: 16 Comm: ksoftirqd/1 Not tainted 5.4.0-rc3+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 4b9d9be839fd ("inetpeer: remove unused list")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16:
     - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()
     - Adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ceba7e469ff0b6e0a3e10ae98972d13571e7eef
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Wed Nov 6 18:31:25 2019 +0100

    regulator: ab8500: Remove SYSCLKREQ from enum ab8505_regulator_id
    
    commit 458ea3ad033fc86e291712ce50cbe60c3428cf30 upstream.
    
    Those regulators are not actually supported by the AB8500 regulator
    driver. There is no ab8500_regulator_info for them and no entry in
    ab8505_regulator_match.
    
    As such, they cannot be registered successfully, and looking them
    up in ab8505_regulator_match causes an out-of-bounds array read.
    
    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-2-stephan@gerhold.net
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 25cbaf8e7a6265d49d20bd40e24329dc51900a6b
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: Ben Hutchings <ben@decadent.org.uk>

commit 6e05c0e0442bb5e39ae5498879c0f307cceb5717
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Mar 18 16:15:47 2016 +0100

    ARM: ux500: remove unused regulator data
    
    commit 37dc78d9b17c971479f742d6d08f38d8f2beb688 upstream.
    
    Most of the board-mop500-regulators.c file is never referenced and
    can simply be removed.
    
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.16 as dependency of commit 99c4f70df3a6
     "regulator: ab8500: Remove AB8505 USB regulator"]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

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

    powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GB
    
    commit f9ec11165301982585e5e5f606739b5bae5331f3 upstream.
    
    When calling __kernel_sync_dicache with a size >4GB, we were masking
    off the upper 32 bits, so we would incorrectly flush a range smaller
    than intended.
    
    This patch replaces the 32 bit shifts with 64 bit ones, so that
    the full size is accounted for.
    
    Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191104023305.9581-3-alastair@au1.ibm.com
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

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

    powerpc: Allow flush_icache_range to work across ranges >4GB
    
    commit 29430fae82073d39b1b881a3cd507416a56a363f upstream.
    
    When calling flush_icache_range with a size >4GB, we were masking
    off the upper 32 bits, so we would incorrectly flush a range smaller
    than intended.
    
    This patch replaces the 32 bit shifts with 64 bit ones, so that
    the full size is accounted for.
    
    Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191104023305.9581-2-alastair@au1.ibm.com
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b2a8a434fd5b05e3b35514f935bf5944c6362b80
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Oct 30 16:09:49 2019 +0900

    perf probe: Skip overlapped location on searching variables
    
    commit dee36a2abb67c175265d49b9a8c7dfa564463d9a upstream.
    
    Since debuginfo__find_probes() callback function can be called with  the
    location which already passed, the callback function must filter out
    such overlapped locations.
    
    add_probe_trace_event() has already done it by commit 1a375ae7659a
    ("perf probe: Skip same probe address for a given line"), but
    add_available_vars() doesn't. Thus perf probe -v shows same address
    repeatedly as below:
    
      # perf probe -V vfs_read:18
      Available variables at vfs_read:18
              @<vfs_read+217>
                      char*   buf
                      loff_t* pos
                      ssize_t ret
                      struct file*    file
              @<vfs_read+217>
                      char*   buf
                      loff_t* pos
                      ssize_t ret
                      struct file*    file
              @<vfs_read+226>
                      char*   buf
                      loff_t* pos
                      ssize_t ret
                      struct file*    file
    
    With this fix, perf probe -V shows it correctly:
    
      # perf probe -V vfs_read:18
      Available variables at vfs_read:18
              @<vfs_read+217>
                      char*   buf
                      loff_t* pos
                      ssize_t ret
                      struct file*    file
              @<vfs_read+226>
                      char*   buf
                      loff_t* pos
                      ssize_t ret
                      struct file*    file
    
    Fixes: cf6eb489e5c0 ("perf probe: Show accessible local variables")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157241938927.32002.4026859017790562751.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6d69113c2291b0558485d88a8c14e94672ad5b06
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Oct 30 16:09:40 2019 +0900

    perf probe: Fix to show calling lines of inlined functions
    
    commit 86c0bf8539e7f46d91bd105e55eda96e0064caef upstream.
    
    Fix to show calling lines of inlined functions (where an inline function
    is called).
    
    die_walk_lines() filtered out the lines inside inlined functions based
    on the address. However this also filtered out the lines which call
    those inlined functions from the target function.
    
    To solve this issue, check the call_file and call_line attributes and do
    not filter out if it matches to the line information.
    
    Without this fix, perf probe -L doesn't show some lines correctly.
    (don't see the lines after 17)
    
      # perf probe -L vfs_read
      <vfs_read@/home/mhiramat/ksrc/linux/fs/read_write.c:0>
            0  ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
            1  {
            2         ssize_t ret;
    
            4         if (!(file->f_mode & FMODE_READ))
                              return -EBADF;
            6         if (!(file->f_mode & FMODE_CAN_READ))
                              return -EINVAL;
            8         if (unlikely(!access_ok(buf, count)))
                              return -EFAULT;
    
           11         ret = rw_verify_area(READ, file, pos, count);
           12         if (!ret) {
           13                 if (count > MAX_RW_COUNT)
                                      count =  MAX_RW_COUNT;
           15                 ret = __vfs_read(file, buf, count, pos);
           16                 if (ret > 0) {
                                      fsnotify_access(file);
                                      add_rchar(current, ret);
                              }
    
    With this fix:
    
      # perf probe -L vfs_read
      <vfs_read@/home/mhiramat/ksrc/linux/fs/read_write.c:0>
            0  ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
            1  {
            2         ssize_t ret;
    
            4         if (!(file->f_mode & FMODE_READ))
                              return -EBADF;
            6         if (!(file->f_mode & FMODE_CAN_READ))
                              return -EINVAL;
            8         if (unlikely(!access_ok(buf, count)))
                              return -EFAULT;
    
           11         ret = rw_verify_area(READ, file, pos, count);
           12         if (!ret) {
           13                 if (count > MAX_RW_COUNT)
                                      count =  MAX_RW_COUNT;
           15                 ret = __vfs_read(file, buf, count, pos);
           16                 if (ret > 0) {
           17                         fsnotify_access(file);
           18                         add_rchar(current, ret);
                              }
           20                 inc_syscr(current);
                      }
    
    Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157241937995.32002.17899884017011512577.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cdcff2bc0299a10741dd0f45d5e9a185757d3d46
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Oct 30 16:09:30 2019 +0900

    perf probe: Filter out instances except for inlined subroutine and subprogram
    
    commit da6cb952a89efe24bb76c4971370d485737a2d85 upstream.
    
    Filter out instances except for inlined_subroutine and subprogram DIE in
    die_walk_instances() and die_is_func_instance().
    
    This fixes an issue that perf probe sets some probes on calling address
    instead of a target function itself.
    
    When perf probe walks on instances of an abstruct origin (a kind of
    function prototype of inlined function), die_walk_instances() can also
    pass a GNU_call_site (a GNU extension for call site) to callback. Since
    it is not an inlined instance of target function, we have to filter out
    when searching a probe point.
    
    Without this patch, perf probe sets probes on call site address too.This
    can happen on some function which is marked "inlined", but has actual
    symbol. (I'm not sure why GCC mark it "inlined"):
    
      # perf probe -D vfs_read
      p:probe/vfs_read _text+2500017
      p:probe/vfs_read_1 _text+2499468
      p:probe/vfs_read_2 _text+2499563
      p:probe/vfs_read_3 _text+2498876
      p:probe/vfs_read_4 _text+2498512
      p:probe/vfs_read_5 _text+2498627
    
    With this patch:
    
    Slightly different results, similar tho:
    
      # perf probe -D vfs_read
      p:probe/vfs_read _text+2498512
    
    Committer testing:
    
      # uname -a
      Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    
    Before:
    
      # perf probe -D vfs_read
      p:probe/vfs_read _text+3131557
      p:probe/vfs_read_1 _text+3130975
      p:probe/vfs_read_2 _text+3131047
      p:probe/vfs_read_3 _text+3130380
      p:probe/vfs_read_4 _text+3130000
      # uname -a
      Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
      #
    
    After:
    
      # perf probe -D vfs_read
      p:probe/vfs_read _text+3130000
      #
    
    Fixes: db0d2c6420ee ("perf probe: Search concrete out-of-line instances")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157241937063.32002.11024544873990816590.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41e959c25d01ce5feb71c0996817dff797f7198b
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Oct 30 16:09:21 2019 +0900

    perf probe: Skip end-of-sequence and non statement lines
    
    commit f4d99bdfd124823a81878b44b5e8750b97f73902 upstream.
    
    Skip end-of-sequence and non-statement lines while walking through lines
    list.
    
    The "end-of-sequence" line information means:
    
     "the current address is that of the first byte after the
      end of a sequence of target machine instructions."
     (DWARF version 4 spec 6.2.2)
    
    This actually means out of scope and we can not probe on it.
    
    On the other hand, the statement lines (is_stmt) means:
    
     "the current instruction is a recommended breakpoint location.
      A recommended breakpoint location is intended to “represent”
      a line, a statement and/or a semantically distinct subpart
      of a statement."
    
     (DWARF version 4 spec 6.2.2)
    
    So, non-statement line info also should be skipped.
    
    These can reduce unneeded probe points and also avoid an error.
    
    E.g. without this patch:
    
      # perf probe -a "clear_tasks_mm_cpumask:1"
      Added new events:
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
        probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:1)
        probe:clear_tasks_mm_cpumask_2 (on clear_tasks_mm_cpumask:1)
        probe:clear_tasks_mm_cpumask_3 (on clear_tasks_mm_cpumask:1)
        probe:clear_tasks_mm_cpumask_4 (on clear_tasks_mm_cpumask:1)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:clear_tasks_mm_cpumask_4 -aR sleep 1
    
      #
    
    This puts 5 probes on one line, but acutally it's not inlined function.
    This is because there are many non statement instructions at the
    function prologue.
    
    With this patch:
    
      # perf probe -a "clear_tasks_mm_cpumask:1"
      Added new event:
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
    
      #
    
    Now perf-probe skips unneeded addresses.
    
    Committer testing:
    
    Slightly different results, but similar:
    
    Before:
    
      # uname -a
      Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
      #
      # perf probe -a "clear_tasks_mm_cpumask:1"
      Added new events:
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
        probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:1)
        probe:clear_tasks_mm_cpumask_2 (on clear_tasks_mm_cpumask:1)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:clear_tasks_mm_cpumask_2 -aR sleep 1
    
      #
    
    After:
    
      # perf probe -a "clear_tasks_mm_cpumask:1"
      Added new event:
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
    
      # perf probe -l
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c)
      #
    
    Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157241936090.32002.12156347518596111660.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 202424b6493645e8315af03fbf10068acee425bb
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Nov 6 13:49:01 2019 +0100

    appledisplay: fix error handling in the scheduled work
    
    commit 91feb01596e5efc0cc922cc73f5583114dccf4d2 upstream.
    
    The work item can operate on
    
    1. stale memory left over from the last transfer
    the actual length of the data transfered needs to be checked
    2. memory already freed
    the error handling in appledisplay_probe() needs
    to cancel the work in that case
    
    Reported-and-tested-by: syzbot+495dab1f175edc9c2f13@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20191106124902.7765-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d1a595ab1cefd3ee9211b08b49c367b039a4e5df
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Nov 6 14:27:10 2019 +0800

    usb: Allow USB device to be warm reset in suspended state
    
    commit e76b3bf7654c3c94554c24ba15a3d105f4006c80 upstream.
    
    On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging
    cable to the ethernet port, the hub and roothub get runtime resumed and
    runtime suspended immediately:
    ...
    [  433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
    [  433.315204] usb usb4: usb auto-resume
    [  433.315226] hub 4-0:1.0: hub_resume
    [  433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343
    [  433.315264] usb usb4-port1: status 0343 change 0001
    [  433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2
    [  433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0
    [  433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
    [  433.422307] usb usb4-port1: do warm reset
    [  433.422311] usb 4-1: device reset not allowed in state 8
    [  433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000
    [  433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
    [  433.422356] usb usb4-port1: do warm reset
    [  433.422358] usb 4-1: device reset not allowed in state 8
    [  433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status  = 0xf0002e2
    [  433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
    [  433.422465] hub 4-0:1.0: hub_suspend
    [  433.422475] usb usb4: bus auto-suspend, wakeup 1
    [  433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling.
    [  433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
    [  433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0
    [  433.862445] xhci_hcd 0000:3a:00.0: PME# enabled
    [  433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20)
    [  433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403)
    [  433.902490] xhci_hcd 0000:3a:00.0: PME# disabled
    [  433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering
    [  433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
    [  433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt!
    [  433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2
    [  433.902842] xhci_hcd 0000:3a:00.0: resume root hub
    [  433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling.
    [  433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling.
    [  433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
    [  433.902919] usb usb4: usb wakeup-resume
    [  433.902942] usb usb4: usb auto-resume
    [  433.902966] hub 4-0:1.0: hub_resume
    ...
    
    As Mathias pointed out, the hub enters Cold Attach Status state and
    requires a warm reset. However usb_reset_device() bails out early when
    the device is in suspended state, as its callers port_event() and
    hub_event() don't always resume the device.
    
    Since there's nothing wrong to reset a suspended device, allow
    usb_reset_device() to do so to solve the issue.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 28f455a3b499735970d1bb1dc78ca287e52dcb78
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Nov 6 14:28:21 2019 -0600

    usb: gadget: pch_udc: fix use after free
    
    commit 66d1b0c0580b7f1b1850ee4423f32ac42afa2e92 upstream.
    
    Remove pointer dereference after free.
    
    pci_pool_free doesn't care about contents of td.
    It's just a void* for it
    
    Addresses-Coverity-ID: 1091173 ("Use after free")
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Link: https://lore.kernel.org/r/20191106202821.GA20347@embeddedor
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6983367eb53f597a7d4942d2651dc9541a9a4388
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Oct 25 17:47:01 2019 +0900

    perf probe: Fix to show inlined function callsite without entry_pc
    
    commit 18e21eb671dc87a4f0546ba505a89ea93598a634 upstream.
    
    Fix 'perf probe --line' option to show inlined function callsite lines
    even if the function DIE has only ranges.
    
    Without this:
    
      # perf probe -L amd_put_event_constraints
      ...
          2  {
          3         if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
                            __amd_put_nb_event_constraints(cpuc, event);
          5  }
    
    With this patch:
    
      # perf probe -L amd_put_event_constraints
      ...
          2  {
          3         if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
          4                 __amd_put_nb_event_constraints(cpuc, event);
          5  }
    
    Committer testing:
    
    Before:
    
      [root@quaco ~]# perf probe -L amd_put_event_constraints
      <amd_put_event_constraints@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/arch/x86/events/amd/core.c:0>
            0  static void amd_put_event_constraints(struct cpu_hw_events *cpuc,
                                                    struct perf_event *event)
            2  {
            3         if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
                              __amd_put_nb_event_constraints(cpuc, event);
            5  }
    
               PMU_FORMAT_ATTR(event, "config:0-7,32-35");
               PMU_FORMAT_ATTR(umask, "config:8-15"   );
    
      [root@quaco ~]#
    
    After:
    
      [root@quaco ~]# perf probe -L amd_put_event_constraints
      <amd_put_event_constraints@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/arch/x86/events/amd/core.c:0>
            0  static void amd_put_event_constraints(struct cpu_hw_events *cpuc,
                                                    struct perf_event *event)
            2  {
            3         if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
            4                 __amd_put_nb_event_constraints(cpuc, event);
            5  }
    
               PMU_FORMAT_ATTR(event, "config:0-7,32-35");
               PMU_FORMAT_ATTR(umask, "config:8-15"   );
    
      [root@quaco ~]# perf probe amd_put_event_constraints:4
      Added new event:
        probe:amd_put_event_constraints (on amd_put_event_constraints:4)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:amd_put_event_constraints -aR sleep 1
    
      [root@quaco ~]#
    
      [root@quaco ~]# perf probe -l
        probe:amd_put_event_constraints (on amd_put_event_constraints:4@arch/x86/events/amd/core.c)
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c)
      [root@quaco ~]#
    
    Using it:
    
      [root@quaco ~]# perf trace -e probe:*
      ^C[root@quaco ~]#
    
    Ok, Intel system here... :-)
    
    Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157199322107.8075.12659099000567865708.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f44ad9b035649faac40ff0796f41be24d615bf86
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Oct 25 17:46:52 2019 +0900

    perf probe: Fix to list probe event with correct line number
    
    commit 3895534dd78f0fd4d3f9e05ee52b9cdd444a743e upstream.
    
    Since debuginfo__find_probe_point() uses dwarf_entrypc() for finding the
    entry address of the function on which a probe is, it will fail when the
    function DIE has only ranges attribute.
    
    To fix this issue, use die_entrypc() instead of dwarf_entrypc().
    
    Without this fix, perf probe -l shows incorrect offset:
    
      # perf probe -l
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask+18446744071579263632@work/linux/linux/kernel/cpu.c)
        probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask+18446744071579263752@work/linux/linux/kernel/cpu.c)
    
    With this:
    
      # perf probe -l
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@work/linux/linux/kernel/cpu.c)
        probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:21@work/linux/linux/kernel/cpu.c)
    
    Committer testing:
    
    Before:
    
      [root@quaco ~]# perf probe -l
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask+18446744071579765152@kernel/cpu.c)
      [root@quaco ~]#
    
    After:
    
      [root@quaco ~]# perf probe -l
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c)
      [root@quaco ~]#
    
    Fixes: 1d46ea2a6a40 ("perf probe: Fix listing incorrect line number with inline function")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157199321227.8075.14655572419136993015.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9dbe57e479ee6a0ce3dc1951f2f86b5c09607162
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Oct 25 17:46:43 2019 +0900

    perf probe: Fix to probe an inline function which has no entry pc
    
    commit eb6933b29d20bf2c3053883d409a53f462c1a3ac upstream.
    
    Fix perf probe to probe an inlne function which has no entry pc
    or low pc but only has ranges attribute.
    
    This seems very rare case, but I could find a few examples, as
    same as probe_point_search_cb(), use die_entrypc() to get the
    entry address in probe_point_inline_cb() too.
    
    Without this patch:
    
      # perf probe -D __amd_put_nb_event_constraints
      Failed to get entry address of __amd_put_nb_event_constraints.
      Probe point '__amd_put_nb_event_constraints' not found.
        Error: Failed to add events.
    
    With this patch:
    
      # perf probe -D __amd_put_nb_event_constraints
      p:probe/__amd_put_nb_event_constraints amd_put_event_constraints+43
    
    Committer testing:
    
    Before:
    
      [root@quaco ~]# perf probe -D __amd_put_nb_event_constraints
      Failed to get entry address of __amd_put_nb_event_constraints.
      Probe point '__amd_put_nb_event_constraints' not found.
        Error: Failed to add events.
      [root@quaco ~]#
    
    After:
    
      [root@quaco ~]# perf probe -D __amd_put_nb_event_constraints
      p:probe/__amd_put_nb_event_constraints _text+33789
      [root@quaco ~]#
    
    Fixes: 4ea42b181434 ("perf: Add perf probe subcommand, a kprobe-event setup helper")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157199320336.8075.16189530425277588587.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 66eee3caf711183eded41949e6866c2db65fe93e
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Oct 25 17:46:34 2019 +0900

    perf probe: Fix to probe a function which has no entry pc
    
    commit 5d16dbcc311d91267ddb45c6da4f187be320ecee upstream.
    
    Fix 'perf probe' to probe a function which has no entry pc or low pc but
    only has ranges attribute.
    
    probe_point_search_cb() uses dwarf_entrypc() to get the probe address,
    but that doesn't work for the function DIE which has only ranges
    attribute. Use die_entrypc() instead.
    
    Without this fix:
    
      # perf probe -k ../build-x86_64/vmlinux -D clear_tasks_mm_cpumask:0
      Probe point 'clear_tasks_mm_cpumask' not found.
        Error: Failed to add events.
    
    With this:
    
      # perf probe -k ../build-x86_64/vmlinux -D clear_tasks_mm_cpumask:0
      p:probe/clear_tasks_mm_cpumask clear_tasks_mm_cpumask+0
    
    Committer testing:
    
    Before:
    
      [root@quaco ~]# perf probe clear_tasks_mm_cpumask:0
      Probe point 'clear_tasks_mm_cpumask' not found.
        Error: Failed to add events.
      [root@quaco ~]#
    
    After:
    
      [root@quaco ~]# perf probe clear_tasks_mm_cpumask:0
      Added new event:
        probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
    
      [root@quaco ~]#
    
    Using it with 'perf trace':
    
      [root@quaco ~]# perf trace -e probe:clear_tasks_mm_cpumask
    
    Doesn't seem to be used in x86_64:
    
      $ find . -name "*.c" | xargs grep clear_tasks_mm_cpumask
      ./kernel/cpu.c: * clear_tasks_mm_cpumask - Safely clear tasks' mm_cpumask for a CPU
      ./kernel/cpu.c:void clear_tasks_mm_cpumask(int cpu)
      ./arch/xtensa/kernel/smp.c:   clear_tasks_mm_cpumask(cpu);
      ./arch/csky/kernel/smp.c:     clear_tasks_mm_cpumask(cpu);
      ./arch/sh/kernel/smp.c:       clear_tasks_mm_cpumask(cpu);
      ./arch/arm/kernel/smp.c:      clear_tasks_mm_cpumask(cpu);
      ./arch/powerpc/mm/nohash/mmu_context.c:       clear_tasks_mm_cpumask(cpu);
      $ find . -name "*.h" | xargs grep clear_tasks_mm_cpumask
      ./include/linux/cpu.h:void clear_tasks_mm_cpumask(int cpu);
      $ find . -name "*.S" | xargs grep clear_tasks_mm_cpumask
      $
    
    Fixes: e1ecbbc3fa83 ("perf probe: Fix to handle optimized not-inlined functions")
    Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157199319438.8075.4695576954550638618.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8bc69eb3c3ac9e706e51a043934b3537352c1d45
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Oct 25 17:46:25 2019 +0900

    perf probe: Fix wrong address verification
    
    commit 07d369857808b7e8e471bbbbb0074a6718f89b31 upstream.
    
    Since there are some DIE which has only ranges instead of the
    combination of entrypc/highpc, address verification must use
    dwarf_haspc() instead of dwarf_entrypc/dwarf_highpc.
    
    Also, the ranges only DIE will have a partial code in different section
    (e.g. unlikely code will be in text.unlikely as "FUNC.cold" symbol). In
    that case, we can not use dwarf_entrypc() or die_entrypc(), because the
    offset from original DIE can be a minus value.
    
    Instead, this simply gets the symbol and offset from symtab.
    
    Without this patch;
    
      # perf probe -D clear_tasks_mm_cpumask:1
      Failed to get entry address of clear_tasks_mm_cpumask
        Error: Failed to add events.
    
    And with this patch:
    
      # perf probe -D clear_tasks_mm_cpumask:1
      p:probe/clear_tasks_mm_cpumask clear_tasks_mm_cpumask+0
      p:probe/clear_tasks_mm_cpumask_1 clear_tasks_mm_cpumask+5
      p:probe/clear_tasks_mm_cpumask_2 clear_tasks_mm_cpumask+8
      p:probe/clear_tasks_mm_cpumask_3 clear_tasks_mm_cpumask+16
      p:probe/clear_tasks_mm_cpumask_4 clear_tasks_mm_cpumask+82
    
    Committer testing:
    
    I managed to reproduce the above:
    
      [root@quaco ~]# perf probe -D clear_tasks_mm_cpumask:1
      p:probe/clear_tasks_mm_cpumask _text+919968
      p:probe/clear_tasks_mm_cpumask_1 _text+919973
      p:probe/clear_tasks_mm_cpumask_2 _text+919976
      [root@quaco ~]#
    
    But then when trying to actually put the probe in place, it fails if I
    use :0 as the offset:
    
      [root@quaco ~]# perf probe -L clear_tasks_mm_cpumask | head -5
      <clear_tasks_mm_cpumask@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/kernel/cpu.c:0>
            0  void clear_tasks_mm_cpumask(int cpu)
            1  {
            2       struct task_struct *p;
    
      [root@quaco ~]# perf probe clear_tasks_mm_cpumask:0
      Probe point 'clear_tasks_mm_cpumask' not found.
        Error: Failed to add events.
      [root@quaco
    
    The next patch is needed to fix this case.
    
    Fixes: 576b523721b7 ("perf probe: Fix probing symbols with optimization suffix")
    Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157199318513.8075.10463906803299647907.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47cf16914939a33576760d0dc556eff2b71f4c0c
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Oct 24 18:12:54 2019 +0900

    perf probe: Fix to show function entry line as probe-able
    
    commit 91e2f539eeda26ab00bd03fae8dc434c128c85ed upstream.
    
    Fix die_walk_lines() to list the function entry line correctly.  Since
    the dwarf_entrypc() does not return the entry pc if the DIE has only
    range attribute, __die_walk_funclines() fails to list the declaration
    line (entry line) in that case.
    
    To solve this issue, this introduces die_entrypc() which correctly
    returns the entry PC (the first address range) even if the DIE has only
    range attribute. With this fix die_walk_lines() shows the function entry
    line is able to probe correctly.
    
    Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157190837419.1859.4619125803596816752.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 76a45335ab86a3fba54d2544391f1c878eda8b7a
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Oct 24 18:12:36 2019 +0900

    perf probe: Fix to find range-only function instance
    
    commit b77afa1f810f37bd8a36cb1318178dfe2d7af6b6 upstream.
    
    Fix die_is_func_instance() to find range-only function instance.
    
    In some case, a function instance can be made without any low PC or
    entry PC, but only with address ranges by optimization.  (e.g. cold text
    partially in "text.unlikely" section) To find such function instance, we
    have to check the range attribute too.
    
    Fixes: e1ecbbc3fa83 ("perf probe: Fix to handle optimized not-inlined functions")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/157190835669.1859.8368628035930950596.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a5c2adfea439b31d97471ebb095e067571bb49b8
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Sat Sep 24 00:35:07 2016 +0900

    perf probe: Skip if the function address is 0
    
    commit 0ad45b33c58dca60dec7e1fb44766753bc4a7a38 upstream.
    
    Skip probes if the entry address of the target function is 0.  This can
    happen when we're handling C++ debuginfo files.
    
    E.g. without this fix, below case still fail.
      ----
      $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD is_open
      probe-definition(0): is_open
      symbol:is_open file:(null) line:0 offset:0 return:0 lazy:(null)
      0 arguments
      symbol:catch file:(null) line:0 offset:0 return:0 lazy:(null)
      symbol:throw file:(null) line:0 offset:0 return:0 lazy:(null)
      symbol:rethrow file:(null) line:0 offset:0 return:0 lazy:(null)
      Open Debuginfo file: /usr/lib/debug/usr/lib64/libstdc++.so.6.0.22.debug
      Try to find probe point from debuginfo.
      Matched function: is_open [295df]
      found inline addr: 0x8ca80
      Probe point found: is_open+0
      found inline addr: 0x8ca70
      Probe point found: is_open+0
      found inline addr: 0x8ca60
      Probe point found: is_open+0
      Matched function: is_open [6527f]
      Matched function: is_open [9fe8a]
      Probe point found: is_open+0
      Matched function: is_open [19710b]
      found inline addr: 0xecca9
      Probe point found: stdio_filebuf+57
      found inline addr: 0x0
      Probe point found: swap+0
      Matched function: is_open [19fc9d]
      Probe point found: is_open+0
      Found 7 probe_trace_events.
      p:probe_libstdc++/is_open /usr/lib64/libstdc++.so.6.0.22:0x8ca80
      p:probe_libstdc++/is_open_1 /usr/lib64/libstdc++.so.6.0.22:0x8ca70
      p:probe_libstdc++/is_open_2 /usr/lib64/libstdc++.so.6.0.22:0x8ca60
      p:probe_libstdc++/is_open_3 /usr/lib64/libstdc++.so.6.0.22:0xb0ad0
      p:probe_libstdc++/is_open_4 /usr/lib64/libstdc++.so.6.0.22:0xecca9
      Failed to synthesize probe trace event.
        Error: Failed to add events. Reason: Invalid argument (Code: -22)
      ----
    This is because some instances have entry_pc == 0 (see 19710b and
    19fc9d). With this fix, those are skipped.
    
      ----
      $ ./perf probe -x /usr/lib64/libstdc++.so.6 -D is_open
      p:probe_libstdc++/is_open /usr/lib64/libstdc++.so.6.0.22:0x8ca80
      p:probe_libstdc++/is_open_1 /usr/lib64/libstdc++.so.6.0.22:0x8ca70
      p:probe_libstdc++/is_open_2 /usr/lib64/libstdc++.so.6.0.22:0x8ca60
      p:probe_libstdc++/is_open_3 /usr/lib64/libstdc++.so.6.0.22:0xb0ad0
      p:probe_libstdc++/is_open_4 /usr/lib64/libstdc++.so.6.0.22:0xecca9
      ----
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Jiri Olsa <jolsa@kernel.org>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/147464490707.29804.14277897643725143867.stgit@devbox
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 92199efb6a15d3e4544ff9317d807cc0358dafe0
Author: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Date:   Thu Aug 13 06:55:41 2015 +0900

    perf probe: Fix to add missed brace around if block
    
    commit 86a76027457633488b0a83d5e2bb944159885605 upstream.
    
    The commit 75186a9b09e4 (perf probe: Fix to show lines of sys_ functions
    correctly) introduced a bug by a missed brace around if block. This
    fixes to add it.
    
    Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Fixes: 75186a9b09e4 ("perf probe: Fix to show lines of sys_ functions correctly")
    Link: http://lkml.kernel.org/r/20150812215541.9088.62425.stgit@localhost.localdomain
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ec3a4559675fd3c1f290db630a46ed46ac82939d
Author: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Date:   Wed Aug 12 10:24:07 2015 +0900

    perf probe: Fix to show lines of sys_ functions correctly
    
    commit 75186a9b09e47072f442f43e292cd47180b67b5c upstream.
    
    "perf probe --lines sys_poll" shows only the first line of sys_poll,
    because the SYSCALL_DEFINE macro:
    
      ----
      SYSCALL_DEFINE*(foo,...)
      {
        body;
      }
      ----
    
      is expanded as below (on debuginfo)
    
      ----
    
      static inline int SYSC_foo(...)
      {
        body;
      }
      int SyS_foo(...) <- is an alias of sys_foo.
      {
        return SYSC_foo(...);
      }
      ----
    
    So, "perf probe --lines sys_foo" decodes SyS_foo function and it also skips
    inlined functions(SYSC_foo) inside the target function because those functions
    are usually defined somewhere else.
    
    To fix this issue, this fix checks whether the inlined function is defined at
    the same point of the target function, and if so, it doesn't skip the inline
    function.
    
    Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
    Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lkml.kernel.org/r/20150812012406.11811.94691.stgit@localhost.localdomain
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 402e1448c9b4474f07cb189a01e0ba6b8150e1d9
Author: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Date:   Fri Jan 30 18:37:44 2015 +0900

    perf probe: Fix to handle optimized not-inlined functions
    
    commit e1ecbbc3fa834cc6b4b344edb1968e734d57189b upstream.
    
    Fix to handle optimized no-inline functions which have only function
    definition but no actual instance at that point.
    
    To fix this problem, we need to find actual instance of the function.
    
    Without this patch:
      ----
      # perf probe -a __up
      Failed to get entry address of __up.
        Error: Failed to add events.
      # perf probe -L __up
      Specified source line is not found.
        Error: Failed to show lines.
      ----
    
    With this patch:
      ----
      # perf probe -a __up
      Added new event:
        probe:__up           (on __up)
    
      You can now use it in all perf tools, such as:
    
              perf record -e probe:__up -aR sleep 1
    
      # perf probe -L __up
      <__up@/home/fedora/ksrc/linux-3/kernel/locking/semaphore.c:0>
            0  static noinline void __sched __up(struct semaphore *sem)
               {
                      struct semaphore_waiter *waiter = list_first_entry(&sem->wait_
                                                              struct semaphore_waite
            4         list_del(&waiter->list);
            5         waiter->up = true;
            6         wake_up_process(waiter->task);
            7  }
      ----
    
    Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20150130093744.30575.43290.stgit@localhost.localdomain
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 557a2bf027052449f9bc6847cecd9960488d9d0b
Author: Pavel Löbl <pavel@loebl.cz>
Date:   Fri Nov 1 08:01:50 2019 +0100

    USB: serial: mos7840: add USB ID to support Moxa UPort 2210
    
    commit e696d00e65e81d46e911f24b12e441037bf11b38 upstream.
    
    Add USB ID for MOXA UPort 2210. This device contains mos7820 but
    it passes GPIO0 check implemented by driver and it's detected as
    mos7840. Hence product id check is added to force mos7820 mode.
    
    Signed-off-by: Pavel Löbl <pavel@loebl.cz>
    [ johan: rename id defines and add vendor-id check ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 98c09aec8d758a53569114971d8f8bfc3a435040
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Nov 5 13:55:53 2019 -0800

    scsi: tracing: Fix handling of TRANSFER LENGTH == 0 for READ(6) and WRITE(6)
    
    commit f6b8540f40201bff91062dd64db8e29e4ddaaa9d upstream.
    
    According to SBC-2 a TRANSFER LENGTH field of zero means that 256 logical
    blocks must be transferred. Make the SCSI tracing code follow SBC-2.
    
    Fixes: bf8162354233 ("[SCSI] add scsi trace core functions and put trace points")
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Link: https://lore.kernel.org/r/20191105215553.185018-1-bvanassche@acm.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1b15668486663120f90d8448512f25a373864eb2
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Tue Sep 24 10:52:23 2019 +0300

    PM / devfreq: Lock devfreq in trans_stat_show
    
    commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream.
    
    There is no locking in this sysfs show function so stats printing can
    race with a devfreq_update_status called as part of freq switching or
    with initialization.
    
    Also add an assert in devfreq_update_status to make it clear that lock
    must be held by caller.
    
    Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats")
    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>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1b5a5b68fe29abd514add600849dd119ec996885
Author: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Date:   Mon Nov 4 21:51:10 2019 -0800

    bnx2x: Enable Multi-Cos feature.
    
    commit 069e47823fff2c634b2d46a328b5096fdc8c2a0c upstream.
    
    FW version 7.13.15 addresses the issue in Multi-cos implementation.
    This patch re-enables the Multi-Cos support in the driver.
    
    Fixes: d1f0b5dce8fd ("bnx2x: Disable multi-cos feature.")
    Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: Keep calling fallback()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a27a720075fff5529e3674786aa2ede9ec3b18a9
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 5 17:44:07 2019 +0100

    jbd2: Fix possible overflow in jbd2_log_space_left()
    
    commit add3efdd78b8a0478ce423bb9d4df6bd95e8b335 upstream.
    
    When number of free space in the journal is very low, the arithmetic in
    jbd2_log_space_left() could underflow resulting in very high number of
    free blocks and thus triggering assertion failure in transaction commit
    code complaining there's not enough space in the journal:
    
    J_ASSERT(journal->j_free > 1);
    
    Properly check for the low number of free blocks.
    
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20191105164437.32602-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ded55327ebba737a602eb1fe2f653ce41f5156da
Author: Pan Bian <bianpan2016@163.com>
Date:   Tue Nov 5 22:49:11 2019 +0800

    staging: rtl8192e: fix potential use after free
    
    commit b7aa39a2ed0112d07fc277ebd24a08a7b2368ab9 upstream.
    
    The variable skb is released via kfree_skb() when the return value of
    _rtl92e_tx is not zero. However, after that, skb is accessed again to
    read its length, which may result in a use after free bug. This patch
    fixes the bug by moving the release operation to where skb is never
    used later.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/1572965351-6745-1-git-send-email-bianpan2016@163.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c4064ba1266852c00418c40fd4c2930b8c17058e
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Fri Oct 18 07:20:52 2019 -0300

    media: exynos4-is: Fix recursive locking in isp_video_release()
    
    commit 704c6c80fb471d1bb0ef0d61a94617d1d55743cd upstream.
    
    >From isp_video_release(), &isp->video_lock is held and subsequent
    vb2_fop_release() tries to lock vdev->lock which is same with the
    previous one. Replace vb2_fop_release() with _vb2_fop_release() to
    fix the recursive locking.
    
    Fixes: 1380f5754cb0 ("[media] videobuf2: Add missing lock held on vb2_fop_release")
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2b1ca90029dc4cfbe20f719ab68504a88da1efee
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 10 10:13:32 2019 -0300

    media: radio: wl1273: fix interrupt masking on release
    
    commit 1091eb830627625dcf79958d99353c2391f41708 upstream.
    
    If a process is interrupted while accessing the radio device and the
    core lock is contended, release() could return early and fail to update
    the interrupt mask.
    
    Note that the return value of the v4l2 release file operation is
    ignored.
    
    Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver")
    Cc: Matti Aaltonen <matti.j.aaltonen@nokia.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cc4f4e35d6c668832576092925e0ec112f20e5fb
Author: Chengguang Xu <cgxu519@mykernel.net>
Date:   Tue Nov 5 12:51:00 2019 +0800

    ext2: check err when partial != NULL
    
    commit e705f4b8aa27a59f8933e8f384e9752f052c469c upstream.
    
    Check err when partial == NULL is meaningless because
    partial == NULL means getting branch successfully without
    error.
    
    Link: https://lore.kernel.org/r/20191105045100.7104-1-cgxu519@mykernel.net
    Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 635e2f8fff2d1d74871ff19deb97909046970725
Author: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Date:   Mon Oct 21 08:46:16 2019 -0700

    tty: serial: msm_serial: Fix flow control
    
    commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream.
    
    hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
    Lenovo Miix 630 laptop.  As part of initializing the wcn3990, hci_qca
    disables flow, configures the uart baudrate, and then reenables flow - at
    which point an event is expected to be received over the uart from the
    wcn3990.  It is observed that this event comes after the baudrate change
    but before hci_qca re-enables flow. This is unexpected, and is a result of
    msm_reset() being broken.
    
    According to the uart_dm hardware documentation, it is recommended that
    automatic hardware flow control be enabled by setting RX_RDY_CTL.  Auto
    hw flow control will manage RFR based on the configured watermark.  When
    there is space to receive data, the hw will assert RFR.  When the watermark
    is hit, the hw will de-assert RFR.
    
    The hardware documentation indicates that RFR can me manually managed via
    CR when RX_RDY_CTL is not set.  SET_RFR asserts RFR, and RESET_RFR
    de-asserts RFR.
    
    msm_reset() is broken because after resetting the hardware, it
    unconditionally asserts RFR via SET_RFR.  This enables flow regardless of
    the current configuration, and would undo a previous flow disable
    operation.  It should instead de-assert RFR via RESET_RFR to block flow
    until the hardware is reconfigured.  msm_serial should rely on the client
    to specify that flow should be enabled, either via mctrl() or the termios
    structure, and only assert RFR in response to those triggers.
    
    Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
    Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Andy Gross <agross@kernel.org>
    Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e311c02df0d3d1c96d2702e1f628bb694d2c990a
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Nov 4 16:26:53 2019 +0800

    blk-mq: make sure that line break can be printed
    
    commit d2c9be89f8ebe7ebcc97676ac40f8dec1cf9b43a upstream.
    
    8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores")
    avoids sysfs buffer overflow, and reserves one character for line break.
    However, the last snprintf() doesn't get correct 'size' parameter passed
    in, so fixed it.
    
    Fixes: 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da91b075d0b81d3e8a1cf0daf539ef2df56e00ab
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Fri Nov 1 11:35:03 2019 +0200

    iio: imu: adis16480: assign bias value only if operation succeeded
    
    commit 9b742763d9d4195e823ae6ece760c9ed0500c1dc upstream.
    
    This was found only after the whole thing with the inline functions, but
    the compiler actually found something. The value of the `bias` (in
    adis16480_get_calibbias()) should only be set if the read operation was
    successful.
    
    No actual known problem occurs as users of this function all
    ultimately check the return value.  Hence probably not stable material.
    
    Fixes: 2f3abe6cbb6c9 ("iio:imu: Add support for the ADIS16480 and similar IMUs")
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd775ed7c79b77e1f0a159d2a4b3efecf5a5ff79
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Nov 2 16:02:15 2019 +0800

    blk-mq: avoid sysfs buffer overflow with too many CPU cores
    
    commit 8962842ca5abdcf98e22ab3b2b45a103f0408b95 upstream.
    
    It is reported that sysfs buffer overflow can be triggered if the system
    has too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs of
    hctx via /sys/block/$DEV/mq/$N/cpu_list.
    
    Use snprintf to avoid the potential buffer overflow.
    
    This version doesn't change the attribute format, and simply stops
    showing CPU numbers if the buffer is going to overflow.
    
    Fixes: 676141e48af7("blk-mq: don't dump CPU -> hw queue map on driver load")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b843cd306a170d007f1438e67d7282095e6f8126
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Sun Sep 27 02:09:25 2015 +0900

    blk-mq: fix deadlock when reading cpu_list
    
    commit 60de074ba1e8f327db19bc33d8530131ac01695d upstream.
    
    CPU hotplug handling for blk-mq (blk_mq_queue_reinit) acquires
    all_q_mutex in blk_mq_queue_reinit_notify() and then removes sysfs
    entries by blk_mq_sysfs_unregister().  Removing sysfs entry needs to
    be blocked until the active reference of the kernfs_node to be zero.
    
    On the other hand, reading blk_mq_hw_sysfs_cpu sysfs entry (e.g.
    /sys/block/nullb0/mq/0/cpu_list) acquires all_q_mutex in
    blk_mq_hw_sysfs_cpus_show().
    
    If these happen at the same time, a deadlock can happen.  Because one
    can wait for the active reference to be zero with holding all_q_mutex,
    and the other tries to acquire all_q_mutex with holding the active
    reference.
    
    The reason that all_q_mutex is acquired in blk_mq_hw_sysfs_cpus_show()
    is to avoid reading an imcomplete hctx->cpumask.  Since reading sysfs
    entry for blk-mq needs to acquire q->sysfs_lock, we can avoid deadlock
    and reading an imcomplete hctx->cpumask by protecting q->sysfs_lock
    while hctx->cpumask is being updated.
    
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Reviewed-by: Ming Lei <tom.leiming@gmail.com>
    Cc: Ming Lei <tom.leiming@gmail.com>
    Cc: Wanpeng Li <wanpeng.li@hotmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f20d8d7ac57a7dae469d3bc44741b9596c2c8d9c
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Fri Nov 1 14:14:47 2019 -0700

    scsi: core: scsi_trace: Use get_unaligned_be*()
    
    commit b1335f5b0486f61fb66b123b40f8e7a98e49605d upstream.
    
    This patch fixes an unintended sign extension on left shifts. From Colin
    King: "Shifting a u8 left will cause the value to be promoted to an
    integer. If the top bit of the u8 is set then the following conversion to
    an u64 will sign extend the value causing the upper 32 bits to be set in
    the result."
    
    Fix this by using get_unaligned_be*() instead.
    
    Fixes: bf8162354233 ("[SCSI] add scsi trace core functions and put trace points")
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Link: https://lore.kernel.org/r/20191101211447.187151-1-bvanassche@acm.org
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9c64da63c028a800020bc9f7e139b8ba2d8f11ed
Author: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Date:   Thu Oct 31 10:39:20 2019 +0000

    quota: Check that quota is not dirty before release
    
    commit df4bb5d128e2c44848aeb36b7ceceba3ac85080d upstream.
    
    There is a race window where quota was redirted once we drop dq_list_lock inside dqput(),
    but before we grab dquot->dq_lock inside dquot_release()
    
    TASK1                                                       TASK2 (chowner)
    ->dqput()
      we_slept:
        spin_lock(&dq_list_lock)
        if (dquot_dirty(dquot)) {
              spin_unlock(&dq_list_lock);
              dquot->dq_sb->dq_op->write_dquot(dquot);
              goto we_slept
        if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {
              spin_unlock(&dq_list_lock);
              dquot->dq_sb->dq_op->release_dquot(dquot);
                                                                dqget()
                                                                mark_dquot_dirty()
                                                                dqput()
              goto we_slept;
            }
    So dquot dirty quota will be released by TASK1, but on next we_sleept loop
    we detect this and call ->write_dquot() for it.
    XFSTEST: https://github.com/dmonakhov/xfstests/commit/440a80d4cbb39e9234df4d7240aee1d551c36107
    
    Link: https://lore.kernel.org/r/20191031103920.3919-2-dmonakhov@openvz.org
    Signed-off-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7f8f231ca569b39265277c86297569634da2891d
Author: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Date:   Thu Oct 31 10:39:19 2019 +0000

    quota: fix livelock in dquot_writeback_dquots
    
    commit 6ff33d99fc5c96797103b48b7b0902c296f09c05 upstream.
    
    Write only quotas which are dirty at entry.
    
    XFSTEST: https://github.com/dmonakhov/xfstests/commit/b10ad23566a5bf75832a6f500e1236084083cddc
    
    Link: https://lore.kernel.org/r/20191031103920.3919-1-dmonakhov@openvz.org
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bcbd8abf66740836f406187787212ab72ef202b7
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Tue Jul 30 20:23:39 2019 +0300

    ARM: tegra: Fix FLOW_CTLR_HALT register clobbering by tegra_resume()
    
    commit d70f7d31a9e2088e8a507194354d41ea10062994 upstream.
    
    There is an unfortunate typo in the code that results in writing to
    FLOW_CTLR_HALT instead of FLOW_CTLR_CSR.
    
    Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 208d05091a22aa7f663e8c39d7f12a583065d473
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue Oct 22 16:58:59 2019 +0200

    mtd: spear_smi: Fix Write Burst mode
    
    commit 69c7f4618c16b4678f8a4949b6bb5ace259c0033 upstream.
    
    Any write with either dd or flashcp to a device driven by the
    spear_smi.c driver will pass through the spear_smi_cpy_toio()
    function. This function will get called for chunks of up to 256 bytes.
    If the amount of data is smaller, we may have a problem if the data
    length is not 4-byte aligned. In this situation, the kernel panics
    during the memcpy:
    
        # dd if=/dev/urandom bs=1001 count=1 of=/dev/mtd6
        spear_smi_cpy_toio [620] dest c9070000, src c7be8800, len 256
        spear_smi_cpy_toio [620] dest c9070100, src c7be8900, len 256
        spear_smi_cpy_toio [620] dest c9070200, src c7be8a00, len 256
        spear_smi_cpy_toio [620] dest c9070300, src c7be8b00, len 233
        Unhandled fault: external abort on non-linefetch (0x808) at 0xc90703e8
        [...]
        PC is at memcpy+0xcc/0x330
    
    The above error occurs because the implementation of memcpy_toio()
    tries to optimize the number of I/O by writing 4 bytes at a time as
    much as possible, until there are less than 4 bytes left and then
    switches to word or byte writes.
    
    Unfortunately, the specification states about the Write Burst mode:
    
            "the next AHB Write request should point to the next
            incremented address and should have the same size (byte,
            half-word or word)"
    
    This means ARM architecture implementation of memcpy_toio() cannot
    reliably be used blindly here. Workaround this situation by update the
    write path to stick to byte access when the burst length is not
    multiple of 4.
    
    Fixes: f18dbbb1bfe0 ("mtd: ST SPEAr: Add SMI driver for serial NOR flash")
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Boris Brezillon <boris.brezillon@collabora.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 61d7fb714b58cdf1375495be0432a79f4aa45180
Author: Marian Mihailescu <mihailescu2m@gmail.com>
Date:   Tue Oct 29 11:20:25 2019 +1030

    clk: samsung: exynos5420: Preserve CPU clocks configuration during suspend/resume
    
    commit e21be0d1d7bd7f78a77613f6bcb6965e72b22fc1 upstream.
    
    Save and restore top PLL related configuration registers for big (APLL)
    and LITTLE (KPLL) cores during suspend/resume cycle. So far, CPU clocks
    were reset to default values after suspend/resume cycle and performance
    after system resume was affected when performance governor has been selected.
    
    Fixes: 773424326b51 ("clk: samsung: exynos5420: add more registers to restore list")
    Signed-off-by: Marian Mihailescu <mihailescu2m@gmail.com>
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d14d61e02ab2da25ed365d74a871019c2586317
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Fri Oct 25 18:12:53 2019 +0200

    scsi: zfcp: trace channel log even for FCP command responses
    
    commit 100843f176109af94600e500da0428e21030ca7f upstream.
    
    While v2.6.26 commit b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug
    trace") is right that we don't want to flood the (payload) trace ring
    buffer, we don't trace successful FCP command responses by default.  So we
    can include the channel log for problem determination with failed responses
    of any FSF request type.
    
    Fixes: b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace")
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Link: https://lore.kernel.org/r/e37597b5c4ae123aaa85fd86c23a9f71e994e4a9.1572018132.git.bblock@linux.ibm.com
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.16: Deleted condition is slightly different]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aa17e8b5b24852a694c786ec108b6f50315f6a7c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 22 13:23:24 2019 +0300

    scsi: esas2r: unlock on error in esas2r_nvram_read_direct()
    
    commit 906ca6353ac09696c1bf0892513c8edffff5e0a6 upstream.
    
    This error path is missing an unlock.
    
    Fixes: 26780d9e12ed ("[SCSI] esas2r: ATTO Technology ExpressSAS 6G SAS/SATA RAID Adapter Driver")
    Link: https://lore.kernel.org/r/20191022102324.GA27540@mwanda
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58bae2bb5fda8fde6f4a33617411b9085fa6b26f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Oct 19 11:59:13 2019 +0300

    scsi: csiostor: Don't enable IRQs too early
    
    commit d6c9b31ac3064fbedf8961f120a4c117daa59932 upstream.
    
    These are called with IRQs disabled from csio_mgmt_tmo_handler() so we
    can't call spin_unlock_irq() or it will enable IRQs prematurely.
    
    Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver")
    Link: https://lore.kernel.org/r/20191019085913.GA14245@mwanda
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6171eb0871c37d73620fdd37889bab7bf0883b23
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Wed Oct 23 09:57:14 2019 +0800

    cpuidle: Do not unset the driver if it is there already
    
    commit 918c1fe9fbbe46fcf56837ff21f0ef96424e8b29 upstream.
    
    Fix __cpuidle_set_driver() to check if any of the CPUs in the mask has
    a driver different from drv already and, if so, return -EBUSY before
    updating any cpuidle_drivers per-CPU pointers.
    
    Fixes: 82467a5a885d ("cpuidle: simplify multiple driver support")
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    [ rjw: Subject & changelog ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bfd415af54a5679f6b7843ab39f727a967045472
Author: Jan Kara <jack@suse.cz>
Date:   Wed Oct 23 17:00:45 2019 -0700

    xfs: Sanity check flags of Q_XQUOTARM call
    
    commit 3dd4d40b420846dd35869ccc8f8627feef2cff32 upstream.
    
    Flags passed to Q_XQUOTARM were not sanity checked for invalid values.
    Fix that.
    
    Fixes: 9da93f9b7cdf ("xfs: fix Q_XQUOTARM ioctl")
    Reported-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbbb175d91ce384972aa4acd486e560c2330a641
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Oct 17 12:19:01 2019 +0200

    x86/ioapic: Prevent inconsistent state when moving an interrupt
    
    commit df4393424af3fbdcd5c404077176082a8ce459c4 upstream.
    
    There is an issue with threaded interrupts which are marked ONESHOT
    and using the fasteoi handler:
    
      if (IS_ONESHOT())
        mask_irq();
      ....
      cond_unmask_eoi_irq()
        chip->irq_eoi();
          if (setaffinity_pending) {
             mask_ioapic();
             ...
             move_affinity();
             unmask_ioapic();
          }
    
    So if setaffinity is pending the interrupt will be moved and then
    unconditionally unmasked at the ioapic level, which is wrong in two
    aspects:
    
     1) It should be kept masked up to the point where the threaded handler
        finished.
    
     2) The physical chip state and the software masked state are inconsistent
    
    Guard both the mask and the unmask with a check for the software masked
    state. If the line is marked masked then the ioapic line is also masked, so
    both mask_ioapic() and unmask_ioapic() can be skipped safely.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sebastian Siewior <bigeasy@linutronix.de>
    Fixes: 3aa551c9b4c4 ("genirq: add threaded interrupt handler support")
    Link: https://lkml.kernel.org/r/20191017101938.321393687@linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.16: Keep using {,un}mask_iopaic_irq()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2984ad34ceacc0952189227e9a42f63704c8c2ba
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jun 3 23:06:00 2019 +0200

    compat_ioctl: handle SIOCOUTQNSD
    
    commit 9d7bf41fafa5b5ddd4c13eb39446b0045f0a8167 upstream.
    
    Unlike the normal SIOCOUTQ, SIOCOUTQNSD was never handled in compat
    mode. Add it to the common socket compat handler along with similar
    ones.
    
    Fixes: 2f4e1b397097 ("tcp: ioctl type SIOCOUTQNSD returns amount of data not sent")
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: netdev@vger.kernel.org
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 01ea6cab089fcc67ea2fc2eba2ae0d4bab6bf119
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Sat Aug 10 10:42:48 2019 +0200

    usb: gadget: u_serial: add missing port entry locking
    
    commit daf82bd24e308c5a83758047aff1bd81edda4f11 upstream.
    
    gserial_alloc_line() misses locking (for a release barrier) while
    resetting port entry on TTY allocation failure. Fix this.
    
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tested-by: Ladislav Michl <ladis@linux-mips.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b97e83df3bb78e5bc6052625bfee14f3e2a5b0ff
Author: Mans Rullgard <mans@mansr.com>
Date:   Fri Oct 18 17:35:04 2019 +0200

    spi: atmel: fix handling of cs_change set on non-last xfer
    
    commit fed8d8c7a6dc2a76d7764842853d81c770b0788e upstream.
    
    The driver does the wrong thing when cs_change is set on a non-last
    xfer in a message.  When cs_change is set, the driver deactivates the
    CS and leaves it off until a later xfer again has cs_change set whereas
    it should be briefly toggling CS off and on again.
    
    This patch brings the behaviour of the driver back in line with the
    documentation and common sense.  The delay of 10 us is the same as is
    used by the default spi_transfer_one_message() function in spi.c.
    [gregory: rebased on for-5.5 from spi tree]
    Fixes: 8090d6d1a415 ("spi: atmel: Refactor spi-atmel to use SPI framework queue")
    Signed-off-by: Mans Rullgard <mans@mansr.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Link: https://lore.kernel.org/r/20191018153504.4249-1-gregory.clement@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [bwhh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b76fc4114f7b991191dbad2ec56a6ca0fb190547
Author: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Date:   Wed Oct 16 20:20:39 2019 -0700

    Bluetooth: hci_core: fix init for HCI_USER_CHANNEL
    
    commit eb8c101e28496888a0dcfe16ab86a1bee369e820 upstream.
    
    During the setup() stage, HCI device drivers expect the chip to
    acknowledge its setup() completion via vendor specific frames.
    
    If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
    the vendor specific frames are never tranmitted to the driver, as
    they are filtered in hci_rx_work().
    
    Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive
    frames if the HCI device is is HCI_INIT state.
    
    [1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html
    
    Fixes: 23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user operation")
    Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    [bwh: Backported to 3.16: Keep checking both HCI_RAW and HCI_USER_CHANNEL
     bits here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd5eeb1a0e5a21574fe4f81884dd50788645b2d3
Author: Steffen Liebergeld <steffen.liebergeld@kernkonzept.com>
Date:   Wed Sep 18 15:16:52 2019 +0200

    PCI: Fix Intel ACS quirk UPDCR register address
    
    commit d8558ac8c93d429d65d7490b512a3a67e559d0d4 upstream.
    
    According to documentation [0] the correct offset for the Upstream Peer
    Decode Configuration Register (UPDCR) is 0x1014.  It was previously defined
    as 0x1114.
    
    d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports")
    intended to enforce isolation between PCI devices allowing them to be put
    into separate IOMMU groups.  Due to the wrong register offset the intended
    isolation was not fully enforced.  This is fixed with this patch.
    
    Please note that I did not test this patch because I have no hardware that
    implements this register.
    
    [0] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-i-o-datasheet.pdf (page 325)
    Fixes: d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports")
    Link: https://lore.kernel.org/r/7a3505df-79ba-8a28-464c-88b83eefffa6@kernkonzept.com
    Signed-off-by: Steffen Liebergeld <steffen.liebergeld@kernkonzept.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Andrew Murray <andrew.murray@arm.com>
    Acked-by: Ashok Raj <ashok.raj@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

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

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

commit 2fc765157831a7386d438e417816758713c6e1b0
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Oct 7 12:09:53 2019 -0300

    media: usbvision: Fix races among open, close, and disconnect
    
    commit 9e08117c9d4efc1e1bc6fce83dab856d9fd284b6 upstream.
    
    Visual inspection of the usbvision driver shows that it suffers from
    three races between its open, close, and disconnect handlers.  In
    particular, the driver is careful to update its usbvision->user and
    usbvision->remove_pending flags while holding the private mutex, but:
    
            usbvision_v4l2_close() and usbvision_radio_close() don't hold
            the mutex while they check the value of
            usbvision->remove_pending;
    
            usbvision_disconnect() doesn't hold the mutex while checking
            the value of usbvision->user; and
    
            also, usbvision_v4l2_open() and usbvision_radio_open() don't
            check whether the device has been unplugged before allowing
            the user to open the device files.
    
    Each of these can potentially lead to usbvision_release() being called
    twice and use-after-free errors.
    
    This patch fixes the races by reading the flags while the mutex is
    still held and checking for pending removes before allowing an open to
    succeed.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    [bwh: Backported to 3.16:
     - Add unlock label in usbvision_v4l2_open()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3897db0846c40ac4526d27890ba6ccbe99a8b0db
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Oct 7 12:09:04 2019 -0300

    media: usbvision: Fix invalid accesses after device disconnect
    
    commit c7a191464078262bf799136317c95824e26a222b upstream.
    
    The syzbot fuzzer found two invalid-access bugs in the usbvision
    driver.  These bugs occur when userspace keeps the device file open
    after the device has been disconnected and usbvision_disconnect() has
    set usbvision->dev to NULL:
    
            When the device file is closed, usbvision_radio_close() tries
            to issue a usb_set_interface() call, passing the NULL pointer
            as its first argument.
    
            If userspace performs a querycap ioctl call, vidioc_querycap()
            calls usb_make_path() with the same NULL pointer.
    
    This patch fixes the problems by making the appropriate tests
    beforehand.  Note that vidioc_querycap() is protected by
    usbvision->v4l2_lock, acquired in a higher layer of the V4L2
    subsystem.
    
    Reported-and-tested-by: syzbot+7fa38a608b1075dfd634@syzkaller.appspotmail.com
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 853c609d59e9e8c653ab618da4ed6493cb3bd63f
Author: Insu Yun <wuninsu@gmail.com>
Date:   Mon Feb 1 13:59:30 2016 -0200

    usbvision: fix locking error
    
    commit 5ce625a42d6206d5a18222c6475f6b866ef68569 upstream.
    
    When remove_pending is non-zero, v4l2_lock is never unlocked.
    
    Signed-off-by: Insu Yun <wuninsu@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit de733b74ba71fce92f2cbd87f4ec31540b3f6fc6
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Jul 20 09:59:35 2015 -0300

    usbvision: fix locking error
    
    commit e2c84ccb0fbe5e524d15bb09c042a6ca634adaed upstream.
    
    If remove_pending is non-zero, then the v4l2_lock is never unlocked.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit db5d868a330d587eae9ad27e52a052d2badc09d2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Oct 16 04:57:21 2014 -0300

    usbvision-video: two use after frees
    
    commit 470a9147899500eb4898f77816520c4b4aa1a698 upstream.
    
    The lock has been freed in usbvision_release() so there is no need to
    call mutex_unlock() here.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 53ff3b77c6cd0fd0e52bd749cfda6850a1ec9561
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Jul 20 09:59:28 2015 -0300

    usbvision: remove power_on_at_open and timed power off
    
    commit 62e259493d779b0e2c1a675ab733136511310821 upstream.
    
    This causes lots of problems and is *very* slow as well.
    
    One of the main problems is that this prohibits the use of the control
    framework since subdevs will be unloaded on power off which is not allowed
    as long as they are used by a usb device.
    
    Apparently the reason for doing this is to turn off a noisy tuner. My hardware
    has no problem with that, and I wonder whether the hardware with that noisy
    tuner wasn't just functioning improperly as I have never heard of noisy tuners.
    
    Contact me if you have one of those devices and I can take a look whether the
    tuner can't be powered off if necessary by letting the tuner subdevice go
    into standby mode. Unloading the tuner module is just evil and is not the
    right approach.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    [bwh: Backported to 3.16 as dependency of locking fixes. Our version of
     usbvision_init_power_off_timer() was slightly different.]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ecf2601fc1c542cb3b3670fdb7c1a9fbe4700aae
Author: Lihua Yao <ylhuajnu@outlook.com>
Date:   Tue Sep 10 13:22:28 2019 +0000

    ARM: dts: s3c64xx: Fix init order of clock providers
    
    commit d60d0cff4ab01255b25375425745c3cff69558ad upstream.
    
    fin_pll is the parent of clock-controller@7e00f000, specify
    the dependency to ensure proper initialization order of clock
    providers.
    
    without this patch:
    [    0.000000] S3C6410 clocks: apll = 0, mpll = 0
    [    0.000000]  epll = 0, arm_clk = 0
    
    with this patch:
    [    0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000
    [    0.000000]  epll = 24000000, arm_clk = 532000000
    
    Fixes: 3f6d439f2022 ("clk: reverse default clk provider initialization order in of_clk_init()")
    Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
    Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c7facda1c03e3b24ee67ce058bbb3923873b633a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Oct 4 13:22:51 2019 +0300

    drm/i810: Prevent underflow in ioctl
    
    commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream.
    
    The "used" variables here come from the user in the ioctl and it can be
    negative.  It could result in an out of bounds write.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b2fcabf070815be0282aa78ba38105d22417be79
Author: Tony Lindgren <tony@atomide.com>
Date:   Sat Sep 14 14:02:56 2019 -0700

    hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled
    
    commit eaecce12f5f0d2c35d278e41e1bc4522393861ab upstream.
    
    When unloading omap3-rom-rng, we'll get the following:
    
    WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable
    
    This is because the clock may be already disabled by omap3_rom_rng_idle().
    Let's fix the issue by checking for rng_idle on exit.
    
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: Adam Ford <aford173@gmail.com>
    Cc: Pali Rohár <pali.rohar@gmail.com>
    Cc: Sebastian Reichel <sre@kernel.org>
    Cc: Tero Kristo <t-kristo@ti.com>
    Fixes: 1c6b7c2108bd ("hwrng: OMAP3 ROM Random Number Generator support")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 20066aeb7f3ca4525ca83df904e86a0e9bb6a592
Author: Denis Efremov <efremov@linux.com>
Date:   Mon Sep 30 23:31:47 2019 +0300

    ar5523: check NULL before memcpy() in ar5523_cmd()
    
    commit 315cee426f87658a6799815845788fde965ddaad upstream.
    
    memcpy() call with "idata == NULL && ilen == 0" results in undefined
    behavior in ar5523_cmd(). For example, NULL is passed in callchain
    "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch
    adds ilen check before memcpy() call in ar5523_cmd() to prevent an
    undefined behavior.
    
    Cc: Pontus Fuchs <pontus.fuchs@gmail.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Signed-off-by: Denis Efremov <efremov@linux.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6bdd5513e4726fd54990ac4c5d61581056ec6379
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 1 14:45:01 2019 +0300

    cw1200: Fix a signedness bug in cw1200_load_firmware()
    
    commit 4a50d454502f1401171ff061a5424583f91266db upstream.
    
    The "priv->hw_type" is an enum and in this context GCC will treat it
    as an unsigned int so the error handling will never trigger.
    
    Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c6544fef93920364719e31078922fad225e0379c
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Sep 27 09:26:42 2019 -0700

    tools/power/cpupower: Fix initializer override in hsw_ext_cstates
    
    commit 7e5705c635ecfccde559ebbbe1eaf05b5cc60529 upstream.
    
    When building cpupower with clang, the following warning appears:
    
     utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides
     prior initialization of this subobject [-Winitializer-overrides]
                     .desc                   = N_("Processor Package C2"),
                                                  ^~~~~~~~~~~~~~~~~~~~~~
     ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
     #define N_(String) gettext_noop(String)
                                     ^~~~~~
     ./utils/helpers/helpers.h:23:30: note: expanded from macro
     'gettext_noop'
     #define gettext_noop(String) String
                                  ^~~~~~
     utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization
     is here
                     .desc                   = N_("Processor Package C9"),
                                                  ^~~~~~~~~~~~~~~~~~~~~~
     ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
     #define N_(String) gettext_noop(String)
                                     ^~~~~~
     ./utils/helpers/helpers.h:23:30: note: expanded from macro
     'gettext_noop'
     #define gettext_noop(String) String
                                 ^~~~~~
     1 warning generated.
    
    This appears to be a copy and paste or merge mistake because the name
    and id fields both have PC9 in them, not PC2. Remove the second
    assignment to fix the warning.
    
    Fixes: 7ee767b69b68 ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states")
    Link: https://github.com/ClangBuiltLinux/linux/issues/718
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 75b5de9b149872dc3a782638a07315aa8b1e61bf
Author: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date:   Tue Sep 3 17:11:43 2019 -0300

    media: ov6650: Fix stored frame format not in sync with hardware
    
    commit 3143b459de4cdcce67b36827476c966e93c1cf01 upstream.
    
    The driver stores frame format settings supposed to be in line with
    hardware state in a device private structure.  Since the driver initial
    submission, those settings are updated before they are actually applied
    on hardware.  If an error occurs on device update, the stored settings
    my not reflect hardware state anymore and consecutive calls to
    .get_fmt() may return incorrect information.  That in turn may affect
    ability of a bridge device to use correct DMA transfer settings if such
    incorrect informmation on active frame format returned by .get_fmt() is
    used.
    
    Assuming a failed device update means its state hasn't changed, update
    frame format related settings stored in the device private structure
    only after they are successfully applied so the stored values always
    reflect hardware state as closely as possible.
    
    Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor")
    Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4a0be5c425c6f52d770afd984d3f87acba0c0208
Author: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date:   Tue Sep 3 17:11:39 2019 -0300

    media: ov6650: Fix incorrect use of JPEG colorspace
    
    commit 12500731895ef09afc5b66b86b76c0884fb9c7bf upstream.
    
    Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG
    for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8.  According
    to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies
    exclusively to V4L2_PIX_FMT_JPEG.  Since the sensor does not support
    JPEG format, fix it to always select V4L2_COLORSPACE_SRGB.
    
    Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor")
    Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef262128ec1652244dd29128974a0ceef0554fb2
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Aug 5 18:27:09 2019 +0200

    pinctrl: samsung: Fix device node refcount leaks in S3C64xx wakeup controller init
    
    commit 7f028caadf6c37580d0f59c6c094ed09afc04062 upstream.
    
    In s3c64xx_eint_eint0_init() the for_each_child_of_node() loop is used
    with a break to find a matching child node.  Although each iteration of
    for_each_child_of_node puts the previous node, but early exit from loop
    misses it.  This leads to leak of device node.
    
    Fixes: 61dd72613177 ("pinctrl: Add pinctrl-s3c64xx driver")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c383e33f94501400ea7fb73b84402b5ff5f6e6ff
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Aug 5 18:27:08 2019 +0200

    pinctrl: samsung: Fix device node refcount leaks in S3C24xx wakeup controller init
    
    commit 6fbbcb050802d6ea109f387e961b1dbcc3a80c96 upstream.
    
    In s3c24xx_eint_init() the for_each_child_of_node() loop is used with a
    break to find a matching child node.  Although each iteration of
    for_each_child_of_node puts the previous node, but early exit from loop
    misses it.  This leads to leak of device node.
    
    Fixes: af99a7507469 ("pinctrl: Add pinctrl-s3c24xx driver")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 135dfdaf7216b41cc098c7674c70c40a797a8b9e
Author: Denis Efremov <efremov@linux.com>
Date:   Fri Sep 27 01:56:04 2019 +0300

    ath9k_hw: fix uninitialized variable data
    
    commit 80e84f36412e0c5172447b6947068dca0d04ee82 upstream.
    
    Currently, data variable in ar9003_hw_thermo_cal_apply() could be
    uninitialized if ar9300_otp_read_word() will fail to read the value.
    Initialize data variable with 0 to prevent an undefined behavior. This
    will be enough to handle error case when ar9300_otp_read_word() fails.
    
    Fixes: 80fe43f2bbd5 ("ath9k_hw: Read and configure thermocal for AR9462")
    Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    Cc: John W. Linville <linville@tuxdriver.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Denis Efremov <efremov@linux.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit af269ec224c0cf02d6cc8f37ae3de498db7ccfa7
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 18 18:43:40 2019 -0700

    workqueue: Fix spurious sanity check failures in destroy_workqueue()
    
    commit def98c84b6cdf2eeea19ec5736e90e316df5206b upstream.
    
    Before actually destrying a workqueue, destroy_workqueue() checks
    whether it's actually idle.  If it isn't, it prints out a bunch of
    warning messages and leaves the workqueue dangling.  It unfortunately
    has a couple issues.
    
    * Mayday list queueing increments pwq's refcnts which gets detected as
      busy and fails the sanity checks.  However, because mayday list
      queueing is asynchronous, this condition can happen without any
      actual work items left in the workqueue.
    
    * Sanity check failure leaves the sysfs interface behind too which can
      lead to init failure of newer instances of the workqueue.
    
    This patch fixes the above two by
    
    * If a workqueue has a rescuer, disable and kill the rescuer before
      sanity checks.  Disabling and killing is guaranteed to flush the
      existing mayday list.
    
    * Remove sysfs interface before sanity checks.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Marcin Pawlowski <mpawlowski@fb.com>
    Reported-by: "Williams, Gerald S" <gerald.s.williams@intel.com>
    [bwh: Backported to 3.16: destroy_workqueue() also freed wq->rescuer itself]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9194baeddf432765d85f158bf3760763b7d2c683
Author: Aaro Koskinen <aaro.koskinen@nokia.com>
Date:   Wed Mar 27 22:35:37 2019 +0200

    net: stmmac: don't stop NAPI processing when dropping a packet
    
    commit 07b3975352374c3f5ebb4a42ef0b253fe370542d upstream.
    
    Currently, if we drop a packet, we exit from NAPI loop before the budget
    is consumed. In some situations this will make the RX processing stall
    e.g. when flood pinging the system with oversized packets, as the
    errorneous packets are not dropped efficiently.
    
    If we drop a packet, we should just continue to the next one as long as
    the budget allows.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [acj: backport v4.4 -stable
    -adjust context]
    Signed-off-by: Aviraj CJ <acj@cisco.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c56d49a783f49b0b63b569590f92a858fc2f0ce
Author: Aaro Koskinen <aaro.koskinen@nokia.com>
Date:   Wed Mar 27 22:35:35 2019 +0200

    net: stmmac: use correct DMA buffer size in the RX descriptor
    
    commit 583e6361414903c5206258a30e5bd88cb03c0254 upstream.
    
    We always program the maximum DMA buffer size into the receive descriptor,
    although the allocated size may be less. E.g. with the default MTU size
    we allocate only 1536 bytes. If somebody sends us a bigger frame, then
    memory may get corrupted.
    
    Fix by using exact buffer sizes.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [acj: backport to v4.4 -stable :
    - Modified patch since v4.4 driver has no support for Big endian
    - Skipped the section modifying non-existent functions in dwmac4_descs.c and
    dwxgmac2_descs.c ]
    Signed-off-by: Aviraj CJ <acj@cisco.com>
    [bwh: For 3.16, don't subtract 1 from BUF_SIZE_8KiB because I already
     backported commit 8137b6ef0ce4 "net: stmmac: Fix RX packet size > 8191".
     Also fold in commit f87db4dbd52f "net: stmmac: Use bfsize1 in
     ndesc_init_rx_desc".]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a2e9db568e9ae4695ae92cb983afbf344ed86ca9
Author: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date:   Thu Nov 26 08:35:45 2015 +0100

    stmmac: fix oversized frame reception
    
    commit e527c4a769d375ac0472450c52bde29087f49cd9 upstream.
    
    The receive skb buffers can be preallocated when the link is opened
    according to mtu size.
    While testing on a network environment with not standard MTU (e.g. 3000),
    a panic occurred if an incoming packet had a length greater than rx skb
    buffer size. This is because the HW is programmed to copy, from the DMA,
    an Jumbo frame and the Sw must check if the allocated buffer is enough to
    store the frame.
    
    Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
    Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2794d8f0ccabe3a8358930b9faa012dabc964d21
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jan 29 12:39:10 2016 +0100

    net: davinci_cpdma: use dma_addr_t for DMA address
    
    commit 84092996673211f16ef3b942a191d7952e9dfea9 upstream.
    
    The davinci_cpdma mixes up physical addresses as seen from the CPU
    and DMA addresses as seen from a DMA master, since it can operate
    on both normal memory or an on-chip buffer. If dma_addr_t is
    different from phys_addr_t, this means we get a compile-time warning
    about the type mismatch:
    
    ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
    ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
       pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
    In file included from ethernet/ti/davinci_cpdma.c:21:0:
    dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
     static inline void *dma_alloc_coherent(struct device *dev, size_t size,
    
    This slightly restructures the code so the address we use for
    mapping RAM into a DMA address is always a dma_addr_t, avoiding
    the warning. The code is correct even if both types are 32-bit
    because the DMA master in this device only supports 32-bit addressing
    anyway, independent of the types that are used.
    
    We still assign this value to pool->phys, and that is wrong if
    the driver is ever used with an IOMMU, but that value appears to
    be never used, so there is no problem really. I've added a couple
    of comments about where we do things that are slightly violating
    the API.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Daniel Wagner <dwagner@suse.de>
    Cc: Pavel Machek <pavel@denx.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 319c9ec2eceb0d458a98160930892d09e6e84c6f
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")
    [kees: backport to v4.9]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ad10e6d464796f2a481de4039a43b9cfca034e1c
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Feb 7 14:20:09 2018 -0800

    x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
    
    commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream.
    
    On i386, there are 2 types of PLTs, PIC and non-PIC.  PIE and shared
    objects must use PIC PLT.  To use PIC PLT, you need to load
    _GLOBAL_OFFSET_TABLE_ into EBX first.  There is no need for that on
    x86-64 since x86-64 uses PC-relative PLT.
    
    On x86-64, for 32-bit PC-relative branches, we can generate PLT32
    relocation, instead of PC32 relocation, which can also be used as
    a marker for 32-bit PC-relative branches.  Linker can always reduce
    PLT32 relocation to PC32 if function is defined locally.   Local
    functions should use PC32 relocation.  As far as Linux kernel is
    concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
    since Linux kernel doesn't use PLT.
    
    R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
    binutils master branch which will become binutils 2.31.
    
    [ hjl is working on having better documentation on this all, but a few
      more notes from him:
    
       "PLT32 relocation is used as marker for PC-relative branches. Because
        of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
        doesn't have GOT.
    
        As for symbol resolution, PLT32 and PC32 relocations are almost
        interchangeable. But when linker sees PLT32 relocation against a
        protected symbol, it can resolved locally at link-time since it is
        used on a branch instruction. Linker can't do that for PC32
        relocation"
    
      but for the kernel use, the two are basically the same, and this
      commit gets things building and working with the current binutils
      master   - Linus ]
    
    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [Woody Suwalski: Backported to 3.16]
    Signed-off-by: Woody Suwalski <terraluna977@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 11de33d23baa0c9168e6e8e34bb4909de08291aa
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Aug 21 20:00:02 2019 +0200

    ALSA: line6: Fix memory leak at line6_init_pcm() error path
    
    commit 1bc8d18c75fef3b478dbdfef722aae09e2a9fde7 upstream.
    
    I forgot to release the allocated object at the early error path in
    line6_init_pcm().  For addressing it, slightly shuffle the code so
    that the PCM destructor (pcm->private_free) is assigned properly
    before all error paths.
    
    Fixes: 3450121997ce ("ALSA: line6: Fix write on zero-sized buffer")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1f36225d6fe815cb0a746f5018e4c9b832a2e8d3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 19 14:41:57 2015 +0100

    ALSA: line6: Drop superfluous snd_device for PCM
    
    commit b45a7c565473d29bd7e02ac8ca86232a24ca247f upstream.
    
    Instead of handling the card-specific resource in snd_device, attach
    it into pcm->private_data and release it directly in private_free.
    This simplifies the code and structure.
    
    Tested-by: Chris Rorvick <chris@rorvick.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.16 as dependency of commit 1bc8d18c75fe
     "ALSA: line6: Fix memory leak at line6_init_pcm() error path"]
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>