commit b5260801526c77496dd8be7d750c20939ec64189
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 25 10:50:29 2019 +0200

    Linux 4.14.140

commit 64d1cec408bfcbfedd7bc33887b0a0a610435da9
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Jun 25 17:26:02 2018 +0200

    xfrm: policy: remove pcpu policy cache
    
    commit e4db5b61c572475bbbcf63e3c8a2606bfccf2c9d upstream.
    
    Kristian Evensen says:
      In a project I am involved in, we are running ipsec (Strongswan) on
      different mt7621-based routers. Each router is configured as an
      initiator and has around ~30 tunnels to different responders (running
      on misc. devices). Before the flow cache was removed (kernel 4.9), we
      got a combined throughput of around 70Mbit/s for all tunnels on one
      router. However, we recently switched to kernel 4.14 (4.14.48), and
      the total throughput is somewhere around 57Mbit/s (best-case). I.e., a
      drop of around 20%. Reverting the flow cache removal restores, as
      expected, performance levels to that of kernel 4.9.
    
    When pcpu xdst exists, it has to be validated first before it can be
    used.
    
    A negative hit thus increases cost vs. no-cache.
    
    As number of tunnels increases, hit rate decreases so this pcpu caching
    isn't a viable strategy.
    
    Furthermore, the xdst cache also needs to run with BH off, so when
    removing this the bh disable/enable pairs can be removed too.
    
    Kristian tested a 4.14.y backport of this change and reported
    increased performance:
    
      In our tests, the throughput reduction has been reduced from around -20%
      to -5%. We also see that the overall throughput is independent of the
      number of tunnels, while before the throughput was reduced as the number
      of tunnels increased.
    
    Reported-by: Kristian Evensen <kristian.evensen@gmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cea3cbf2cade6f85dc06ac2728ccb533fc16ddf1
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Mon Aug 6 10:43:10 2018 +0200

    mmc: sdhci-of-arasan: Do now show error message in case of deffered probe
    
    commit 60208a267208c27fa3f23dfd36cbda180471fa98 upstream.
    
    When mmc-pwrseq property is passed mmc_pwrseq_alloc() can return
    -EPROBE_DEFER because driver for power sequence provider is not probed
    yet. Do not show error message when this situation happens.
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c35aeec7eff56ba58a629528c93ddec35164ba38
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Aug 7 10:19:59 2019 +0800

    bonding: Add vlan tx offload to hw_enc_features
    
    [ Upstream commit d595b03de2cb0bdf9bcdf35ff27840cc3a37158f ]
    
    As commit 30d8177e8ac7 ("bonding: Always enable vlan tx offload")
    said, we should always enable bonding's vlan tx offload, pass the
    vlan packets to the slave devices with vlan tci, let them to handle
    vlan implementation.
    
    Now if encapsulation protocols like VXLAN is used, skb->encapsulation
    may be set, then the packet is passed to vlan device which based on
    bonding device. However in netif_skb_features(), the check of
    hw_enc_features:
    
             if (skb->encapsulation)
                     features &= dev->hw_enc_features;
    
    clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
    in same issue in commit 30d8177e8ac7 like this:
    
    vlan_dev_hard_start_xmit
      -->dev_queue_xmit
        -->validate_xmit_skb
          -->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
          -->validate_xmit_vlan
            -->__vlan_hwaccel_push_inside //skb->tci is cleared
    ...
     --> bond_start_xmit
       --> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
         --> __skb_flow_dissect // nhoff point to IP header
            -->  case htons(ETH_P_8021Q)
                 // skb_vlan_tag_present is false, so
                 vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
                 //vlan point to ip header wrongly
    
    Fixes: b2a103e6d0af ("bonding: convert to ndo_fix_features")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46b06c8ad2937e0feaf713df8de40b1cb4f27a9d
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Aug 8 14:22:47 2019 +0800

    team: Add vlan tx offload to hw_enc_features
    
    [ Upstream commit 227f2f030e28d8783c3d10ce70ff4ba79cad653f ]
    
    We should also enable team's vlan tx offload in hw_enc_features,
    pass the vlan packets to the slave devices with vlan tci, let the
    slave handle vlan tunneling offload implementation.
    
    Fixes: 3268e5cb494d ("team: Advertise tunneling offload features")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16e1dafa21acfe5c37934ec1e7414f1fba572279
Author: Maxim Mikityanskiy <maximmi@mellanox.com>
Date:   Fri Jul 5 17:59:28 2019 +0300

    net/mlx5e: Use flow keys dissector to parse packets for ARFS
    
    [ Upstream commit 405b93eb764367a670e729da18e54dc42db32620 ]
    
    The current ARFS code relies on certain fields to be set in the SKB
    (e.g. transport_header) and extracts IP addresses and ports by custom
    code that parses the packet. The necessary SKB fields, however, are not
    always set at that point, which leads to an out-of-bounds access. Use
    skb_flow_dissect_flow_keys() to get the necessary information reliably,
    fix the out-of-bounds access and reuse the code.
    
    Fixes: 18c908e477dc ("net/mlx5e: Add accelerated RFS support")
    Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfb4320e793890b8dc4807506ea02e66c7af6d34
Author: Huy Nguyen <huyn@mellanox.com>
Date:   Thu Aug 1 11:10:19 2019 -0500

    net/mlx5e: Only support tx/rx pause setting for port owner
    
    [ Upstream commit 466df6eb4a9e813b3cfc674363316450c57a89c5 ]
    
    Only support changing tx/rx pause frame setting if the net device
    is the vport group manager.
    
    Fixes: 3c2d18ef22df ("net/mlx5e: Support ethtool get/set_pauseparam")
    Signed-off-by: Huy Nguyen <huyn@mellanox.com>
    Reviewed-by: Parav Pandit <parav@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7a327b7436721ee929f3215c59ab3d1c772e66b
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Mon Aug 5 16:34:34 2019 +0100

    xen/netback: Reset nr_frags before freeing skb
    
    [ Upstream commit 3a0233ddec554b886298de2428edb5c50a20e694 ]
    
    At this point nr_frags has been incremented but the frag does not yet
    have a page assigned so freeing the skb results in a crash. Reset
    nr_frags before freeing the skb to prevent this.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 382d8991832ff838b08257a6355edbfc28106043
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Aug 12 20:49:12 2019 +0800

    sctp: fix the transport error_count check
    
    [ Upstream commit a1794de8b92ea6bc2037f445b296814ac826693e ]
    
    As the annotation says in sctp_do_8_2_transport_strike():
    
      "If the transport error count is greater than the pf_retrans
       threshold, and less than pathmaxrtx ..."
    
    It should be transport->error_count checked with pathmaxrxt,
    instead of asoc->pf_retrans.
    
    Fixes: 5aa93bcf66f4 ("sctp: Implement quick failover draft from tsvwg")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ac73816dda7d2d33ef89177b3d095b3cf5777fb
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Aug 14 02:11:57 2019 -0700

    net/packet: fix race in tpacket_snd()
    
    [ Upstream commit 32d3182cd2cd29b2e7e04df7b0db350fbe11289f ]
    
    packet_sendmsg() checks tx_ring.pg_vec to decide
    if it must call tpacket_snd().
    
    Problem is that the check is lockless, meaning another thread
    can issue a concurrent setsockopt(PACKET_TX_RING ) to flip
    tx_ring.pg_vec back to NULL.
    
    Given that tpacket_snd() grabs pg_vec_lock mutex, we can
    perform the check again to solve the race.
    
    syzbot reported :
    
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 11429 Comm: syz-executor394 Not tainted 5.3.0-rc4+ #101
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:packet_lookup_frame+0x8d/0x270 net/packet/af_packet.c:474
    Code: c1 ee 03 f7 73 0c 80 3c 0e 00 0f 85 cb 01 00 00 48 8b 0b 89 c0 4c 8d 24 c1 48 b8 00 00 00 00 00 fc ff df 4c 89 e1 48 c1 e9 03 <80> 3c 01 00 0f 85 94 01 00 00 48 8d 7b 10 4d 8b 3c 24 48 b8 00 00
    RSP: 0018:ffff88809f82f7b8 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: ffff8880a45c7030 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 1ffff110148b8e06 RDI: ffff8880a45c703c
    RBP: ffff88809f82f7e8 R08: ffff888087aea200 R09: fffffbfff134ae50
    R10: fffffbfff134ae4f R11: ffffffff89a5727f R12: 0000000000000000
    R13: 0000000000000001 R14: ffff8880a45c6ac0 R15: 0000000000000000
    FS:  00007fa04716f700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fa04716edb8 CR3: 0000000091eb4000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     packet_current_frame net/packet/af_packet.c:487 [inline]
     tpacket_snd net/packet/af_packet.c:2667 [inline]
     packet_sendmsg+0x590/0x6250 net/packet/af_packet.c:2975
     sock_sendmsg_nosec net/socket.c:637 [inline]
     sock_sendmsg+0xd7/0x130 net/socket.c:657
     ___sys_sendmsg+0x3e2/0x920 net/socket.c:2311
     __sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413
     __do_sys_sendmmsg net/socket.c:2442 [inline]
     __se_sys_sendmmsg net/socket.c:2439 [inline]
     __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2439
     do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
    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>

commit fbaae3105ff1f12a7f2a565ef4e9cd18dc83d0f1
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Mon Aug 12 14:11:35 2019 -0500

    net/mlx4_en: fix a memory leak bug
    
    [ Upstream commit 48ec7014c56e5eb2fbf6f479896143622d834f3b ]
    
    In mlx4_en_config_rss_steer(), 'rss_map->indir_qp' is allocated through
    kzalloc(). After that, mlx4_qp_alloc() is invoked to configure RSS
    indirection. However, if mlx4_qp_alloc() fails, the allocated
    'rss_map->indir_qp' is not deallocated, leading to a memory leak bug.
    
    To fix the above issue, add the 'qp_alloc_err' label to free
    'rss_map->indir_qp'.
    
    Fixes: 4931c6ef04b4 ("net/mlx4_en: Optimized single ring steering")
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a994cee95eb1ad0269b3f09d45e474607659ca4
Author: Manish Chopra <manishc@marvell.com>
Date:   Sun Aug 18 07:25:48 2019 -0700

    bnx2x: Fix VF's VLAN reconfiguration in reload.
    
    [ Upstream commit 4a4d2d372fb9b9229327e2ed01d5d9572eddf4de ]
    
    Commit 04f05230c5c13 ("bnx2x: Remove configured vlans as
    part of unload sequence."), introduced a regression in driver
    that as a part of VF's reload flow, VLANs created on the VF
    doesn't get re-configured in hardware as vlan metadata/info
    was not getting cleared for the VFs which causes vlan PING to stop.
    
    This patch clears the vlan metadata/info so that VLANs gets
    re-configured back in the hardware in VF's reload flow and
    PING/traffic continues for VLANs created over the VFs.
    
    Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.")
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: Sudarsana Kalluru <skalluru@marvell.com>
    Signed-off-by: Shahed Shaikh <shshaikh@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37bc6f45e8dcec51eb162da618b96fc96b291f26
Author: Joerg Roedel <jroedel@suse.de>
Date:   Fri Oct 5 12:32:46 2018 +0200

    iommu/amd: Move iommu_init_pci() to .init section
    
    commit 24d2c521749d8547765b555b7a85cca179bb2275 upstream.
    
    The function is only called from another __init function, so
    it should be moved to .init too.
    
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6879992d0754245473a044734cc7bb9caacb7e1
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Jul 16 20:17:20 2019 +0200

    Input: psmouse - fix build error of multiple definition
    
    commit 49e6979e7e92cf496105b5636f1df0ac17c159c0 upstream.
    
    trackpoint_detect() should be static inline while
    CONFIG_MOUSE_PS2_TRACKPOINT is not set, otherwise, we build fails:
    
    drivers/input/mouse/alps.o: In function `trackpoint_detect':
    alps.c:(.text+0x8e00): multiple definition of `trackpoint_detect'
    drivers/input/mouse/psmouse-base.o:psmouse-base.c:(.text+0x1b50): first defined here
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 55e3d9224b60 ("Input: psmouse - allow disabing certain protocol extensions")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6a1dc4dbe93f3db32da7a97d24203cf0d8ff2b2
Author: Dirk Morris <dmorris@metaloft.com>
Date:   Thu Aug 8 13:57:51 2019 -0700

    netfilter: conntrack: Use consistent ct id hash calculation
    
    commit 656c8e9cc1badbc18eefe6ba01d33ebbcae61b9a upstream.
    
    Change ct id hash calculation to only use invariants.
    
    Currently the ct id hash calculation is based on some fields that can
    change in the lifetime on a conntrack entry in some corner cases. The
    current hash uses the whole tuple which contains an hlist pointer which
    will change when the conntrack is placed on the dying list resulting in
    a ct id change.
    
    This patch also removes the reply-side tuple and extension pointer from
    the hash calculation so that the ct id will will not change from
    initialization until confirmation.
    
    Fixes: 3c79107631db1f7 ("netfilter: ctnetlink: don't use conntrack/expect object addresses as id")
    Signed-off-by: Dirk Morris <dmorris@metaloft.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 209479bfff8da8a53a460591b89007e4254d5245
Author: Will Deacon <will@kernel.org>
Date:   Fri Aug 16 14:57:43 2019 +0100

    arm64: ftrace: Ensure module ftrace trampoline is coherent with I-side
    
    commit b6143d10d23ebb4a77af311e8b8b7f019d0163e6 upstream.
    
    The initial support for dynamic ftrace trampolines in modules made use
    of an indirect branch which loaded its target from the beginning of
    a special section (e71a4e1bebaf7 ("arm64: ftrace: add support for far
    branches to dynamic ftrace")). Since no instructions were being patched,
    no cache maintenance was needed. However, later in be0f272bfc83 ("arm64:
    ftrace: emit ftrace-mod.o contents through code") this code was reworked
    to output the trampoline instructions directly into the PLT entry but,
    unfortunately, the necessary cache maintenance was overlooked.
    
    Add a call to __flush_icache_range() after writing the new trampoline
    instructions but before patching in the branch to the trampoline.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: James Morse <james.morse@arm.com>
    Cc: <stable@vger.kernel.org>
    Fixes: be0f272bfc83 ("arm64: ftrace: emit ftrace-mod.o contents through code")
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed13fc13af8e43e019acca4d2c62b41eb2fb2ae9
Author: Will Deacon <will@kernel.org>
Date:   Mon Jul 29 11:06:17 2019 +0100

    arm64: compat: Allow single-byte watchpoints on all addresses
    
    commit 849adec41203ac5837c40c2d7e08490ffdef3c2c upstream.
    
    Commit d968d2b801d8 ("ARM: 7497/1: hw_breakpoint: allow single-byte
    watchpoints on all addresses") changed the validation requirements for
    hardware watchpoints on arch/arm/. Update our compat layer to implement
    the same relaxation.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 480d6d2f396e76bb9d77a180d32f2308fa8fb2d9
Author: Sasha Levin <sashal@kernel.org>
Date:   Mon Aug 19 23:17:55 2019 -0400

    Revert "tcp: Clear sk_send_head after purging the write queue"
    
    This reverts commit e99e7745d03fc50ba7c5b7c91c17294fee2d5991.
    
    Ben Hutchings writes:
    
    >Sorry, this is the same issue that was already fixed by "tcp: reset
    >sk_send_head in tcp_write_queue_purge".  You can drop my version from
    >the queue for 4.4 and 4.9 and revert it for 4.14.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d45c6f193789c6b610d734997a2f4cdebec4e37
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Dec 11 12:14:12 2018 +0100

    bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K
    
    [ Upstream commit fdadd04931c2d7cd294dc5b2b342863f94be53a3 ]
    
    Michael and Sandipan report:
    
      Commit ede95a63b5 introduced a bpf_jit_limit tuneable to limit BPF
      JIT allocations. At compile time it defaults to PAGE_SIZE * 40000,
      and is adjusted again at init time if MODULES_VADDR is defined.
    
      For ppc64 kernels, MODULES_VADDR isn't defined, so we're stuck with
      the compile-time default at boot-time, which is 0x9c400000 when
      using 64K page size. This overflows the signed 32-bit bpf_jit_limit
      value:
    
      root@ubuntu:/tmp# cat /proc/sys/net/core/bpf_jit_limit
      -1673527296
    
      and can cause various unexpected failures throughout the network
      stack. In one case `strace dhclient eth0` reported:
    
      setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, {len=11, filter=0x105dd27f8},
                 16) = -1 ENOTSUPP (Unknown error 524)
    
      and similar failures can be seen with tools like tcpdump. This doesn't
      always reproduce however, and I'm not sure why. The more consistent
      failure I've seen is an Ubuntu 18.04 KVM guest booted on a POWER9
      host would time out on systemd/netplan configuring a virtio-net NIC
      with no noticeable errors in the logs.
    
    Given this and also given that in near future some architectures like
    arm64 will have a custom area for BPF JIT image allocations we should
    get rid of the BPF_JIT_LIMIT_DEFAULT fallback / default entirely. For
    4.21, we have an overridable bpf_jit_alloc_exec(), bpf_jit_free_exec()
    so therefore add another overridable bpf_jit_alloc_exec_limit() helper
    function which returns the possible size of the memory area for deriving
    the default heuristic in bpf_jit_charge_init().
    
    Like bpf_jit_alloc_exec() and bpf_jit_free_exec(), the new
    bpf_jit_alloc_exec_limit() assumes that module_alloc() is the default
    JIT memory provider, and therefore in case archs implement their custom
    module_alloc() we use MODULES_{END,_VADDR} for limits and otherwise for
    vmalloc_exec() cases like on ppc64 we use VMALLOC_{END,_START}.
    
    Additionally, for archs supporting large page sizes, we should change
    the sysctl to be handled as long to not run into sysctl restrictions
    in future.
    
    Fixes: ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations")
    Reported-by: Sandipan Das <sandipan@linux.ibm.com>
    Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef6a045a90eb1212c4cab72a51a077ea56097485
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu Aug 15 01:26:02 2019 -0700

    USB: serial: option: Add Motorola modem UARTs
    
    commit 6caf0be40a707689e8ff8824fdb96ef77685b1ba upstream.
    
    On Motorola Mapphone devices such as Droid 4 there are five USB ports
    that do not use the same layout as Gobi 1K/2K/etc devices listed in
    qcserial.c. So we should use qcaux.c or option.c as noted by
    Dan Williams <dan.j.williams@intel.com>.
    
    As the Motorola USB serial ports have an interrupt endpoint as shown
    with lsusb -v, we should use option.c instead of qcaux.c as pointed out
    by Johan Hovold <johan@kernel.org>.
    
    The ff/ff/ff interfaces seem to always be UARTs on Motorola devices.
    For the other interfaces, class 0x0a (CDC Data) should not in general
    be added as they are typically part of a multi-interface function as
    noted earlier by Bjørn Mork <bjorn@mork.no>.
    
    However, looking at the Motorola mapphone kernel code, the mdm6600 0x0a
    class is only used for flashing the modem firmware, and there are no
    other interfaces. So I've added that too with more details below as it
    works just fine.
    
    The ttyUSB ports on Droid 4 are:
    
    ttyUSB0 DIAG, CQDM-capable
    ttyUSB1 MUX or NMEA, no response
    ttyUSB2 MUX or NMEA, no response
    ttyUSB3 TCMD
    ttyUSB4 AT-capable
    
    The ttyUSB0 is detected as QCDM capable by ModemManager. I think
    it's only used for debugging with ModemManager --debug for sending
    custom AT commands though. ModemManager already can manage data
    connection using the USB QMI ports that are already handled by the
    qmi_wwan.c driver.
    
    To enable the MUX or NMEA ports, it seems that something needs to be
    done additionally to enable them, maybe via the DIAG or TCMD port.
    It might be just a NVRAM setting somewhere, but I have no idea what
    NVRAM settings may need changing for that.
    
    The TCMD port seems to be a Motorola custom protocol for testing
    the modem and to configure it's NVRAM and seems to work just fine
    based on a quick test with a minimal tcmdrw tool I wrote.
    
    The voice modem AT-capable port seems to provide only partial
    support, and no PM support compared to the TS 27.010 based UART
    wired directly to the modem.
    
    The UARTs added with this change are the same product IDs as the
    Motorola Mapphone Android Linux kernel mdm6600_id_table. I don't
    have any mdm9600 based devices, so I have only tested these on
    mdm6600 based droid 4.
    
    Then for the class 0x0a (CDC Data) mode, the Motorola Mapphone Android
    Linux kernel driver moto_flashqsc.c just seems to change the
    port->bulk_out_size to 8K from the default. And is only used for
    flashing the modem firmware it seems.
    
    I've verified that flashing the modem with signed firmware works just
    fine with the option driver after manually toggling the GPIO pins, so
    I've added droid 4 modem flashing mode to the option driver. I've not
    added the other devices listed in moto_flashqsc.c in case they really
    need different port->bulk_out_size. Those can be added as they get
    tested to work for flashing the modem.
    
    After this patch the output of /sys/kernel/debug/usb/devices has
    the following for normal 22b8:2a70 mode including the related qmi_wwan
    interfaces:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=22b8 ProdID=2a70 Rev= 0.00
    S:  Manufacturer=Motorola, Incorporated
    S:  Product=Flash MZ600
    C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
    E:  Ad=8a(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
    E:  Ad=8b(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
    E:  Ad=8c(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=08(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
    E:  Ad=8d(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=09(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    
    In 22b8:900e "qc_dload" mode the device shows up as:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=22b8 ProdID=900e Rev= 0.00
    S:  Manufacturer=Motorola, Incorporated
    S:  Product=Flash MZ600
    C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    
    And in 22b8:4281 "ram_downloader" mode the device shows up as:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=22b8 ProdID=4281 Rev= 0.00
    S:  Manufacturer=Motorola, Incorporated
    S:  Product=Flash MZ600
    C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=fc Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    
    Cc: Bjørn Mork <bjorn@mork.no>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Lars Melin <larsm17@gmail.com>
    Cc: Marcel Partap <mpartap@gmx.net>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Michael Scott <hashcode0f@gmail.com>
    Cc: NeKit <nekit1000@gmail.com>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Sebastian Reichel <sre@kernel.org>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d319621f66068dece47481b12913f03083a8904b
Author: Bob Ham <bob.ham@puri.sm>
Date:   Wed Jul 24 07:52:26 2019 -0700

    USB: serial: option: add the BroadMobi BM818 card
    
    commit e5d8badf37e6b547842f2fcde10361b29e08bd36 upstream.
    
    Add a VID:PID for the BroadMobi BM818 M.2 card
    
    T:  Bus=01 Lev=03 Prnt=40 Port=03 Cnt=01 Dev#= 44 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2020 ProdID=2060 Rev=00.00
    S:  Manufacturer=Qualcomm, Incorporated
    S:  Product=Qualcomm CDMA Technologies MSM
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none)
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    
    Signed-off-by: Bob Ham <bob.ham@puri.sm>
    Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
    Cc: stable <stable@vger.kernel.org>
    [ johan: use USB_DEVICE_INTERFACE_CLASS() ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8313b7682928f50cde9a567dbf19b32e9f8590b4
Author: Yoshiaki Okamoto <yokamoto@allied-telesis.co.jp>
Date:   Sat Jul 20 22:23:18 2019 +0900

    USB: serial: option: Add support for ZTE MF871A
    
    commit 7e7ae38bf928c5cfa6dd6e9a2cf8b42c84a27c92 upstream.
    
    This patch adds support for MF871A USB modem (aka Speed USB STICK U03)
    to option driver. This modem is manufactured by ZTE corporation, and
    sold by KDDI.
    
    Interface layout:
    0: AT
    1: MODEM
    
    usb-devices output:
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  9 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=1481 Rev=52.87
    S:  Manufacturer=ZTE,Incorporated
    S:  Product=ZTE Technologies MSM
    S:  SerialNumber=1234567890ABCDEF
    C:  #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    
    Co-developed-by: Hiroyuki Yamamoto <hyamamo@allied-telesis.co.jp>
    Signed-off-by: Hiroyuki Yamamoto <hyamamo@allied-telesis.co.jp>
    Signed-off-by: Yoshiaki Okamoto <yokamoto@allied-telesis.co.jp>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e11df87e1430ad8c74d3959d9e0782fb8fabe5ca
Author: Rogan Dawes <rogan@dawes.za.net>
Date:   Wed Jul 17 11:11:34 2019 +0200

    USB: serial: option: add D-Link DWM-222 device ID
    
    commit 552573e42aab5f75aff9bab855a9677979d9a7d5 upstream.
    
    Add device id for D-Link DWM-222 A2.
    
    MI_00 D-Link HS-USB Diagnostics
    MI_01 D-Link HS-USB Modem
    MI_02 D-Link HS-USB AT Port
    MI_03 D-Link HS-USB NMEA
    MI_04 D-Link HS-USB WWAN Adapter (qmi_wwan)
    MI_05 USB Mass Storage Device
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1213b365921b5dc55ae24e7daed78422e20d6e76
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Aug 13 11:35:41 2019 +0200

    USB: CDC: fix sanity checks in CDC union parser
    
    commit 54364278fb3cabdea51d6398b07c87415065b3fc upstream.
    
    A few checks checked for the size of the pointer to a structure
    instead of the structure itself. Copy & paste issue presumably.
    
    Fixes: e4c6fb7794982 ("usbnet: move the CDC parser into USB core")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: syzbot+45a53506b65321c1fe91@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20190813093541.18889-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e630f38040b5d2ecc56920742f7bafd57834cd2a
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Aug 8 16:21:19 2019 +0200

    usb: cdc-acm: make sure a refcount is taken early enough
    
    commit c52873e5a1ef72f845526d9f6a50704433f9c625 upstream.
    
    destroy() will decrement the refcount on the interface, so that
    it needs to be taken so early that it never undercounts.
    
    Fixes: 7fb57a019f94e ("USB: cdc-acm: Fix potential deadlock (lockdep warning)")
    Cc: stable <stable@vger.kernel.org>
    Reported-and-tested-by: syzbot+1b2449b7b5dc240d107a@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20190808142119.7998-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56a3eb5fa5d024794c5c62edc0e7b5864aa68bcb
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Wed Jul 31 19:15:43 2019 +0900

    usb: gadget: udc: renesas_usb3: Fix sysfs interface of "role"
    
    commit 5dac665cf403967bb79a7aeb8c182a621fe617ff upstream.
    
    Since the role_store() uses strncmp(), it's possible to refer
    out-of-memory if the sysfs data size is smaller than strlen("host").
    This patch fixes it by using sysfs_streq() instead of strncmp().
    
    Fixes: cc995c9ec118 ("usb: gadget: udc: renesas_usb3: add support for usb role swap")
    Cc: <stable@vger.kernel.org> # v4.12+
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 282a771475c2016ef77871f4438d9aaf9c8aa2b7
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 12 16:11:07 2019 -0400

    USB: core: Fix races in character device registration and deregistraion
    
    commit 303911cfc5b95d33687d9046133ff184cf5043ff upstream.
    
    The syzbot fuzzer has found two (!) races in the USB character device
    registration and deregistration routines.  This patch fixes the races.
    
    The first race results from the fact that usb_deregister_dev() sets
    usb_minors[intf->minor] to NULL before calling device_destroy() on the
    class device.  This leaves a window during which another thread can
    allocate the same minor number but will encounter a duplicate name
    error when it tries to register its own class device.  A typical error
    message in the system log would look like:
    
        sysfs: cannot create duplicate filename '/class/usbmisc/ldusb0'
    
    The patch fixes this race by destroying the class device first.
    
    The second race is in usb_register_dev().  When that routine runs, it
    first allocates a minor number, then drops minor_rwsem, and then
    creates the class device.  If the device creation fails, the minor
    number is deallocated and the whole routine returns an error.  But
    during the time while minor_rwsem was dropped, there is a window in
    which the minor number is allocated and so another thread can
    successfully open the device file.  Typically this results in
    use-after-free errors or invalid accesses when the other thread closes
    its open file reference, because the kernel then tries to release
    resources that were already deallocated when usb_register_dev()
    failed.  The patch fixes this race by keeping minor_rwsem locked
    throughout the entire routine.
    
    Reported-and-tested-by: syzbot+30cf45ebfe0b0c4847a1@syzkaller.appspotmail.com
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908121607590.1659-100000@iolanthe.rowland.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24e808d96068c3ab226fc66c5c6472dd529cd302
Author: Jacopo Mondi <jacopo+renesas@jmondi.org>
Date:   Mon Aug 5 17:55:15 2019 +0200

    iio: adc: max9611: Fix temperature reading in probe
    
    commit b9ddd5091160793ee9fac10da765cf3f53d2aaf0 upstream.
    
    The max9611 driver reads the die temperature at probe time to validate
    the communication channel. Use the actual read value to perform the test
    instead of the read function return value, which was mistakenly used so
    far.
    
    The temperature reading test was only successful because the 0 return
    value is in the range of supported temperatures.
    
    Fixes: 69780a3bbc0b ("iio: adc: Add Maxim max9611 ADC driver")
    Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit beed4c284a40347f3203137bdc114a6f2c30b0a5
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Aug 12 13:08:14 2019 +0100

    staging: comedi: dt3000: Fix rounding up of timer divisor
    
    commit 8e2a589a3fc36ce858d42e767c3bcd8fc62a512b upstream.
    
    `dt3k_ns_to_timer()` determines the prescaler and divisor to use to
    produce a desired timing period.  It is influenced by a rounding mode
    and can round the divisor up, down, or to the nearest value.  However,
    the code for rounding up currently does the same as rounding down!  Fix
    ir by using the `DIV_ROUND_UP()` macro to calculate the divisor when
    rounding up.
    
    Also, change the types of the `divider`, `base` and `prescale` variables
    from `int` to `unsigned int` to avoid mixing signed and unsigned types
    in the calculations.
    
    Also fix a typo in a nearby comment: "improvment" => "improvement".
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190812120814.21188-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c8b1c3659c75c83bd48e8d3b0b8a24a3f29052b
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Aug 12 12:15:17 2019 +0100

    staging: comedi: dt3000: Fix signed integer overflow 'divider * base'
    
    commit b4d98bc3fc93ec3a58459948a2c0e0c9b501cd88 upstream.
    
    In `dt3k_ns_to_timer()` the following lines near the end of the function
    result in a signed integer overflow:
    
            prescale = 15;
            base = timer_base * (1 << prescale);
            divider = 65535;
            *nanosec = divider * base;
    
    (`divider`, `base` and `prescale` are type `int`, `timer_base` and
    `*nanosec` are type `unsigned int`.  The value of `timer_base` will be
    either 50 or 100.)
    
    The main reason for the overflow is that the calculation for `base` is
    completely wrong.  It should be:
    
            base = timer_base * (prescale + 1);
    
    which matches an earlier instance of this calculation in the same
    function.
    
    Reported-by: David Binderman <dcb314@hotmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20190812111517.26803-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 672980bd9c5c96a2851041fd32116d780210cfbc
Author: Marc Zyngier <maz@kernel.org>
Date:   Fri Aug 2 10:28:32 2019 +0100

    KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block
    
    commit 5eeaf10eec394b28fad2c58f1f5c3a5da0e87d1c upstream.
    
    Since commit commit 328e56647944 ("KVM: arm/arm64: vgic: Defer
    touching GICH_VMCR to vcpu_load/put"), we leave ICH_VMCR_EL2 (or
    its GICv2 equivalent) loaded as long as we can, only syncing it
    back when we're scheduled out.
    
    There is a small snag with that though: kvm_vgic_vcpu_pending_irq(),
    which is indirectly called from kvm_vcpu_check_block(), needs to
    evaluate the guest's view of ICC_PMR_EL1. At the point were we
    call kvm_vcpu_check_block(), the vcpu is still loaded, and whatever
    changes to PMR is not visible in memory until we do a vcpu_put().
    
    Things go really south if the guest does the following:
    
            mov x0, #0      // or any small value masking interrupts
            msr ICC_PMR_EL1, x0
    
            [vcpu preempted, then rescheduled, VMCR sampled]
    
            mov x0, #ff     // allow all interrupts
            msr ICC_PMR_EL1, x0
            wfi             // traps to EL2, so samping of VMCR
    
            [interrupt arrives just after WFI]
    
    Here, the hypervisor's view of PMR is zero, while the guest has enabled
    its interrupts. kvm_vgic_vcpu_pending_irq() will then say that no
    interrupts are pending (despite an interrupt being received) and we'll
    block for no reason. If the guest doesn't have a periodic interrupt
    firing once it has blocked, it will stay there forever.
    
    To avoid this unfortuante situation, let's resync VMCR from
    kvm_arch_vcpu_blocking(), ensuring that a following kvm_vcpu_check_block()
    will observe the latest value of PMR.
    
    This has been found by booting an arm64 Linux guest with the pseudo NMI
    feature, and thus using interrupt priorities to mask interrupts instead
    of the usual PSTATE masking.
    
    Cc: stable@vger.kernel.org # 4.12
    Fixes: 328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43b3942c9d69a951cd9a82c19cfd285c903e1200
Author: Qian Cai <cai@lca.pw>
Date:   Fri Aug 2 21:49:19 2019 -0700

    asm-generic: fix -Wtype-limits compiler warnings
    
    [ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
    
    Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
    compilation warning because "rx_frag_size" is an "ushort" while
    PAGE_SHIFT here is 16.
    
    The commit changed the get_order() to be a multi-line macro where
    compilers insist to check all statements in the macro even when
    __builtin_constant_p(rx_frag_size) will return false as "rx_frag_size"
    is a module parameter.
    
    In file included from ./arch/powerpc/include/asm/page_64.h:107,
                     from ./arch/powerpc/include/asm/page.h:242,
                     from ./arch/powerpc/include/asm/mmu.h:132,
                     from ./arch/powerpc/include/asm/lppaca.h:47,
                     from ./arch/powerpc/include/asm/paca.h:17,
                     from ./arch/powerpc/include/asm/current.h:13,
                     from ./include/linux/thread_info.h:21,
                     from ./arch/powerpc/include/asm/processor.h:39,
                     from ./include/linux/prefetch.h:15,
                     from drivers/net/ethernet/emulex/benet/be_main.c:14:
    drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_rx_cqs_create':
    ./include/asm-generic/getorder.h:54:9: warning: comparison is always
    true due to limited range of data type [-Wtype-limits]
       (((n) < (1UL << PAGE_SHIFT)) ? 0 :  \
             ^
    drivers/net/ethernet/emulex/benet/be_main.c:3138:33: note: in expansion
    of macro 'get_order'
      adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
                                     ^~~~~~~~~
    
    Fix it by moving all of this multi-line macro into a proper function,
    and killing __get_order() off.
    
    [akpm@linux-foundation.org: remove __get_order() altogether]
    [cai@lca.pw: v2]
      Link: http://lkml.kernel.org/r/1564000166-31428-1-git-send-email-cai@lca.pw
    Link: http://lkml.kernel.org/r/1563914986-26502-1-git-send-email-cai@lca.pw
    Fixes: d66acc39c7ce ("bitops: Optimise get_order()")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: James Y Knight <jyknight@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aae6206781fa542bd8528ed05f3c4ee90cfd4f5e
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Aug 2 21:48:40 2019 -0700

    ocfs2: remove set but not used variable 'last_hash'
    
    [ Upstream commit 7bc36e3ce91471b6377c8eadc0a2f220a2280083 ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
      fs/ocfs2/xattr.c: In function ocfs2_xattr_bucket_find:
      fs/ocfs2/xattr.c:3828:6: warning: variable last_hash set but not used [-Wunused-but-set-variable]
    
    It's never used and can be removed.
    
    Link: http://lkml.kernel.org/r/20190716132110.34836-1-yuehaibing@huawei.com
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3da4da7728a5cee1524a7d62659c02f66ef109a4
Author: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Date:   Wed Jun 26 11:00:15 2019 -0700

    drm: msm: Fix add_gpu_components
    
    [ Upstream commit 9ca7ad6c7706edeae331c1632d0c63897418ebad ]
    
    add_gpu_components() adds found GPU nodes from the DT to the match list,
    regardless of the status of the nodes.  This is a problem, because if the
    nodes are disabled, they should not be on the match list because they will
    not be matched.  This prevents display from initing if a GPU node is
    defined, but it's status is disabled.
    
    Fix this by checking the node's status before adding it to the match list.
    
    Fixes: dc3ea265b856 (drm/msm: Drop the gpu binding)
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f0cd54d0215b0da243f252db6eb255383390965
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Aug 1 15:14:49 2019 +0300

    IB/mad: Fix use-after-free in ib mad completion handling
    
    [ Upstream commit 770b7d96cfff6a8bf6c9f261ba6f135dc9edf484 ]
    
    We encountered a use-after-free bug when unloading the driver:
    
    [ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
    [ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862
    [ 3562.118385]
    [ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G           OE     5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1
    [ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
    [ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
    [ 3562.124383] Call Trace:
    [ 3562.125640]  dump_stack+0x9a/0xeb
    [ 3562.126911]  print_address_description+0xe3/0x2e0
    [ 3562.128223]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
    [ 3562.129545]  __kasan_report+0x15c/0x1df
    [ 3562.130866]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
    [ 3562.132174]  kasan_report+0xe/0x20
    [ 3562.133514]  ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
    [ 3562.134835]  ? find_mad_agent+0xa00/0xa00 [ib_core]
    [ 3562.136158]  ? qlist_free_all+0x51/0xb0
    [ 3562.137498]  ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib]
    [ 3562.138833]  ? quarantine_reduce+0x1fa/0x270
    [ 3562.140171]  ? kasan_unpoison_shadow+0x30/0x40
    [ 3562.141522]  ib_mad_recv_done+0xdf6/0x3000 [ib_core]
    [ 3562.142880]  ? _raw_spin_unlock_irqrestore+0x46/0x70
    [ 3562.144277]  ? ib_mad_send_done+0x1810/0x1810 [ib_core]
    [ 3562.145649]  ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib]
    [ 3562.147008]  ? _raw_spin_unlock_irqrestore+0x46/0x70
    [ 3562.148380]  ? debug_object_deactivate+0x2b9/0x4a0
    [ 3562.149814]  __ib_process_cq+0xe2/0x1d0 [ib_core]
    [ 3562.151195]  ib_cq_poll_work+0x45/0xf0 [ib_core]
    [ 3562.152577]  process_one_work+0x90c/0x1860
    [ 3562.153959]  ? pwq_dec_nr_in_flight+0x320/0x320
    [ 3562.155320]  worker_thread+0x87/0xbb0
    [ 3562.156687]  ? __kthread_parkme+0xb6/0x180
    [ 3562.158058]  ? process_one_work+0x1860/0x1860
    [ 3562.159429]  kthread+0x320/0x3e0
    [ 3562.161391]  ? kthread_park+0x120/0x120
    [ 3562.162744]  ret_from_fork+0x24/0x30
    ...
    [ 3562.187615] Freed by task 31682:
    [ 3562.188602]  save_stack+0x19/0x80
    [ 3562.189586]  __kasan_slab_free+0x11d/0x160
    [ 3562.190571]  kfree+0xf5/0x2f0
    [ 3562.191552]  ib_mad_port_close+0x200/0x380 [ib_core]
    [ 3562.192538]  ib_mad_remove_device+0xf0/0x230 [ib_core]
    [ 3562.193538]  remove_client_context+0xa6/0xe0 [ib_core]
    [ 3562.194514]  disable_device+0x14e/0x260 [ib_core]
    [ 3562.195488]  __ib_unregister_device+0x79/0x150 [ib_core]
    [ 3562.196462]  ib_unregister_device+0x21/0x30 [ib_core]
    [ 3562.197439]  mlx4_ib_remove+0x162/0x690 [mlx4_ib]
    [ 3562.198408]  mlx4_remove_device+0x204/0x2c0 [mlx4_core]
    [ 3562.199381]  mlx4_unregister_interface+0x49/0x1d0 [mlx4_core]
    [ 3562.200356]  mlx4_ib_cleanup+0xc/0x1d [mlx4_ib]
    [ 3562.201329]  __x64_sys_delete_module+0x2d2/0x400
    [ 3562.202288]  do_syscall_64+0x95/0x470
    [ 3562.203277]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    The problem was that the MAD PD was deallocated before the MAD CQ.
    There was completion work pending for the CQ when the PD got deallocated.
    When the mad completion handling reached procedure
    ib_mad_post_receive_mads(), we got a use-after-free bug in the following
    line of code in that procedure:
       sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
    (the pd pointer in the above line is no longer valid, because the
    pd has been deallocated).
    
    We fix this by allocating the PD before the CQ in procedure
    ib_mad_port_open(), and deallocating the PD after freeing the CQ
    in procedure ib_mad_port_close().
    
    Since the CQ completion work queue is flushed during ib_free_cq(),
    no completions will be pending for that CQ when the PD is later
    deallocated.
    
    Note that freeing the CQ before deallocating the PD is the practice
    in the ULPs.
    
    Fixes: 4be90bc60df4 ("IB/mad: Remove ib_get_dma_mr calls")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.org
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11dc5bb9155ff000ddb85716d9587ddd80cd78ba
Author: Luck, Tony <tony.luck@intel.com>
Date:   Tue Jul 30 21:39:57 2019 -0700

    IB/core: Add mitigation for Spectre V1
    
    [ Upstream commit 61f259821dd3306e49b7d42a3f90fb5a4ff3351b ]
    
    Some processors may mispredict an array bounds check and
    speculatively access memory that they should not. With
    a user supplied array index we like to play things safe
    by masking the value with the array size before it is
    used as an index.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20190731043957.GA1600@agluck-desk2.amr.corp.intel.com
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecad92b10470d3a815cb9e379e8b2f1e50ac6032
Author: Qian Cai <cai@lca.pw>
Date:   Wed Jul 31 16:05:45 2019 -0400

    arm64/mm: fix variable 'pud' set but not used
    
    [ Upstream commit 7d4e2dcf311d3b98421d1f119efe5964cafa32fc ]
    
    GCC throws a warning,
    
    arch/arm64/mm/mmu.c: In function 'pud_free_pmd_page':
    arch/arm64/mm/mmu.c:1033:8: warning: variable 'pud' set but not used
    [-Wunused-but-set-variable]
      pud_t pud;
            ^~~
    
    because pud_table() is a macro and compiled away. Fix it by making it a
    static inline function and for pud_sect() as well.
    
    Signed-off-by: Qian Cai <cai@lca.pw>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5afb0d801471140c48286b29d65803c44f1f4d9b
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Jul 25 17:16:05 2019 +0900

    arm64: unwind: Prohibit probing on return_address()
    
    [ Upstream commit ee07b93e7721ccd5d5b9fa6f0c10cb3fe2f1f4f9 ]
    
    Prohibit probing on return_address() and subroutines which
    is called from return_address(), since the it is invoked from
    trace_hardirqs_off() which is also kprobe blacklisted.
    
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c14951e1ea6b9432fd9e83c8c79091d58f818da
Author: Qian Cai <cai@lca.pw>
Date:   Tue Jul 30 17:23:48 2019 -0400

    arm64/efi: fix variable 'si' set but not used
    
    [ Upstream commit f1d4836201543e88ebe70237e67938168d5fab19 ]
    
    GCC throws out this warning on arm64.
    
    drivers/firmware/efi/libstub/arm-stub.c: In function 'efi_entry':
    drivers/firmware/efi/libstub/arm-stub.c:132:22: warning: variable 'si'
    set but not used [-Wunused-but-set-variable]
    
    Fix it by making free_screen_info() a static inline function.
    
    Acked-by: Will Deacon <will@kernel.org>
    Signed-off-by: Qian Cai <cai@lca.pw>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f295b9ab64394e45aa2c35362b24012cb0e17074
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Wed Jul 31 00:59:00 2019 +0900

    kbuild: modpost: handle KBUILD_EXTRA_SYMBOLS only for external modules
    
    [ Upstream commit cb4819934a7f9b87876f11ed05b8624c0114551b ]
    
    KBUILD_EXTRA_SYMBOLS makes sense only when building external modules.
    Moreover, the modpost sets 'external_module' if the -e option is given.
    
    I replaced $(patsubst %, -e %,...) with simpler $(addprefix -e,...)
    while I was here.
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddc47dc28e163a27fe93ff0619b9b354388025af
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Jul 31 14:26:51 2019 +0200

    ata: libahci: do not complain in case of deferred probe
    
    [ Upstream commit 090bb803708198e5ab6b0046398c7ed9f4d12d6b ]
    
    Retrieving PHYs can defer the probe, do not spawn an error when
    -EPROBE_DEFER is returned, it is normal behavior.
    
    Fixes: b1a9edbda040 ("ata: libahci: allow to use multiple PHYs")
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f366bdf3f821d63bf4c4e02e1472cbe06e44b5a5
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Mon Jul 29 16:44:51 2019 +0800

    scsi: qla2xxx: Fix possible fcport null-pointer dereferences
    
    [ Upstream commit e82f04ec6ba91065fd33a6201ffd7cab840e1475 ]
    
    In qla2x00_alloc_fcport(), fcport is assigned to NULL in the error
    handling code on line 4880:
        fcport = NULL;
    
    Then fcport is used on lines 4883-4886:
        INIT_WORK(&fcport->del_work, qla24xx_delete_sess_fn);
            INIT_WORK(&fcport->reg_work, qla_register_fcport_fn);
            INIT_LIST_HEAD(&fcport->gnl_entry);
            INIT_LIST_HEAD(&fcport->list);
    
    Thus, possible null-pointer dereferences may occur.
    
    To fix these bugs, qla2x00_alloc_fcport() directly returns NULL
    in the error handling code.
    
    These bugs are found by a static analysis tool STCheck written by us.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d110628c3f5cbe59625c60b49438cfe49fe97578
Author: Don Brace <don.brace@microsemi.com>
Date:   Wed Jul 24 17:08:06 2019 -0500

    scsi: hpsa: correct scsi command status issue after reset
    
    [ Upstream commit eeebce1862970653cdf5c01e98bc669edd8f529a ]
    
    Reviewed-by: Bader Ali - Saleh <bader.alisaleh@microsemi.com>
    Reviewed-by: Scott Teel <scott.teel@microsemi.com>
    Reviewed-by: Scott Benesh <scott.benesh@microsemi.com>
    Reviewed-by: Kevin Barnett <kevin.barnett@microsemi.com>
    Signed-off-by: Don Brace <don.brace@microsemi.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0039f9766dd5103cf0ec0f844d2d0e638dcfc697
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon Jul 29 15:12:16 2019 +0800

    drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m
    
    [ Upstream commit f4cc743a98136df3c3763050a0e8223b52d9a960 ]
    
    If DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
    build fails:
    
    drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
    lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: dbb58bfd9ae6 ("drm/bridge: Fix lvds-encoder since the panel_bridge rework.")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190729071216.27488-1-yuehaibing@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f917417a06285620449b1e74e460cee2b3094cca
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Jul 29 14:47:22 2019 -0700

    libata: zpodd: Fix small read overflow in zpodd_get_mech_type()
    
    [ Upstream commit 71d6c505b4d9e6f76586350450e785e3d452b346 ]
    
    Jeffrin reported a KASAN issue:
    
      BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70
      Read of size 16 at addr ffffffff91f41f80 by task scsi_eh_1/149
      ...
      The buggy address belongs to the variable:
        cdb.48319+0x0/0x40
    
    Much like commit 18c9a99bce2a ("libata: zpodd: small read overflow in
    eject_tray()"), this fixes a cdb[] buffer length, this time in
    zpodd_get_mech_type():
    
    We read from the cdb[] buffer in ata_exec_internal_sg(). It has to be
    ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.
    
    Reported-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
    Fixes: afe759511808c ("libata: identify and init ZPODD devices")
    Link: https://lore.kernel.org/lkml/201907181423.E808958@keescook/
    Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83b9d5e3689b40353395475972bedec53e50e089
Author: Numfor Mbiziwo-Tiapo <nums@google.com>
Date:   Wed Jul 24 16:44:58 2019 -0700

    perf header: Fix use of unitialized value warning
    
    [ Upstream commit 20f9781f491360e7459c589705a2e4b1f136bee9 ]
    
    When building our local version of perf with MSAN (Memory Sanitizer) and
    running the perf record command, MSAN throws a use of uninitialized
    value warning in "tools/perf/util/util.c:333:6".
    
    This warning stems from the "buf" variable being passed into "write".
    It originated as the variable "ev" with the type union perf_event*
    defined in the "perf_event__synthesize_attr" function in
    "tools/perf/util/header.c".
    
    In the "perf_event__synthesize_attr" function they allocate space with a malloc
    call using ev, then go on to only assign some of the member variables before
    passing "ev" on as a parameter to the "process" function therefore "ev"
    contains uninitialized memory. Changing the malloc call to zalloc to initialize
    all the members of "ev" which gets rid of the warning.
    
    To reproduce this warning, build perf by running:
    make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
     -fsanitize-memory-track-origins"
    
    (Additionally, llvm might have to be installed and clang might have to
    be specified as the compiler - export CC=/usr/bin/clang)
    
    then running:
    tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate\
     -i - --stdio
    
    Please see the cover letter for why false positive warnings may be
    generated.
    
    Signed-off-by: Numfor Mbiziwo-Tiapo <nums@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Drayton <mbd@fb.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lkml.kernel.org/r/20190724234500.253358-2-nums@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 577b3ccbb8259a4e76177cedb837c076f5e69111
Author: Vince Weaver <vincent.weaver@maine.edu>
Date:   Tue Jul 23 11:06:01 2019 -0400

    perf header: Fix divide by zero error if f_header.attr_size==0
    
    [ Upstream commit 7622236ceb167aa3857395f9bdaf871442aa467e ]
    
    So I have been having lots of trouble with hand-crafted perf.data files
    causing segfaults and the like, so I have started fuzzing the perf tool.
    
    First issue found:
    
    If f_header.attr_size is 0 in the perf.data file, then perf will crash
    with a divide-by-zero error.
    
    Committer note:
    
    Added a pr_err() to tell the user why the command failed.
    
    Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1907231100440.14532@macbook-air
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31afdd903a1d6738f503694e1bb38af3e9b98fea
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Jul 12 15:29:05 2019 +0200

    irqchip/irq-imx-gpcv2: Forward irq type to parent
    
    [ Upstream commit 9a446ef08f3bfc0c3deb9c6be840af2528ef8cf8 ]
    
    The GPCv2 is a stacked IRQ controller below the ARM GIC. It doesn't
    care about the IRQ type itself, but needs to forward the type to the
    parent IRQ controller, so this one can be configured correctly.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acc760f32a07bc0ecd653526366f2e03ae17ae32
Author: Nianyao Tang <tangnianyao@huawei.com>
Date:   Fri Jul 26 17:32:57 2019 +0800

    irqchip/gic-v3-its: Free unused vpt_page when alloc vpe table fail
    
    [ Upstream commit 34f8eb92ca053cbba2887bb7e4dbf2b2cd6eb733 ]
    
    In its_vpe_init, when its_alloc_vpe_table fails, we should free
    vpt_page allocated just before, instead of vpe->vpt_page.
    Let's fix it.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jason Cooper <jason@lakedaemon.net>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
    Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0d12e58188156a2162ae54c23fe089122c0c31e
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jul 24 22:08:50 2019 +0800

    xen/pciback: remove set but not used variable 'old_state'
    
    [ Upstream commit 09e088a4903bd0dd911b4f1732b250130cdaffed ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    drivers/xen/xen-pciback/conf_space_capability.c: In function pm_ctrl_write:
    drivers/xen/xen-pciback/conf_space_capability.c:119:25: warning:
     variable old_state set but not used [-Wunused-but-set-variable]
    
    It is never used so can be removed.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 990ea5ad6744ae919b5e48dfde6b098fd12604f0
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Jul 11 15:03:59 2019 +0200

    clk: renesas: cpg-mssr: Fix reset control race condition
    
    [ Upstream commit e1f1ae8002e4b06addc52443fcd975bbf554ae92 ]
    
    The module reset code in the Renesas CPG/MSSR driver uses
    read-modify-write (RMW) operations to write to a Software Reset Register
    (SRCRn), and simple writes to write to a Software Reset Clearing
    Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
    User's Manuals.
    
    However, this may cause a race condition when two devices are reset in
    parallel: if the reset for device A completes in the middle of the RMW
    operation for device B, device A may be reset again, causing subtle
    failures (e.g. i2c timeouts):
    
            thread A                        thread B
            --------                        --------
    
            val = SRCRn
            val |= bit A
            SRCRn = val
    
            delay
    
                                            val = SRCRn (bit A is set)
    
            SRSTCLRn = bit A
            (bit A in SRCRn is cleared)
    
                                            val |= bit B
                                            SRCRn = val (bit A and B are set)
    
    This can be reproduced on e.g. Salvator-XS using:
    
        $ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done &
        $ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done &
    
        i2c-rcar e6510000.i2c: error -110 : 40000002
        i2c-rcar e66d8000.i2c: error -110 : 40000002
    
    According to the R-Car Gen3 Hardware Manual Errata for Rev.
    0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware
    User's Manual, writes to SRCRn do not require read-modify-write cycles.
    
    Note that the R-Car Gen2 Hardware User's Manual has not been updated
    yet, and still says a read-modify-write sequence is required.  According
    to the hardware team, the reset hardware block is the same on both R-Car
    Gen2 and Gen3, though.
    
    Hence fix the issue by replacing the read-modify-write operations on
    SRCRn by simple writes.
    
    Reported-by: Yao Lihua <Lihua.Yao@desay-svautomotive.com>
    Fixes: 6197aa65c4905532 ("clk: renesas: cpg-mssr: Add support for reset control")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Linh Phung <linh.phung.jy@renesas.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9b83c9eb96ebfc94cb47ffd058435a15f7484db
Author: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Date:   Tue Jun 25 12:10:02 2019 +0300

    clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1
    
    [ Upstream commit 1573eebeaa8055777eb753f9b4d1cbe653380c38 ]
    
    In clk_generated_determine_rate(), if the divisor is greater than
    GENERATED_MAX_DIV + 1, then the wrong best_rate will be returned.
    If clk_generated_set_rate() will be called later with this wrong
    rate, it will return -EINVAL, so the generated clock won't change
    its value. Do no let the divisor be greater than GENERATED_MAX_DIV + 1.
    
    Fixes: 8c7aa6328947 ("clk: at91: clk-generated: remove useless divisor loop")
    Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f896cbc0a66c8cfa886e4709e9c0483226447a1
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Jul 29 17:58:10 2019 +0200

    netfilter: ebtables: also count base chain policies
    
    commit 3b48300d5cc7c7bed63fddb006c4046549ed4aec upstream.
    
    ebtables doesn't include the base chain policies in the rule count,
    so we need to add them manually when we call into the x_tables core
    to allocate space for the comapt offset table.
    
    This lead syzbot to trigger:
    WARNING: CPU: 1 PID: 9012 at net/netfilter/x_tables.c:649
    xt_compat_add_offset.cold+0x11/0x36 net/netfilter/x_tables.c:649
    
    Reported-by: syzbot+276ddebab3382bbf72db@syzkaller.appspotmail.com
    Fixes: 2035f3ff8eaa ("netfilter: ebtables: compat: un-break 32bit setsockopt when no rules are present")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8176e66caedb1b8f0a9c2429e57e0c8dda127010
Author: Denis Kirjanov <kda@linux-powerpc.org>
Date:   Tue Jul 30 15:13:57 2019 +0200

    net: usb: pegasus: fix improper read if get_registers() fail
    
    commit 224c04973db1125fcebefffd86115f99f50f8277 upstream.
    
    get_registers() may fail with -ENOMEM and in this
    case we can read a garbage from the status variable tmp.
    
    Reported-by: syzbot+3499a83b2d062ae409d4@syzkaller.appspotmail.com
    Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ab425b091ff31dd8e2e0d4220b4f6e91e3da1d5
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Aug 6 09:05:55 2019 -0700

    Input: iforce - add sanity checks
    
    commit 849f5ae3a513c550cad741c68dd3d7eb2bcc2a2c upstream.
    
    The endpoint type should also be checked before a device
    is accepted.
    
    Reported-by: syzbot+5efc10c005014d061a74@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbfcffcbe92ba39ec7d45674e8e987c7b5335d38
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Aug 1 09:44:25 2019 -0700

    Input: kbtab - sanity check for endpoint type
    
    commit c88090dfc84254fa149174eb3e6a8458de1912c4 upstream.
    
    The driver should check whether the endpoint it uses has the correct
    type.
    
    Reported-by: syzbot+c7df50363aaff50aa363@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d65ca54d05c209571cf2b3913277f75ab477e214
Author: Hillf Danton <hdanton@sina.com>
Date:   Tue Aug 6 16:40:15 2019 +0800

    HID: hiddev: do cleanup in failure of opening a device
    
    commit 6d4472d7bec39917b54e4e80245784ea5d60ce49 upstream.
    
    Undo what we did for opening before releasing the memory slice.
    
    Reported-by: syzbot <syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4239114d88c9e017139d54c744065842d8271dff
Author: Hillf Danton <hdanton@sina.com>
Date:   Tue Aug 6 16:38:58 2019 +0800

    HID: hiddev: avoid opening a disconnected device
    
    commit 9c09b214f30e3c11f9b0b03f89442df03643794d upstream.
    
    syzbot found the following crash on:
    
    HEAD commit:    e96407b4 usb-fuzzer: main usb gadget fuzzer driver
    git tree:       https://github.com/google/kasan.git usb-fuzzer
    console output: https://syzkaller.appspot.com/x/log.txt?x=147ac20c600000
    kernel config:  https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
    dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e
    compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
    
    ==================================================================
    BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50
    kernel/locking/lockdep.c:3753
    Read of size 8 at addr ffff8881cf591a08 by task syz-executor.1/26260
    
    CPU: 1 PID: 26260 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #24
    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+0xca/0x13e lib/dump_stack.c:113
      print_address_description+0x6a/0x32c mm/kasan/report.c:351
      __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
      kasan_report+0xe/0x12 mm/kasan/common.c:612
      __lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753
      lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
      __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
      _raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
      hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221
      __fput+0x2d7/0x840 fs/file_table.c:280
      task_work_run+0x13f/0x1c0 kernel/task_work.c:113
      exit_task_work include/linux/task_work.h:22 [inline]
      do_exit+0x8ef/0x2c50 kernel/exit.c:878
      do_group_exit+0x125/0x340 kernel/exit.c:982
      get_signal+0x466/0x23d0 kernel/signal.c:2728
      do_signal+0x88/0x14e0 arch/x86/kernel/signal.c:815
      exit_to_usermode_loop+0x1a2/0x200 arch/x86/entry/common.c:159
      prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
      syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
      do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x459829
    Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
    48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
    ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007f75b2a6ccf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
    RAX: fffffffffffffe00 RBX: 000000000075c078 RCX: 0000000000459829
    RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000075c078
    RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 000000000075c07c
    R13: 00007ffcdfe1023f R14: 00007f75b2a6d9c0 R15: 000000000075c07c
    
    Allocated by task 104:
      save_stack+0x1b/0x80 mm/kasan/common.c:69
      set_track mm/kasan/common.c:77 [inline]
      __kasan_kmalloc mm/kasan/common.c:487 [inline]
      __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
      kmalloc include/linux/slab.h:552 [inline]
      kzalloc include/linux/slab.h:748 [inline]
      hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900
      hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
      hid_hw_start drivers/hid/hid-core.c:1981 [inline]
      hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
      appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
      hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
      really_probe+0x281/0x650 drivers/base/dd.c:548
      driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      __device_attach+0x217/0x360 drivers/base/dd.c:882
      bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
      device_add+0xae6/0x16f0 drivers/base/core.c:2114
      hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
      usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
      usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
      really_probe+0x281/0x650 drivers/base/dd.c:548
      driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      __device_attach+0x217/0x360 drivers/base/dd.c:882
      bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
      device_add+0xae6/0x16f0 drivers/base/core.c:2114
      usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
      generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
      usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
      really_probe+0x281/0x650 drivers/base/dd.c:548
      driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      __device_attach+0x217/0x360 drivers/base/dd.c:882
      bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
      device_add+0xae6/0x16f0 drivers/base/core.c:2114
      usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
      hub_port_connect drivers/usb/core/hub.c:5098 [inline]
      hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
      port_event drivers/usb/core/hub.c:5359 [inline]
      hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
      process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
      worker_thread+0x96/0xe20 kernel/workqueue.c:2415
      kthread+0x318/0x420 kernel/kthread.c:255
      ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    
    Freed by task 104:
      save_stack+0x1b/0x80 mm/kasan/common.c:69
      set_track mm/kasan/common.c:77 [inline]
      __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
      slab_free_hook mm/slub.c:1423 [inline]
      slab_free_freelist_hook mm/slub.c:1470 [inline]
      slab_free mm/slub.c:3012 [inline]
      kfree+0xe4/0x2f0 mm/slub.c:3953
      hiddev_connect.cold+0x45/0x5c drivers/hid/usbhid/hiddev.c:914
      hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
      hid_hw_start drivers/hid/hid-core.c:1981 [inline]
      hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
      appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
      hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
      really_probe+0x281/0x650 drivers/base/dd.c:548
      driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      __device_attach+0x217/0x360 drivers/base/dd.c:882
      bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
      device_add+0xae6/0x16f0 drivers/base/core.c:2114
      hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
      usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
      usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
      really_probe+0x281/0x650 drivers/base/dd.c:548
      driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      __device_attach+0x217/0x360 drivers/base/dd.c:882
      bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
      device_add+0xae6/0x16f0 drivers/base/core.c:2114
      usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
      generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
      usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
      really_probe+0x281/0x650 drivers/base/dd.c:548
      driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      __device_attach+0x217/0x360 drivers/base/dd.c:882
      bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
      device_add+0xae6/0x16f0 drivers/base/core.c:2114
      usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
      hub_port_connect drivers/usb/core/hub.c:5098 [inline]
      hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
      port_event drivers/usb/core/hub.c:5359 [inline]
      hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
      process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
      worker_thread+0x96/0xe20 kernel/workqueue.c:2415
      kthread+0x318/0x420 kernel/kthread.c:255
      ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    
    The buggy address belongs to the object at ffff8881cf591900
      which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 264 bytes inside of
      512-byte region [ffff8881cf591900, ffff8881cf591b00)
    The buggy address belongs to the page:
    page:ffffea00073d6400 refcount:1 mapcount:0 mapping:ffff8881da002500
    index:0x0 compound_mapcount: 0
    flags: 0x200000000010200(slab|head)
    raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da002500
    raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
      ffff8881cf591900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8881cf591980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    > ffff8881cf591a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                           ^
      ffff8881cf591a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8881cf591b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    ==================================================================
    
    In order to avoid opening a disconnected device, we need to check exist
    again after acquiring the existance lock, and bail out if necessary.
    
    Reported-by: syzbot <syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32cfa39afe8ff13ca74ba5b1153472b4b87ad91f
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Jul 25 15:13:33 2019 +0200

    HID: holtek: test for sanity of intfdata
    
    commit 01ec0a5f19c8c82960a07f6c7410fc9e01d7fb51 upstream.
    
    The ioctl handler uses the intfdata of a second interface,
    which may not be present in a broken or malicious device, hence
    the intfdata needs to be checked for NULL.
    
    [jkosina@suse.cz: fix newly added spurious space]
    Reported-by: syzbot+965152643a75a56737be@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3bbd13899e57cc0d2e7c31c7d2284b978611fc1
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Aug 14 12:09:07 2019 +0800

    ALSA: hda - Let all conexant codec enter D3 when rebooting
    
    commit 401714d9534aad8c24196b32600da683116bbe09 upstream.
    
    We have 3 new lenovo laptops which have conexant codec 0x14f11f86,
    these 3 laptops also have the noise issue when rebooting, after
    letting the codec enter D3 before rebooting or poweroff, the noise
    disappers.
    
    Instead of adding a new ID again in the reboot_notify(), let us make
    this function apply to all conexant codec. In theory make codec enter
    D3 before rebooting or poweroff is harmless, and I tested this change
    on a couple of other Lenovo laptops which have different conexant
    codecs, there is no side effect so far.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0412f12fe287331b116cd5f5d13e54921a070649
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Aug 14 12:09:08 2019 +0800

    ALSA: hda - Add a generic reboot_notify
    
    commit 871b9066027702e6e6589da0e1edd3b7dede7205 upstream.
    
    Make codec enter D3 before rebooting or poweroff can fix the noise
    issue on some laptops. And in theory it is harmless for all codecs
    to enter D3 before rebooting or poweroff, let us add a generic
    reboot_notify, then realtek and conexant drivers can call this
    function.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9de28f8872f76f754c48f023c2b34db455a4d27b
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Fri Aug 9 23:29:48 2019 -0500

    ALSA: hda - Fix a memory leak bug
    
    commit cfef67f016e4c00a2f423256fc678a6967a9fc09 upstream.
    
    In snd_hda_parse_generic_codec(), 'spec' is allocated through kzalloc().
    Then, the pin widgets in 'codec' are parsed. However, if the parsing
    process fails, 'spec' is not deallocated, leading to a memory leak.
    
    To fix the above issue, free 'spec' before returning the error.
    
    Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser")
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64d581bb9a5ffc9dc2598ec26d90fc5574258c9f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Aug 9 11:23:00 2019 +0200

    ALSA: hda - Apply workaround for another AMD chip 1022:1487
    
    commit de768ce45466f3009809719eb7b1f6f5277d9373 upstream.
    
    MSI MPG X570 board is with another AMD HD-audio controller (PCI ID
    1022:1487) and it requires the same workaround applied for X370, etc
    (PCI ID 1022:1457).
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2e9581f18c4cbc63fd0da670b532136bb27f8d3
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Aug 12 15:01:30 2019 -0700

    xtensa: add missing isync to the cpu_reset TLB code
    
    commit cd8869f4cb257f22b89495ca40f5281e58ba359c upstream.
    
    ITLB entry modifications must be followed by the isync instruction
    before the new entries are possibly used. cpu_reset lacks one isync
    between ITLB way 6 initialization and jump to the identity mapping.
    Add missing isync to xtensa cpu_reset.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bcb4a1b81f55f8391b7c5e57a5b540af749fe2c
Author: Nadav Amit <namit@vmware.com>
Date:   Fri Aug 16 23:05:46 2019 +0100

    x86/mm: Use WRITE_ONCE() when setting PTEs
    
    commit 9bc4f28af75a91aea0ae383f50b0a430c4509303 upstream.
    
    When page-table entries are set, the compiler might optimize their
    assignment by using multiple instructions to set the PTE. This might
    turn into a security hazard if the user somehow manages to use the
    interim PTE. L1TF does not make our lives easier, making even an interim
    non-present PTE a security hazard.
    
    Using WRITE_ONCE() to set PTEs and friends should prevent this potential
    security hazard.
    
    I skimmed the differences in the binary with and without this patch. The
    differences are (obviously) greater when CONFIG_PARAVIRT=n as more
    code optimizations are possible. For better and worse, the impact on the
    binary with this patch is pretty small. Skimming the code did not cause
    anything to jump out as a security hazard, but it seems that at least
    move_soft_dirty_pte() caused set_pte_at() to use multiple writes.
    
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Sean Christopherson <sean.j.christopherson@intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Link: https://lkml.kernel.org/r/20180902181451.80520-1-namit@vmware.com
    [bwh: Backported to 4.14:
     - Drop changes in pmdp_establish()
     - 5-level paging is a compile-time option
     - Update both cases in native_set_pgd()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1fe647042affe713a17243cd10e9b25f3d83948
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Aug 16 23:05:36 2019 +0100

    bpf: add bpf_jit_limit knob to restrict unpriv allocations
    
    commit ede95a63b5e84ddeea6b0c473b36ab8bfd8c6ce3 upstream.
    
    Rick reported that the BPF JIT could potentially fill the entire module
    space with BPF programs from unprivileged users which would prevent later
    attempts to load normal kernel modules or privileged BPF programs, for
    example. If JIT was enabled but unsuccessful to generate the image, then
    before commit 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
    we would always fall back to the BPF interpreter. Nowadays in the case
    where the CONFIG_BPF_JIT_ALWAYS_ON could be set, then the load will abort
    with a failure since the BPF interpreter was compiled out.
    
    Add a global limit and enforce it for unprivileged users such that in case
    of BPF interpreter compiled out we fail once the limit has been reached
    or we fall back to BPF interpreter earlier w/o using module mem if latter
    was compiled in. In a next step, fair share among unprivileged users can
    be resolved in particular for the case where we would fail hard once limit
    is reached.
    
    Fixes: 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
    Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64")
    Co-Developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: LKML <linux-kernel@vger.kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3c69acfc7cea96c68b9af8af9ff13415839bbec
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Aug 16 23:05:20 2019 +0100

    bpf: restrict access to core bpf sysctls
    
    commit 2e4a30983b0f9b19b59e38bbf7427d7fdd480d98 upstream.
    
    Given BPF reaches far beyond just networking these days, it was
    never intended to allow setting and in some cases reading those
    knobs out of a user namespace root running without CAP_SYS_ADMIN,
    thus tighten such access.
    
    Also the bpf_jit_enable = 2 debugging mode should only be allowed
    if kptr_restrict is not set since it otherwise can leak addresses
    to the kernel log. Dump a note to the kernel log that this is for
    debugging JITs only when enabled.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    [bwh: Backported to 4.14: We don't have bpf_dump_raw_ok(), so drop the
     condition based on it. This condition only made it a bit harder for a
     privileged user to do something silly.]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 234646dcfc5f531c74ab20595e89eacd62e3611f
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Aug 16 23:04:32 2019 +0100

    bpf: get rid of pure_initcall dependency to enable jits
    
    commit fa9dd599b4dae841924b022768354cfde9affecb upstream.
    
    Having a pure_initcall() callback just to permanently enable BPF
    JITs under CONFIG_BPF_JIT_ALWAYS_ON is unnecessary and could leave
    a small race window in future where JIT is still disabled on boot.
    Since we know about the setting at compilation time anyway, just
    initialize it properly there. Also consolidate all the individual
    bpf_jit_enable variables into a single one and move them under one
    location. Moreover, don't allow for setting unspecified garbage
    values on them.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    [bwh: Backported to 4.14 as dependency of commit 2e4a30983b0f
     "bpf: restrict access to core bpf sysctls":
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4de1123478864d714efba0eaa4fc4ffc01709cc
Author: Miles Chen <miles.chen@mediatek.com>
Date:   Tue Aug 13 15:37:28 2019 -0700

    mm/memcontrol.c: fix use after free in mem_cgroup_iter()
    
    commit 54a83d6bcbf8f4700013766b974bf9190d40b689 upstream.
    
    This patch is sent to report an use after free in mem_cgroup_iter()
    after merging commit be2657752e9e ("mm: memcg: fix use after free in
    mem_cgroup_iter()").
    
    I work with android kernel tree (4.9 & 4.14), and commit be2657752e9e
    ("mm: memcg: fix use after free in mem_cgroup_iter()") has been merged
    to the trees.  However, I can still observe use after free issues
    addressed in the commit be2657752e9e.  (on low-end devices, a few times
    this month)
    
    backtrace:
            css_tryget <- crash here
            mem_cgroup_iter
            shrink_node
            shrink_zones
            do_try_to_free_pages
            try_to_free_pages
            __perform_reclaim
            __alloc_pages_direct_reclaim
            __alloc_pages_slowpath
            __alloc_pages_nodemask
    
    To debug, I poisoned mem_cgroup before freeing it:
    
      static void __mem_cgroup_free(struct mem_cgroup *memcg)
            for_each_node(node)
            free_mem_cgroup_per_node_info(memcg, node);
            free_percpu(memcg->stat);
      +     /* poison memcg before freeing it */
      +     memset(memcg, 0x78, sizeof(struct mem_cgroup));
            kfree(memcg);
      }
    
    The coredump shows the position=0xdbbc2a00 is freed.
    
      (gdb) p/x ((struct mem_cgroup_per_node *)0xe5009e00)->iter[8]
      $13 = {position = 0xdbbc2a00, generation = 0x2efd}
    
      0xdbbc2a00:     0xdbbc2e00      0x00000000      0xdbbc2800      0x00000100
      0xdbbc2a10:     0x00000200      0x78787878      0x00026218      0x00000000
      0xdbbc2a20:     0xdcad6000      0x00000001      0x78787800      0x00000000
      0xdbbc2a30:     0x78780000      0x00000000      0x0068fb84      0x78787878
      0xdbbc2a40:     0x78787878      0x78787878      0x78787878      0xe3fa5cc0
      0xdbbc2a50:     0x78787878      0x78787878      0x00000000      0x00000000
      0xdbbc2a60:     0x00000000      0x00000000      0x00000000      0x00000000
      0xdbbc2a70:     0x00000000      0x00000000      0x00000000      0x00000000
      0xdbbc2a80:     0x00000000      0x00000000      0x00000000      0x00000000
      0xdbbc2a90:     0x00000001      0x00000000      0x00000000      0x00100000
      0xdbbc2aa0:     0x00000001      0xdbbc2ac8      0x00000000      0x00000000
      0xdbbc2ab0:     0x00000000      0x00000000      0x00000000      0x00000000
      0xdbbc2ac0:     0x00000000      0x00000000      0xe5b02618      0x00001000
      0xdbbc2ad0:     0x00000000      0x78787878      0x78787878      0x78787878
      0xdbbc2ae0:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2af0:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b00:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b10:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b20:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b30:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b40:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b50:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b60:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b70:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2b80:     0x78787878      0x78787878      0x00000000      0x78787878
      0xdbbc2b90:     0x78787878      0x78787878      0x78787878      0x78787878
      0xdbbc2ba0:     0x78787878      0x78787878      0x78787878      0x78787878
    
    In the reclaim path, try_to_free_pages() does not setup
    sc.target_mem_cgroup and sc is passed to do_try_to_free_pages(), ...,
    shrink_node().
    
    In mem_cgroup_iter(), root is set to root_mem_cgroup because
    sc->target_mem_cgroup is NULL.  It is possible to assign a memcg to
    root_mem_cgroup.nodeinfo.iter in mem_cgroup_iter().
    
            try_to_free_pages
                    struct scan_control sc = {...}, target_mem_cgroup is 0x0;
            do_try_to_free_pages
            shrink_zones
            shrink_node
                     mem_cgroup *root = sc->target_mem_cgroup;
                     memcg = mem_cgroup_iter(root, NULL, &reclaim);
            mem_cgroup_iter()
                    if (!root)
                            root = root_mem_cgroup;
                    ...
    
                    css = css_next_descendant_pre(css, &root->css);
                    memcg = mem_cgroup_from_css(css);
                    cmpxchg(&iter->position, pos, memcg);
    
    My device uses memcg non-hierarchical mode.  When we release a memcg:
    invalidate_reclaim_iterators() reaches only dead_memcg and its parents.
    If non-hierarchical mode is used, invalidate_reclaim_iterators() never
    reaches root_mem_cgroup.
    
      static void invalidate_reclaim_iterators(struct mem_cgroup *dead_memcg)
      {
            struct mem_cgroup *memcg = dead_memcg;
    
            for (; memcg; memcg = parent_mem_cgroup(memcg)
            ...
      }
    
    So the use after free scenario looks like:
    
      CPU1                                          CPU2
    
      try_to_free_pages
      do_try_to_free_pages
      shrink_zones
      shrink_node
      mem_cgroup_iter()
          if (!root)
            root = root_mem_cgroup;
          ...
          css = css_next_descendant_pre(css, &root->css);
          memcg = mem_cgroup_from_css(css);
          cmpxchg(&iter->position, pos, memcg);
    
                                            invalidate_reclaim_iterators(memcg);
                                            ...
                                            __mem_cgroup_free()
                                                    kfree(memcg);
    
      try_to_free_pages
      do_try_to_free_pages
      shrink_zones
      shrink_node
      mem_cgroup_iter()
          if (!root)
            root = root_mem_cgroup;
          ...
          mz = mem_cgroup_nodeinfo(root, reclaim->pgdat->node_id);
          iter = &mz->iter[reclaim->priority];
          pos = READ_ONCE(iter->position);
          css_tryget(&pos->css) <- use after free
    
    To avoid this, we should also invalidate root_mem_cgroup.nodeinfo.iter
    in invalidate_reclaim_iterators().
    
    [cai@lca.pw: fix -Wparentheses compilation warning]
      Link: http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-cai@lca.pw
    Link: http://lkml.kernel.org/r/20190730015729.4406-1-miles.chen@mediatek.com
    Fixes: 5ac8fb31ad2e ("mm: memcontrol: convert reclaim iterator to simple css refcounting")
    Signed-off-by: Miles Chen <miles.chen@mediatek.com>
    Signed-off-by: Qian Cai <cai@lca.pw>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e7e8017a7c07a722d206f3084974dbbcad60a30
Author: Isaac J. Manjarres <isaacm@codeaurora.org>
Date:   Tue Aug 13 15:37:37 2019 -0700

    mm/usercopy: use memory range to be accessed for wraparound check
    
    commit 951531691c4bcaa59f56a316e018bc2ff1ddf855 upstream.
    
    Currently, when checking to see if accessing n bytes starting at address
    "ptr" will cause a wraparound in the memory addresses, the check in
    check_bogus_address() adds an extra byte, which is incorrect, as the
    range of addresses that will be accessed is [ptr, ptr + (n - 1)].
    
    This can lead to incorrectly detecting a wraparound in the memory
    address, when trying to read 4 KB from memory that is mapped to the the
    last possible page in the virtual address space, when in fact, accessing
    that range of memory would not cause a wraparound to occur.
    
    Use the memory range that will actually be accessed when considering if
    accessing a certain amount of bytes will cause the memory address to
    wrap around.
    
    Link: http://lkml.kernel.org/r/1564509253-23287-1-git-send-email-isaacm@codeaurora.org
    Fixes: f5509cc18daa ("mm: Hardened usercopy")
    Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
    Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
    Co-developed-by: Prasad Sodagudi <psodagud@codeaurora.org>
    Reviewed-by: William Kucharski <william.kucharski@oracle.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Trilok Soni <tsoni@codeaurora.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [kees: backport to v4.14]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f89256f5bb80129a5584898d5a43e11e0000cbe
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Fri Aug 9 23:43:56 2019 -0500

    sh: kernel: hw_breakpoint: Fix missing break in switch statement
    
    commit 1ee1119d184bb06af921b48c3021d921bbd85bac upstream.
    
    Add missing break statement in order to prevent the code from falling
    through to case SH_BREAKPOINT_WRITE.
    
    Fixes: 09a072947791 ("sh: hw-breakpoints: Add preliminary support for SH-4A UBC.")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25f99d0072600573e64d30c3a1aeda710e4c2571
Author: Suganath Prabu <suganath-prabu.subramani@broadcom.com>
Date:   Tue Jul 30 03:43:57 2019 -0400

    scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA
    
    commit df9a606184bfdb5ae3ca9d226184e9489f5c24f7 upstream.
    
    Although SAS3 & SAS3.5 IT HBA controllers support 64-bit DMA addressing, as
    per hardware design, if DMA-able range contains all 64-bits
    set (0xFFFFFFFF-FFFFFFFF) then it results in a firmware fault.
    
    E.g. SGE's start address is 0xFFFFFFFF-FFFF000 and data length is 0x1000
    bytes. when HBA tries to DMA the data at 0xFFFFFFFF-FFFFFFFF location then
    HBA will fault the firmware.
    
    Driver will set 63-bit DMA mask to ensure the above address will not be
    used.
    
    Cc: <stable@vger.kernel.org> # 5.1.20+
    Signed-off-by: Suganath Prabu <suganath-prabu.subramani@broadcom.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>