commit e6395b928d7374bf4289316988da727894fd4cde
Author: Alexandre Frade <admfrade@gmail.com>
Date:   Wed Jul 3 10:33:06 2019 -0300

    5.1.16-xanmod10
    
    Signed-off-by: Alexandre Frade <admfrade@gmail.com>

commit 5e727fa7713743264e201def5d296cc4af8c3b8d
Merge: e53f3f4f3e08 8584aaf1c326
Author: Alexandre Frade <admfrade@gmail.com>
Date:   Wed Jul 3 10:32:01 2019 -0300

    Merge tag 'v5.1.16' into 5.1
    
    This is the 5.1.16 stable release

commit 8584aaf1c3262ca17d1e4a614ede9179ef462bb0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jul 3 13:13:45 2019 +0200

    Linux 5.1.16

commit 25998210bb2c905d66590703ad11fdcb0cb3e55f
Author: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Date:   Fri May 24 13:52:19 2019 +0100

    arm64: insn: Fix ldadd instruction encoding
    
    commit c5e2edeb01ae9ffbdde95bdcdb6d3614ba1eb195 upstream.
    
    GCC 8.1.0 reports that the ldadd instruction encoding, recently added to
    insn.c, doesn't match the mask and couldn't possibly be identified:
    
     linux/arch/arm64/include/asm/insn.h: In function 'aarch64_insn_is_ldadd':
     linux/arch/arm64/include/asm/insn.h:280:257: warning: bitwise comparison always evaluates to false [-Wtautological-compare]
    
    Bits [31:30] normally encode the size of the instruction (1 to 8 bytes)
    and the current instruction value only encodes the 4- and 8-byte
    variants. At the moment only the BPF JIT needs this instruction, and
    doesn't require the 1- and 2-byte variants, but to be consistent with
    our other ldr and str instruction encodings, clear the size field in the
    insn value.
    
    Fixes: 34b8ab091f9ef57a ("bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd")
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf9513b45f6408f12e84fca6a7bf83f62ac9d1bc
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Jun 17 21:34:15 2019 +0800

    tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb
    
    commit c3bcde026684c62d7a2b6f626dc7cf763833875c upstream.
    
    udp_tunnel(6)_xmit_skb() called by tipc_udp_xmit() expects a tunnel device
    to count packets on dev->tstats, a perpcu variable. However, TIPC is using
    udp tunnel with no tunnel device, and pass the lower dev, like veth device
    that only initializes dev->lstats(a perpcu variable) when creating it.
    
    Later iptunnel_xmit_stats() called by ip(6)tunnel_xmit() thinks the dev as
    a tunnel device, and uses dev->tstats instead of dev->lstats. tstats' each
    pointer points to a bigger struct than lstats, so when tstats->tx_bytes is
    increased, other percpu variable's members could be overwritten.
    
    syzbot has reported quite a few crashes due to fib_nh_common percpu member
    'nhc_pcpu_rth_output' overwritten, call traces are like:
    
      BUG: KASAN: slab-out-of-bounds in rt_cache_valid+0x158/0x190
      net/ipv4/route.c:1556
        rt_cache_valid+0x158/0x190 net/ipv4/route.c:1556
        __mkroute_output net/ipv4/route.c:2332 [inline]
        ip_route_output_key_hash_rcu+0x819/0x2d50 net/ipv4/route.c:2564
        ip_route_output_key_hash+0x1ef/0x360 net/ipv4/route.c:2393
        __ip_route_output_key include/net/route.h:125 [inline]
        ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2651
        ip_route_output_key include/net/route.h:135 [inline]
      ...
    
    or:
    
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      RIP: 0010:dst_dev_put+0x24/0x290 net/core/dst.c:168
        <IRQ>
        rt_fibinfo_free_cpus net/ipv4/fib_semantics.c:200 [inline]
        free_fib_info_rcu+0x2e1/0x490 net/ipv4/fib_semantics.c:217
        __rcu_reclaim kernel/rcu/rcu.h:240 [inline]
        rcu_do_batch kernel/rcu/tree.c:2437 [inline]
        invoke_rcu_callbacks kernel/rcu/tree.c:2716 [inline]
        rcu_process_callbacks+0x100a/0x1ac0 kernel/rcu/tree.c:2697
      ...
    
    The issue exists since tunnel stats update is moved to iptunnel_xmit by
    Commit 039f50629b7f ("ip_tunnel: Move stats update to iptunnel_xmit()"),
    and here to fix it by passing a NULL tunnel dev to udp_tunnel(6)_xmit_skb
    so that the packets counting won't happen on dev->tstats.
    
    Reported-by: syzbot+9d4c12bfd45a58738d0a@syzkaller.appspotmail.com
    Reported-by: syzbot+a9e23ea2aa21044c2798@syzkaller.appspotmail.com
    Reported-by: syzbot+c4c4b2bb358bb936ad7e@syzkaller.appspotmail.com
    Reported-by: syzbot+0290d2290a607e035ba1@syzkaller.appspotmail.com
    Reported-by: syzbot+a43d8d4e7e8a7a9e149e@syzkaller.appspotmail.com
    Reported-by: syzbot+a47c5f4c6c00fc1ed16e@syzkaller.appspotmail.com
    Fixes: 039f50629b7f ("ip_tunnel: Move stats update to iptunnel_xmit()")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b74063b5f16ab816dece79eec1830870d472aa43
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Jun 19 13:34:44 2019 +0300

    fanotify: update connector fsid cache on add mark
    
    commit c285a2f01d692ef48d7243cf1072897bbd237407 upstream.
    
    When implementing connector fsid cache, we only initialized the cache
    when the first mark added to object was added by FAN_REPORT_FID group.
    We forgot to update conn->fsid when the second mark is added by
    FAN_REPORT_FID group to an already attached connector without fsid
    cache.
    
    Reported-and-tested-by: syzbot+c277e8e2f46414645508@syzkaller.appspotmail.com
    Fixes: 77115225acc6 ("fanotify: cache fsid in fsnotify_mark_connector")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 993a0821eb5b810bff67152a8005e1107f07a69d
Author: Jason Gunthorpe <jgg@mellanox.com>
Date:   Sun May 12 21:57:57 2019 -0300

    RDMA: Directly cast the sockaddr union to sockaddr
    
    commit 641114d2af312d39ca9bbc2369d18a5823da51c6 upstream.
    
    gcc 9 now does allocation size tracking and thinks that passing the member
    of a union and then accessing beyond that member's bounds is an overflow.
    
    Instead of using the union member, use the entire union with a cast to
    get to the sockaddr. gcc will now know that the memory extends the full
    size of the union.
    
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41dd902f6ec7bfc2185e27c5c0f6ef7cb158bc1f
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Apr 10 11:51:54 2019 +0100

    futex: Update comments and docs about return values of arch futex code
    
    commit 427503519739e779c0db8afe876c1b33f3ac60ae upstream.
    
    The architecture implementations of 'arch_futex_atomic_op_inuser()' and
    'futex_atomic_cmpxchg_inatomic()' are permitted to return only -EFAULT,
    -EAGAIN or -ENOSYS in the case of failure.
    
    Update the comments in the asm-generic/ implementation and also a stray
    reference in the robust futex documentation.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 272ca3913c8eaaa92086df6f78f108f2546e277d
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Apr 26 21:48:22 2019 +0200

    bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd
    
    commit 34b8ab091f9ef57a2bb3c8c8359a0a03a8abf2f9 upstream.
    
    Since ARMv8.1 supplement introduced LSE atomic instructions back in 2016,
    lets add support for STADD and use that in favor of LDXR / STXR loop for
    the XADD mapping if available. STADD is encoded as an alias for LDADD with
    XZR as the destination register, therefore add LDADD to the instruction
    encoder along with STADD as special case and use it in the JIT for CPUs
    that advertise LSE atomics in CPUID register. If immediate offset in the
    BPF XADD insn is 0, then use dst register directly instead of temporary
    one.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fac9c64326dd2176d59a97a7046b34de3edce2f9
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Apr 10 11:49:11 2019 +0100

    arm64: futex: Avoid copying out uninitialised stack in failed cmpxchg()
    
    commit 8e4e0ac02b449297b86498ac24db5786ddd9f647 upstream.
    
    Returning an error code from futex_atomic_cmpxchg_inatomic() indicates
    that the caller should not make any use of *uval, and should instead act
    upon on the value of the error code. Although this is implemented
    correctly in our futex code, we needlessly copy uninitialised stack to
    *uval in the error case, which can easily be avoided.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb3fb093b41f10315e93ca2974164243958a6f51
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Fri May 31 15:29:11 2019 -0700

    bpf: udp: ipv6: Avoid running reuseport's bpf_prog from __udp6_lib_err
    
    commit 4ac30c4b3659efac031818c418beb51e630d512d upstream.
    
    __udp6_lib_err() may be called when handling icmpv6 message. For example,
    the icmpv6 toobig(type=2).  __udp6_lib_lookup() is then called
    which may call reuseport_select_sock().  reuseport_select_sock() will
    call into a bpf_prog (if there is one).
    
    reuseport_select_sock() is expecting the skb->data pointing to the
    transport header (udphdr in this case).  For example, run_bpf_filter()
    is pulling the transport header.
    
    However, in the __udp6_lib_err() path, the skb->data is pointing to the
    ipv6hdr instead of the udphdr.
    
    One option is to pull and push the ipv6hdr in __udp6_lib_err().
    Instead of doing this, this patch follows how the original
    commit 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF")
    was done in IPv4, which has passed a NULL skb pointer to
    reuseport_select_sock().
    
    Fixes: 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF")
    Cc: Craig Gallek <kraig@google.com>
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Acked-by: Song Liu <songliubraving@fb.com>
    Acked-by: Craig Gallek <kraig@google.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da6dab6373b223a3f05df6b2236a3ffa81ed7cb8
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Fri May 31 15:29:13 2019 -0700

    bpf: udp: Avoid calling reuseport's bpf_prog from udp_gro
    
    commit 257a525fe2e49584842c504a92c27097407f778f upstream.
    
    When the commit a6024562ffd7 ("udp: Add GRO functions to UDP socket")
    added udp[46]_lib_lookup_skb to the udp_gro code path, it broke
    the reuseport_select_sock() assumption that skb->data is pointing
    to the transport header.
    
    This patch follows an earlier __udp6_lib_err() fix by
    passing a NULL skb to avoid calling the reuseport's bpf_prog.
    
    Fixes: a6024562ffd7 ("udp: Add GRO functions to UDP socket")
    Cc: Tom Herbert <tom@herbertland.com>
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Acked-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 591c18e3aed16fde52cfdfc4af094b2cfd5dd0f2
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Jun 7 01:48:57 2019 +0200

    bpf: fix unconnected udp hooks
    
    commit 983695fa676568fc0fe5ddd995c7267aabc24632 upstream.
    
    Intention of cgroup bind/connect/sendmsg BPF hooks is to act transparently
    to applications as also stated in original motivation in 7828f20e3779 ("Merge
    branch 'bpf-cgroup-bind-connect'"). When recently integrating the latter
    two hooks into Cilium to enable host based load-balancing with Kubernetes,
    I ran into the issue that pods couldn't start up as DNS got broken. Kubernetes
    typically sets up DNS as a service and is thus subject to load-balancing.
    
    Upon further debugging, it turns out that the cgroupv2 sendmsg BPF hooks API
    is currently insufficient and thus not usable as-is for standard applications
    shipped with most distros. To break down the issue we ran into with a simple
    example:
    
      # cat /etc/resolv.conf
      nameserver 147.75.207.207
      nameserver 147.75.207.208
    
    For the purpose of a simple test, we set up above IPs as service IPs and
    transparently redirect traffic to a different DNS backend server for that
    node:
    
      # cilium service list
      ID   Frontend            Backend
      1    147.75.207.207:53   1 => 8.8.8.8:53
      2    147.75.207.208:53   1 => 8.8.8.8:53
    
    The attached BPF program is basically selecting one of the backends if the
    service IP/port matches on the cgroup hook. DNS breaks here, because the
    hooks are not transparent enough to applications which have built-in msg_name
    address checks:
    
      # nslookup 1.1.1.1
      ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
      ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
      ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
      [...]
      ;; connection timed out; no servers could be reached
    
      # dig 1.1.1.1
      ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
      ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
      ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
      [...]
    
      ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
      ;; global options: +cmd
      ;; connection timed out; no servers could be reached
    
    For comparison, if none of the service IPs is used, and we tell nslookup
    to use 8.8.8.8 directly it works just fine, of course:
    
      # nslookup 1.1.1.1 8.8.8.8
      1.1.1.1.in-addr.arpa  name = one.one.one.one.
    
    In order to fix this and thus act more transparent to the application,
    this needs reverse translation on recvmsg() side. A minimal fix for this
    API is to add similar recvmsg() hooks behind the BPF cgroups static key
    such that the program can track state and replace the current sockaddr_in{,6}
    with the original service IP. From BPF side, this basically tracks the
    service tuple plus socket cookie in an LRU map where the reverse NAT can
    then be retrieved via map value as one example. Side-note: the BPF cgroups
    static key should be converted to a per-hook static key in future.
    
    Same example after this fix:
    
      # cilium service list
      ID   Frontend            Backend
      1    147.75.207.207:53   1 => 8.8.8.8:53
      2    147.75.207.208:53   1 => 8.8.8.8:53
    
    Lookups work fine now:
    
      # nslookup 1.1.1.1
      1.1.1.1.in-addr.arpa    name = one.one.one.one.
    
      Authoritative answers can be found from:
    
      # dig 1.1.1.1
    
      ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51550
      ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;1.1.1.1.                       IN      A
    
      ;; AUTHORITY SECTION:
      .                       23426   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2019052001 1800 900 604800 86400
    
      ;; Query time: 17 msec
      ;; SERVER: 147.75.207.207#53(147.75.207.207)
      ;; WHEN: Tue May 21 12:59:38 UTC 2019
      ;; MSG SIZE  rcvd: 111
    
    And from an actual packet level it shows that we're using the back end
    server when talking via 147.75.207.20{7,8} front end:
    
      # tcpdump -i any udp
      [...]
      12:59:52.698732 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
      12:59:52.698735 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
      12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
      12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
      [...]
    
    In order to be flexible and to have same semantics as in sendmsg BPF
    programs, we only allow return codes in [1,1] range. In the sendmsg case
    the program is called if msg->msg_name is present which can be the case
    in both, connected and unconnected UDP.
    
    The former only relies on the sockaddr_in{,6} passed via connect(2) if
    passed msg->msg_name was NULL. Therefore, on recvmsg side, we act in similar
    way to call into the BPF program whenever a non-NULL msg->msg_name was
    passed independent of sk->sk_state being TCP_ESTABLISHED or not. Note
    that for TCP case, the msg->msg_name is ignored in the regular recvmsg
    path and therefore not relevant.
    
    For the case of ip{,v6}_recv_error() paths, picked up via MSG_ERRQUEUE,
    the hook is not called. This is intentional as it aligns with the same
    semantics as in case of TCP cgroup BPF hooks right now. This might be
    better addressed in future through a different bpf_attach_type such
    that this case can be distinguished from the regular recvmsg paths,
    for example.
    
    Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Andrey Ignatov <rdna@fb.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Acked-by: Martynas Pumputis <m@lambda.lt>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a9fedc1ef4be2acb4fd4674f405c21c811e1505
Author: Matt Mullins <mmullins@fb.com>
Date:   Tue Jun 11 14:53:04 2019 -0700

    bpf: fix nested bpf tracepoints with per-cpu data
    
    commit 9594dc3c7e71b9f52bee1d7852eb3d4e3aea9e99 upstream.
    
    BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as
    they do not increment bpf_prog_active while executing.
    
    This enables three levels of nesting, to support
      - a kprobe or raw tp or perf event,
      - another one of the above that irq context happens to call, and
      - another one in nmi context
    (at most one of which may be a kprobe or perf event).
    
    Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data")
    Signed-off-by: Matt Mullins <mmullins@fb.com>
    Acked-by: Andrii Nakryiko <andriin@fb.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cec89761822f911527ba89ffda314fa4c0fad67
Author: Jonathan Lemon <jonathan.lemon@gmail.com>
Date:   Sat Jun 8 12:54:19 2019 -0700

    bpf: lpm_trie: check left child of last leftmost node for NULL
    
    commit da2577fdd0932ea4eefe73903f1130ee366767d2 upstream.
    
    If the leftmost parent node of the tree has does not have a child
    on the left side, then trie_get_next_key (and bpftool map dump) will
    not look at the child on the right.  This leads to the traversal
    missing elements.
    
    Lookup is not affected.
    
    Update selftest to handle this case.
    
    Reproducer:
    
     bpftool map create /sys/fs/bpf/lpm type lpm_trie key 6 \
         value 1 entries 256 name test_lpm flags 1
     bpftool map update pinned /sys/fs/bpf/lpm key  8 0 0 0  0   0 value 1
     bpftool map update pinned /sys/fs/bpf/lpm key 16 0 0 0  0 128 value 2
     bpftool map dump   pinned /sys/fs/bpf/lpm
    
    Returns only 1 element. (2 expected)
    
    Fixes: b471f2f1de8b ("bpf: implement MAP_GET_NEXT_KEY command for LPM_TRIE")
    Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7108c83502e822e52052eea7d13f9d3d8bc8dea0
Author: Martynas Pumputis <m@lambda.lt>
Date:   Wed Jun 12 18:05:40 2019 +0200

    bpf: simplify definition of BPF_FIB_LOOKUP related flags
    
    commit b1d6c15b9d824a58c5415673f374fac19e8eccdf upstream.
    
    Previously, the BPF_FIB_LOOKUP_{DIRECT,OUTPUT} flags in the BPF UAPI
    were defined with the help of BIT macro. This had the following issues:
    
    - In order to use any of the flags, a user was required to depend
      on <linux/bits.h>.
    - No other flag in bpf.h uses the macro, so it seems that an unwritten
      convention is to use (1 << (nr)) to define BPF-related flags.
    
    Fixes: 87f5fc7e48dd ("bpf: Provide helper to do forwarding lookups in kernel FIB table")
    Signed-off-by: Martynas Pumputis <m@lambda.lt>
    Acked-by: Andrii Nakryiko <andriin@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03c3e507e90eb4fc528ed52e77d9f9ae8e4edd64
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Sat Jun 22 08:46:37 2019 +0000

    net: aquantia: fix vlans not working over bridged network
    
    [ Upstream commit 48dd73d08d4dda47ee31cc8611fb16840fc16803 ]
    
    In configuration of vlan over bridge over aquantia device
    it was found that vlan tagged traffic is dropped on chip.
    
    The reason is that bridge device enables promisc mode,
    but in atlantic chip vlan filters will still apply.
    So we have to corellate promisc settings with vlan configuration.
    
    The solution is to track in a separate state variable the
    need of vlan forced promisc. And also consider generic
    promisc configuration when doing vlan filter config.
    
    Fixes: 7975d2aff5af ("net: aquantia: add support of rx-vlan-filter offload")
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9590d1d1b033cb3c1211a90c66b928a141d6b129
Author: Fei Li <lifei.shirley@bytedance.com>
Date:   Mon Jun 17 21:26:36 2019 +0800

    tun: wake up waitqueues after IFF_UP is set
    
    [ Upstream commit 72b319dc08b4924a29f5e2560ef6d966fa54c429 ]
    
    Currently after setting tap0 link up, the tun code wakes tx/rx waited
    queues up in tun_net_open() when .ndo_open() is called, however the
    IFF_UP flag has not been set yet. If there's already a wait queue, it
    would fail to transmit when checking the IFF_UP flag in tun_sendmsg().
    Then the saving vhost_poll_start() will add the wq into wqh until it
    is waken up again. Although this works when IFF_UP flag has been set
    when tun_chr_poll detects; this is not true if IFF_UP flag has not
    been set at that time. Sadly the latter case is a fatal error, as
    the wq will never be waken up in future unless later manually
    setting link up on purpose.
    
    Fix this by moving the wakeup process into the NETDEV_UP event
    notifying process, this makes sure IFF_UP has been set before all
    waited queues been waken up.
    
    Signed-off-by: Fei Li <lifei.shirley@bytedance.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a54c0c1d392138f2012c1f644c434cbeed4cac77
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Jun 25 00:28:19 2019 +0800

    tipc: check msg->req data len in tipc_nl_compat_bearer_disable
    
    [ Upstream commit 4f07b80c973348a99b5d2a32476a2e7877e94a05 ]
    
    This patch is to fix an uninit-value issue, reported by syzbot:
    
      BUG: KMSAN: uninit-value in memchr+0xce/0x110 lib/string.c:981
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0x191/0x1f0 lib/dump_stack.c:113
        kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
        __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
        memchr+0xce/0x110 lib/string.c:981
        string_is_valid net/tipc/netlink_compat.c:176 [inline]
        tipc_nl_compat_bearer_disable+0x2a1/0x480 net/tipc/netlink_compat.c:449
        __tipc_nl_compat_doit net/tipc/netlink_compat.c:327 [inline]
        tipc_nl_compat_doit+0x3ac/0xb00 net/tipc/netlink_compat.c:360
        tipc_nl_compat_handle net/tipc/netlink_compat.c:1178 [inline]
        tipc_nl_compat_recv+0x1b1b/0x27b0 net/tipc/netlink_compat.c:1281
    
    TLV_GET_DATA_LEN() may return a negtive int value, which will be
    used as size_t (becoming a big unsigned long) passed into memchr,
    cause this issue.
    
    Similar to what it does in tipc_nl_compat_bearer_enable(), this
    fix is to return -EINVAL when TLV_GET_DATA_LEN() is negtive in
    tipc_nl_compat_bearer_disable(), as well as in
    tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
    
    v1->v2:
      - add the missing Fixes tags per Eric's request.
    
    Fixes: 0762216c0ad2 ("tipc: fix uninit-value in tipc_nl_compat_bearer_enable")
    Fixes: 8b66fee7f8ee ("tipc: fix uninit-value in tipc_nl_compat_link_reset_stats")
    Reported-by: syzbot+30eaa8bf392f7fafffaf@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec7fafa68f287c290c08a07765cbb0772e3d7229
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Jun 20 18:39:28 2019 +0800

    tipc: change to use register_pernet_device
    
    [ Upstream commit c492d4c74dd3f87559883ffa0f94a8f1ae3fe5f5 ]
    
    This patch is to fix a dst defcnt leak, which can be reproduced by doing:
    
      # ip net a c; ip net a s; modprobe tipc
      # ip net e s ip l a n eth1 type veth peer n eth1 netns c
      # ip net e c ip l s lo up; ip net e c ip l s eth1 up
      # ip net e s ip l s lo up; ip net e s ip l s eth1 up
      # ip net e c ip a a 1.1.1.2/8 dev eth1
      # ip net e s ip a a 1.1.1.1/8 dev eth1
      # ip net e c tipc b e m udp n u1 localip 1.1.1.2
      # ip net e s tipc b e m udp n u1 localip 1.1.1.1
      # ip net d c; ip net d s; rmmod tipc
    
    and it will get stuck and keep logging the error:
    
      unregister_netdevice: waiting for lo to become free. Usage count = 1
    
    The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx
    path with udp_early_demux == 1, and this dst (eventually holding lo dev)
    can't be released as bearer's removal in tipc pernet .exit happens after
    lo dev's removal, default_device pernet .exit.
    
     "There are two distinct types of pernet_operations recognized: subsys and
      device.  At creation all subsys init functions are called before device
      init functions, and at destruction all device exit functions are called
      before subsys exit function."
    
    So by calling register_pernet_device instead to register tipc_net_ops, the
    pernet .exit() will be invoked earlier than loopback dev's removal when a
    netns is being destroyed, as fou/gue does.
    
    Note that vxlan and geneve udp tunnels don't have this issue, as the udp
    sock is released in their device ndo_stop().
    
    This fix is also necessary for tipc dst_cache, which will hold dsts on tx
    path and I will introduce in my next patch.
    
    Reported-by: Li Shuang <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a061216af44be711890d0153b4305553c98d9528
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Jun 27 00:03:39 2019 +0800

    team: Always enable vlan tx offload
    
    [ Upstream commit ee4297420d56a0033a8593e80b33fcc93fda8509 ]
    
    We should rather have vlan_tci filled all the way down
    to the transmitting netdevice and let it do the hw/sw
    vlan implementation.
    
    Suggested-by: Jiri Pirko <jiri@resnulli.us>
    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 6c616a135a6d9b8ff2f5aa65b6c0999530228058
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Jun 25 00:21:45 2019 +0800

    sctp: change to hold sk after auth shkey is created successfully
    
    [ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
    
    Now in sctp_endpoint_init(), it holds the sk then creates auth
    shkey. But when the creation fails, it doesn't release the sk,
    which causes a sk defcnf leak,
    
    Here to fix it by only holding the sk when auth shkey is created
    successfully.
    
    Fixes: a29a5bd4f5c3 ("[SCTP]: Implement SCTP-AUTH initializations.")
    Reported-by: syzbot+afabda3890cc2f765041@syzkaller.appspotmail.com
    Reported-by: syzbot+276ca1c77a19977c0130@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0962d139f22a4e889e686b86806767b99eda8086
Author: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Date:   Sun Jun 23 21:26:58 2019 -0700

    net/tls: fix page double free on TX cleanup
    
    [ Upstream commit 9354544cbccf68da1b047f8fb7b47630e3c8a59d ]
    
    With commit 94850257cf0f ("tls: Fix tls_device handling of partial records")
    a new path was introduced to cleanup partial records during sk_proto_close.
    This path does not handle the SW KTLS tx_list cleanup.
    
    This is unnecessary though since the free_resources calls for both
    SW and offload paths will cleanup a partial record.
    
    The visible effect is the following warning, but this bug also causes
    a page double free.
    
        WARNING: CPU: 7 PID: 4000 at net/core/stream.c:206 sk_stream_kill_queues+0x103/0x110
        RIP: 0010:sk_stream_kill_queues+0x103/0x110
        RSP: 0018:ffffb6df87e07bd0 EFLAGS: 00010206
        RAX: 0000000000000000 RBX: ffff8c21db4971c0 RCX: 0000000000000007
        RDX: ffffffffffffffa0 RSI: 000000000000001d RDI: ffff8c21db497270
        RBP: ffff8c21db497270 R08: ffff8c29f4748600 R09: 000000010020001a
        R10: ffffb6df87e07aa0 R11: ffffffff9a445600 R12: 0000000000000007
        R13: 0000000000000000 R14: ffff8c21f03f2900 R15: ffff8c21f03b8df0
        Call Trace:
         inet_csk_destroy_sock+0x55/0x100
         tcp_close+0x25d/0x400
         ? tcp_check_oom+0x120/0x120
         tls_sk_proto_close+0x127/0x1c0
         inet_release+0x3c/0x60
         __sock_release+0x3d/0xb0
         sock_close+0x11/0x20
         __fput+0xd8/0x210
         task_work_run+0x84/0xa0
         do_exit+0x2dc/0xb90
         ? release_sock+0x43/0x90
         do_group_exit+0x3a/0xa0
         get_signal+0x295/0x720
         do_signal+0x36/0x610
         ? SYSC_recvfrom+0x11d/0x130
         exit_to_usermode_loop+0x69/0xb0
         do_syscall_64+0x173/0x180
         entry_SYSCALL_64_after_hwframe+0x3d/0xa2
        RIP: 0033:0x7fe9b9abc10d
        RSP: 002b:00007fe9b19a1d48 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
        RAX: fffffffffffffe00 RBX: 0000000000000006 RCX: 00007fe9b9abc10d
        RDX: 0000000000000002 RSI: 0000000000000080 RDI: 00007fe948003430
        RBP: 00007fe948003410 R08: 00007fe948003430 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000246 R12: 00005603739d9080
        R13: 00007fe9b9ab9f90 R14: 00007fe948003430 R15: 0000000000000000
    
    Fixes: 94850257cf0f ("tls: Fix tls_device handling of partial records")
    Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6902fe436d068f8afeb34a0ac5dfdf2d99abd8d
Author: Roland Hii <roland.king.guan.hii@intel.com>
Date:   Wed Jun 19 22:41:48 2019 +0800

    net: stmmac: set IC bit when transmitting frames with HW timestamp
    
    [ Upstream commit d0bb82fd60183868f46c8ccc595a3d61c3334a18 ]
    
    When transmitting certain PTP frames, e.g. SYNC and DELAY_REQ, the
    PTP daemon, e.g. ptp4l, is polling the driver for the frame transmit
    hardware timestamp. The polling will most likely timeout if the tx
    coalesce is enabled due to the Interrupt-on-Completion (IC) bit is
    not set in tx descriptor for those frames.
    
    This patch will ignore the tx coalesce parameter and set the IC bit
    when transmitting PTP frames which need to report out the frame
    transmit hardware timestamp to user space.
    
    Fixes: f748be531d70 ("net: stmmac: Rework coalesce timer and fix multi-queue races")
    Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
    Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
    Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac086d4c5d0f54c3412472d343268df132b55328
Author: Roland Hii <roland.king.guan.hii@intel.com>
Date:   Wed Jun 19 22:13:48 2019 +0800

    net: stmmac: fixed new system time seconds value calculation
    
    [ Upstream commit a1e5388b4d5fc78688e5e9ee6641f779721d6291 ]
    
    When ADDSUB bit is set, the system time seconds field is calculated as
    the complement of the seconds part of the update value.
    
    For example, if 3.000000001 seconds need to be subtracted from the
    system time, this field is calculated as
    2^32 - 3 = 4294967296 - 3 = 0x100000000 - 3 = 0xFFFFFFFD
    
    Previously, the 0x100000000 is mistakenly written as 100000000.
    
    This is further simplified from
      sec = (0x100000000ULL - sec);
    to
      sec = -sec;
    
    Fixes: ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
    Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
    Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
    Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 505c925823144996daa030e4bbe26660569a0609
Author: JingYi Hou <houjingyi647@gmail.com>
Date:   Mon Jun 17 14:56:05 2019 +0800

    net: remove duplicate fetch in sock_getsockopt
    
    [ Upstream commit d0bae4a0e3d8c5690a885204d7eb2341a5b4884d ]
    
    In sock_getsockopt(), 'optlen' is fetched the first time from userspace.
    'len < 0' is then checked. Then in condition 'SO_MEMINFO', 'optlen' is
    fetched the second time from userspace.
    
    If change it between two fetches may cause security problems or unexpected
    behaivor, and there is no reason to fetch it a second time.
    
    To fix this, we need to remove the second fetch.
    
    Signed-off-by: JingYi Hou <houjingyi647@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65b2a8047939229a9e767b82d741bee4f8ac6b53
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jun 24 02:38:20 2019 -0700

    net/packet: fix memory leak in packet_set_ring()
    
    [ Upstream commit 55655e3d1197fff16a7a05088fb0e5eba50eac55 ]
    
    syzbot found we can leak memory in packet_set_ring(), if user application
    provides buggy parameters.
    
    Fixes: 7f953ab2ba46 ("af_packet: TX_RING support for TPACKET_V3")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Sowmini Varadhan <sowmini.varadhan@oracle.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 c79ab459bea42f66f5c4d161dc41f9d8e40ab4ff
Author: Stephen Suryaputra <ssuryaextr@gmail.com>
Date:   Mon Jun 24 20:14:06 2019 -0400

    ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop
    
    [ Upstream commit 38c73529de13e1e10914de7030b659a2f8b01c3b ]
    
    In commit 19e4e768064a8 ("ipv4: Fix raw socket lookup for local
    traffic"), the dif argument to __raw_v4_lookup() is coming from the
    returned value of inet_iif() but the change was done only for the first
    lookup. Subsequent lookups in the while loop still use skb->dev->ifIndex.
    
    Fixes: 19e4e768064a8 ("ipv4: Fix raw socket lookup for local traffic")
    Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc4fdb7d73ba4b4ecd9e12686ab64a6cdb3f2bb1
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jun 26 16:08:44 2019 +0800

    bonding: Always enable vlan tx offload
    
    [ Upstream commit 30d8177e8ac776d89d387fad547af6a0f599210e ]
    
    We build vlan on top of bonding interface, which vlan offload
    is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
    BOND_XMIT_POLICY_ENCAP34.
    
    Because vlan tx offload is off, vlan tci is cleared and skb push
    the vlan header in validate_xmit_vlan() while sending from vlan
    devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
    get information from protocol headers encapsulated within vlan,
    because 'nhoff' is points to IP header, so bond hashing is based
    on layer 2 info, which fails to distribute packets across slaves.
    
    This patch always enable bonding's vlan tx offload, pass the vlan
    packets to the slave devices with vlan tci, let them to handle
    vlan implementation.
    
    Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
    Suggested-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c14a0de97597f2022e83abb5cbb0144c231a4a33
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Tue Jun 25 17:57:49 2019 -0400

    af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
    
    [ Upstream commit 89ed5b519004a7706f50b70f611edbd3aaacff2c ]
    
    When an application is run that:
    a) Sets its scheduler to be SCHED_FIFO
    and
    b) Opens a memory mapped AF_PACKET socket, and sends frames with the
    MSG_DONTWAIT flag cleared, its possible for the application to hang
    forever in the kernel.  This occurs because when waiting, the code in
    tpacket_snd calls schedule, which under normal circumstances allows
    other tasks to run, including ksoftirqd, which in some cases is
    responsible for freeing the transmitted skb (which in AF_PACKET calls a
    destructor that flips the status bit of the transmitted frame back to
    available, allowing the transmitting task to complete).
    
    However, when the calling application is SCHED_FIFO, its priority is
    such that the schedule call immediately places the task back on the cpu,
    preventing ksoftirqd from freeing the skb, which in turn prevents the
    transmitting task from detecting that the transmission is complete.
    
    We can fix this by converting the schedule call to a completion
    mechanism.  By using a completion queue, we force the calling task, when
    it detects there are no more frames to send, to schedule itself off the
    cpu until such time as the last transmitted skb is freed, allowing
    forward progress to be made.
    
    Tested by myself and the reporter, with good results
    
    Change Notes:
    
    V1->V2:
            Enhance the sleep logic to support being interruptible and
    allowing for honoring to SK_SNDTIMEO (Willem de Bruijn)
    
    V2->V3:
            Rearrage the point at which we wait for the completion queue, to
    avoid needing to check for ph/skb being null at the end of the loop.
    Also move the complete call to the skb destructor to avoid needing to
    modify __packet_set_status.  Also gate calling complete on
    packet_read_pending returning zero to avoid multiple calls to complete.
    (Willem de Bruijn)
    
            Move timeo computation within loop, to re-fetch the socket
    timeout since we also use the timeo variable to record the return code
    from the wait_for_complete call (Neil Horman)
    
    V3->V4:
            Willem has requested that the control flow be restored to the
    previous state.  Doing so lets us eliminate the need for the
    po->wait_on_complete flag variable, and lets us get rid of the
    packet_next_frame function, but introduces another complexity.
    Specifically, but using the packet pending count, we can, if an
    applications calls sendmsg multiple times with MSG_DONTWAIT set, each
    set of transmitted frames, when complete, will cause
    tpacket_destruct_skb to issue a complete call, for which there will
    never be a wait_on_completion call.  This imbalance will lead to any
    future call to wait_for_completion here to return early, when the frames
    they sent may not have completed.  To correct this, we need to re-init
    the completion queue on every call to tpacket_snd before we enter the
    loop so as to ensure we wait properly for the frames we send in this
    iteration.
    
            Change the timeout and interrupted gotos to out_put rather than
    out_status so that we don't try to free a non-existant skb
            Clean up some extra newlines (Willem de Bruijn)
    
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: Matteo Croce <mcroce@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0730644e5602b5573401e091442acbee7e5778a1
Author: Paul Burton <paul.burton@mips.com>
Date:   Wed Jun 5 09:34:10 2019 +0100

    irqchip/mips-gic: Use the correct local interrupt map registers
    
    commit 6d4d367d0e9ffab4d64a3436256a6a052dc1195d upstream.
    
    The MIPS GIC contains a block of registers used to map local interrupts
    to a particular CPU interrupt pin. Since these registers are found at a
    consecutive range of addresses we access them using an index, via the
    (read|write)_gic_v[lo]_map accessor functions. We currently use values
    from enum mips_gic_local_interrupt as those indices.
    
    Unfortunately whilst enum mips_gic_local_interrupt provides the correct
    offsets for bits in the pending & mask registers, the ordering of the
    map registers is subtly different... Compared with the ordering of
    pending & mask bits, the map registers move the FDC from the end of the
    list to index 3 after the timer interrupt. As a result the performance
    counter & software interrupts are therefore at indices 4-6 rather than
    indices 3-5.
    
    Notably this causes problems with performance counter interrupts being
    incorrectly mapped on some systems, and presumably will also cause
    problems for FDC interrupts.
    
    Introduce a function to map from enum mips_gic_local_interrupt to the
    index of the corresponding map register, and use it to ensure we access
    the map registers for the correct interrupts.
    
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: a0dc5cb5e31b ("irqchip: mips-gic: Simplify gic_local_irq_domain_map()")
    Fixes: da61fcf9d62a ("irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs")
    Reported-and-tested-by: Archer Yan <ayan@wavecomp.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jason Cooper <jason@lakedaemon.net>
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dfe49ca70e10eef208b6d4a673f34d01bff0293
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Mon Jun 24 19:15:44 2019 -0400

    SUNRPC: Fix up calculation of client message length
    
    commit 7e3d3620974b743b91b1f9d0660061b1de20174c upstream.
    
    In the case where a record marker was used, xs_sendpages() needs
    to return the length of the payload + record marker so that we
    operate correctly in the case of a partial transmission.
    When the callers check return value, they therefore need to
    take into account the record marker length.
    
    Fixes: 06b5fc3ad94e ("Merge tag 'nfs-rdma-for-5.1-1'...")
    Cc: stable@vger.kernel.org # 5.1+
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b187fae6ee297f3bba913cfc8b6c2181bccae3dd
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu May 16 09:09:35 2019 +0200

    cpu/speculation: Warn on unsupported mitigations= parameter
    
    commit 1bf72720281770162c87990697eae1ba2f1d917a upstream.
    
    Currently, if the user specifies an unsupported mitigation strategy on the
    kernel command line, it will be ignored silently.  The code will fall back
    to the default strategy, possibly leaving the system more vulnerable than
    expected.
    
    This may happen due to e.g. a simple typo, or, for a stable kernel release,
    because not all mitigation strategies have been backported.
    
    Inform the user by printing a message.
    
    Fixes: 98af8452945c5565 ("cpu/speculation: Add 'mitigations=' cmdline option")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190516070935.22546-1-geert@linux-m68k.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82d0f7b68d939aa67b6adcb449a7753cbeee36b8
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Tue Jun 25 16:41:16 2019 -0400

    NFS/flexfiles: Use the correct TCP timeout for flexfiles I/O
    
    commit 68f461593f76bd5f17e87cdd0bea28f4278c7268 upstream.
    
    Fix a typo where we're confusing the default TCP retrans value
    (NFS_DEF_TCP_RETRANS) for the default TCP timeout value.
    
    Fixes: 15d03055cf39f ("pNFS/flexfiles: Set reasonable default ...")
    Cc: stable@vger.kernel.org # 4.8+
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5961ecad7121fec138ebee7d9eba4863f9dc6e7
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sun Jun 9 20:17:44 2019 +0200

    efi/memreserve: deal with memreserve entries in unmapped memory
    
    commit 18df7577adae6c6c778bf774b3aebcacbc1fb439 upstream.
    
    Ensure that the EFI memreserve entries can be accessed, even if they
    are located in memory that the kernel (e.g., a crashkernel) omits from
    the linear map.
    
    Fixes: 80424b02d42b ("efi: Reduce the amount of memblock reservations ...")
    Cc: <stable@vger.kernel.org> # 5.0+
    Reported-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
    Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
    Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 994f9a520c1ba3a5d8d585888da4e27ff9abfeb0
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Fri May 24 10:12:46 2019 -0400

    mm: fix page cache convergence regression
    
    commit 7b785645e8f13e17cbce492708cf6e7039d32e46 upstream.
    
    Since a28334862993 ("page cache: Finish XArray conversion"), on most
    major Linux distributions, the page cache doesn't correctly transition
    when the hot data set is changing, and leaves the new pages thrashing
    indefinitely instead of kicking out the cold ones.
    
    On a freshly booted, freshly ssh'd into virtual machine with 1G RAM
    running stock Arch Linux:
    
    [root@ham ~]# ./reclaimtest.sh
    + dd of=workingset-a bs=1M count=0 seek=600
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + ./mincore workingset-a
    153600/153600 workingset-a
    + dd of=workingset-b bs=1M count=0 seek=600
    + cat workingset-b
    + cat workingset-b
    + cat workingset-b
    + cat workingset-b
    + ./mincore workingset-a workingset-b
    104029/153600 workingset-a
    120086/153600 workingset-b
    + cat workingset-b
    + cat workingset-b
    + cat workingset-b
    + cat workingset-b
    + ./mincore workingset-a workingset-b
    104029/153600 workingset-a
    120268/153600 workingset-b
    
    workingset-b is a 600M file on a 1G host that is otherwise entirely
    idle. No matter how often it's being accessed, it won't get cached.
    
    While investigating, I noticed that the non-resident information gets
    aggressively reclaimed - /proc/vmstat::workingset_nodereclaim. This is
    a problem because a workingset transition like this relies on the
    non-resident information tracked in the page cache tree of evicted
    file ranges: when the cache faults are refaults of recently evicted
    cache, we challenge the existing active set, and that allows a new
    workingset to establish itself.
    
    Tracing the shrinker that maintains this memory revealed that all page
    cache tree nodes were allocated to the root cgroup. This is a problem,
    because 1) the shrinker sizes the amount of non-resident information
    it keeps to the size of the cgroup's other memory and 2) on most major
    Linux distributions, only kernel threads live in the root cgroup and
    everything else gets put into services or session groups:
    
    [root@ham ~]# cat /proc/self/cgroup
    0::/user.slice/user-0.slice/session-c1.scope
    
    As a result, we basically maintain no non-resident information for the
    workloads running on the system, thus breaking the caching algorithm.
    
    Looking through the code, I found the culprit in the above-mentioned
    patch: when switching from the radix tree to xarray, it dropped the
    __GFP_ACCOUNT flag from the tree node allocations - the flag that
    makes sure the allocated memory gets charged to and tracked by the
    cgroup of the calling process - in this case, the one doing the fault.
    
    To fix this, allow xarray users to specify per-tree flag that makes
    xarray allocate nodes using __GFP_ACCOUNT. Then restore the page cache
    tree annotation to request such cgroup tracking for the cache nodes.
    
    With this patch applied, the page cache correctly converges on new
    workingsets again after just a few iterations:
    
    [root@ham ~]# ./reclaimtest.sh
    + dd of=workingset-a bs=1M count=0 seek=600
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + cat workingset-a
    + ./mincore workingset-a
    153600/153600 workingset-a
    + dd of=workingset-b bs=1M count=0 seek=600
    + cat workingset-b
    + ./mincore workingset-a workingset-b
    124607/153600 workingset-a
    87876/153600 workingset-b
    + cat workingset-b
    + ./mincore workingset-a workingset-b
    81313/153600 workingset-a
    133321/153600 workingset-b
    + cat workingset-b
    + ./mincore workingset-a workingset-b
    63036/153600 workingset-a
    153600/153600 workingset-b
    
    Cc: stable@vger.kernel.org # 4.20+
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b901ec94de5181f936858dfb2c7f28ebe70e5a7
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Wed Jun 19 13:27:16 2019 -0700

    x86/resctrl: Prevent possible overrun during bitmap operations
    
    commit 32f010deab575199df4ebe7b6aec20c17bb7eccd upstream.
    
    While the DOC at the beginning of lib/bitmap.c explicitly states that
    "The number of valid bits in a given bitmap does _not_ need to be an
    exact multiple of BITS_PER_LONG.", some of the bitmap operations do
    indeed access BITS_PER_LONG portions of the provided bitmap no matter
    the size of the provided bitmap.
    
    For example, if find_first_bit() is provided with an 8 bit bitmap the
    operation will access BITS_PER_LONG bits from the provided bitmap. While
    the operation ensures that these extra bits do not affect the result,
    the memory is still accessed.
    
    The capacity bitmasks (CBMs) are typically stored in u32 since they
    can never exceed 32 bits. A few instances exist where a bitmap_*
    operation is performed on a CBM by simply pointing the bitmap operation
    to the stored u32 value.
    
    The consequence of this pattern is that some bitmap_* operations will
    access out-of-bounds memory when interacting with the provided CBM.
    
    This same issue has previously been addressed with commit 49e00eee0061
    ("x86/intel_rdt: Fix out-of-bounds memory access in CBM tests")
    but at that time not all instances of the issue were fixed.
    
    Fix this by using an unsigned long to store the capacity bitmask data
    that is passed to bitmap functions.
    
    Fixes: e651901187ab ("x86/intel_rdt: Introduce "bit_usage" to display cache allocations details")
    Fixes: f4e80d67a527 ("x86/intel_rdt: Resctrl files reflect pseudo-locked information")
    Fixes: 95f0b77efa57 ("x86/intel_rdt: Initialize new resource group with sane defaults")
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable <stable@vger.kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/58c9b6081fd9bf599af0dfc01a6fdd335768efef.1560975645.git.reinette.chatre@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c762ccd9d57fbe34d4439cc167ea59803b3fb05
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 18 22:31:40 2019 +0200

    x86/microcode: Fix the microcode load on CPU hotplug for real
    
    commit 5423f5ce5ca410b3646f355279e4e937d452e622 upstream.
    
    A recent change moved the microcode loader hotplug callback into the early
    startup phase which is running with interrupts disabled. It missed that
    the callbacks invoke sysfs functions which might sleep causing nice 'might
    sleep' splats with proper debugging enabled.
    
    Split the callbacks and only load the microcode in the early startup phase
    and move the sysfs handling back into the later threaded and preemptible
    bringup phase where it was before.
    
    Fixes: 78f4e932f776 ("x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1906182228350.1766@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aec2bbd7839c9d45609e78198dac3ddc9b91750
Author: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Date:   Mon Jun 10 13:20:10 2019 -0400

    x86/speculation: Allow guests to use SSBD even if host does not
    
    commit c1f7fec1eb6a2c86d01bc22afce772c743451d88 upstream.
    
    The bits set in x86_spec_ctrl_mask are used to calculate the guest's value
    of SPEC_CTRL that is written to the MSR before VMENTRY, and control which
    mitigations the guest can enable.  In the case of SSBD, unless the host has
    enabled SSBD always on mode (by passing "spec_store_bypass_disable=on" in
    the kernel parameters), the SSBD bit is not set in the mask and the guest
    can not properly enable the SSBD always on mitigation mode.
    
    This has been confirmed by running the SSBD PoC on a guest using the SSBD
    always on mitigation mode (booted with kernel parameter
    "spec_store_bypass_disable=on"), and verifying that the guest is vulnerable
    unless the host is also using SSBD always on mode. In addition, the guest
    OS incorrectly reports the SSB vulnerability as mitigated.
    
    Always set the SSBD bit in x86_spec_ctrl_mask when the host CPU supports
    it, allowing the guest to use SSBD whether or not the host has chosen to
    enable the mitigation in any of its modes.
    
    Fixes: be6fcb5478e9 ("x86/bugs: Rework spec_ctrl base and mask logic")
    Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
    Reviewed-by: Mark Kanda <mark.kanda@oracle.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: bp@alien8.de
    Cc: rkrcmar@redhat.com
    Cc: kvm@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1560187210-11054-1-git-send-email-alejandro.j.jimenez@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5fb2093f9e86abe7c742465a8e9908951c463d2
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 19 09:05:41 2019 +0200

    scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()
    
    commit 240b4cc8fd5db138b675297d4226ec46594d9b3b upstream.
    
    Once we unlock adapter->hw_lock in pvscsi_queue_lck() nothing prevents just
    queued scsi_cmnd from completing and freeing the request. Thus cmd->cmnd[0]
    dereference can dereference already freed request leading to kernel crashes
    or other issues (which one of our customers observed). Store cmd->cmnd[0]
    in a local variable before unlocking adapter->hw_lock to fix the issue.
    
    CC: <stable@vger.kernel.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddae0798dd1183183694977c2632e686ed317b06
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Jun 21 10:20:18 2019 -0600

    io_uring: ensure req->file is cleared on allocation
    
    commit 60c112b0ada09826cc4ae6a4e55df677f76f1313 upstream.
    
    Stephen reports:
    
    I hit the following General Protection Fault when testing io_uring via
    the io_uring engine in fio. This was on a VM running 5.2-rc5 and the
    latest version of fio. The issue occurs for both null_blk and fake NVMe
    drives. I have not tested bare metal or real NVMe SSDs. The fio script
    used is given below.
    
    [io_uring]
    time_based=1
    runtime=60
    filename=/dev/nvme2n1 (note /dev/nullb0 also fails)
    ioengine=io_uring
    bs=4k
    rw=readwrite
    direct=1
    fixedbufs=1
    sqthread_poll=1
    sqthread_poll_cpu=0
    
    general protection fault: 0000 [#1] SMP PTI
    CPU: 0 PID: 872 Comm: io_uring-sq Not tainted 5.2.0-rc5-cpacket-io-uring #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    RIP: 0010:fput_many+0x7/0x90
    Code: 01 48 85 ff 74 17 55 48 89 e5 53 48 8b 1f e8 a0 f9 ff ff 48 85 db 48 89 df 75 f0 5b 5d f3 c3 0f 1f 40 00 0f 1f 44 00 00 89 f6 <f0> 48 29 77 38 74 01 c3 55 48 89 e5 53 48 89 fb 65 48 \
    
    RSP: 0018:ffffadeb817ebc50 EFLAGS: 00010246
    RAX: 0000000000000004 RBX: ffff8f46ad477480 RCX: 0000000000001805
    RDX: 0000000000000000 RSI: 0000000000000001 RDI: f18b51b9a39552b5
    RBP: ffffadeb817ebc58 R08: ffff8f46b7a318c0 R09: 000000000000015d
    R10: ffffadeb817ebce8 R11: 0000000000000020 R12: ffff8f46ad4cd000
    R13: 00000000fffffff7 R14: ffffadeb817ebe30 R15: 0000000000000004
    FS:  0000000000000000(0000) GS:ffff8f46b7a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055828f0bbbf0 CR3: 0000000232176004 CR4: 00000000003606f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ? fput+0x13/0x20
     io_free_req+0x20/0x40
     io_put_req+0x1b/0x20
     io_submit_sqe+0x40a/0x680
     ? __switch_to_asm+0x34/0x70
     ? __switch_to_asm+0x40/0x70
     io_submit_sqes+0xb9/0x160
     ? io_submit_sqes+0xb9/0x160
     ? __switch_to_asm+0x40/0x70
     ? __switch_to_asm+0x34/0x70
     ? __schedule+0x3f2/0x6a0
     ? __switch_to_asm+0x34/0x70
     io_sq_thread+0x1af/0x470
     ? __switch_to_asm+0x34/0x70
     ? wait_woken+0x80/0x80
     ? __switch_to+0x85/0x410
     ? __switch_to_asm+0x40/0x70
     ? __switch_to_asm+0x34/0x70
     ? __schedule+0x3f2/0x6a0
     kthread+0x105/0x140
     ? io_submit_sqes+0x160/0x160
     ? kthread+0x105/0x140
     ? io_submit_sqes+0x160/0x160
     ? kthread_destroy_worker+0x50/0x50
     ret_from_fork+0x35/0x40
    
    which occurs because using a kernel side submission thread isn't valid
    without using fixed files (registered through io_uring_register()). This
    causes io_uring to put the request after logging an error, but before
    the file field is set in the request. If it happens to be non-zero, we
    attempt to fput() garbage.
    
    Fix this by ensuring that req->file is initialized when the request is
    allocated.
    
    Cc: stable@vger.kernel.org # 5.1+
    Reported-by: Stephen Bates <sbates@raithlin.com>
    Tested-by: Stephen Bates <sbates@raithlin.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25df4ce382c963f0c28fefd0bcbd49bd44ce9fdc
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Wed Jun 5 21:27:08 2019 +0800

    dm log writes: make sure super sector log updates are written in order
    
    commit 211ad4b733037f66f9be0a79eade3da7ab11cbb8 upstream.
    
    Currently, although we submit super bios in order (and super.nr_entries
    is incremented by each logged entry), submit_bio() is async so each
    super sector may not be written to log device in order and then the
    final nr_entries may be smaller than it should be.
    
    This problem can be reproduced by the xfstests generic/455 with ext4:
    
      QA output created by 455
     -Silence is golden
     +mark 'end' does not exist
    
    Fix this by serializing submission of super sectors to make sure each
    is written to the log disk in order.
    
    Fixes: 0e9cebe724597 ("dm: add log writes target")
    Cc: stable@vger.kernel.org
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Suggested-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e17b11ffedd6e935c507c39b92e9c8ddb88c3c9
Author: Gen Zhang <blackgod016574@gmail.com>
Date:   Wed May 29 09:33:20 2019 +0800

    dm init: fix incorrect uses of kstrndup()
    
    commit dec7e6494e1aea6bf676223da3429cd17ce0af79 upstream.
    
    Fix 2 kstrndup() calls with incorrect argument order.
    
    Fixes: 6bbc923dfcf5 ("dm: add support to directly boot to a mapped device")
    Cc: stable@vger.kernel.org # v5.1
    Signed-off-by: Gen Zhang <blackgod016574@gmail.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3d6fe0b33dfa707a37d0cd750bb2d191c3a64dc
Author: Huang Ying <ying.huang@intel.com>
Date:   Fri Jun 28 12:07:18 2019 -0700

    mm, swap: fix THP swap out
    
    commit 1a5f439c7c02837d943e528d46501564d4226757 upstream.
    
    0-Day test system reported some OOM regressions for several THP
    (Transparent Huge Page) swap test cases.  These regressions are bisected
    to 6861428921b5 ("block: always define BIO_MAX_PAGES as 256").  In the
    commit, BIO_MAX_PAGES is set to 256 even when THP swap is enabled.  So the
    bio_alloc(gfp_flags, 512) in get_swap_bio() may fail when swapping out
    THP.  That causes the OOM.
    
    As in the patch description of 6861428921b5 ("block: always define
    BIO_MAX_PAGES as 256"), THP swap should use multi-page bvec to write THP
    to swap space.  So the issue is fixed via doing that in get_swap_bio().
    
    BTW: I remember I have checked the THP swap code when 6861428921b5
    ("block: always define BIO_MAX_PAGES as 256") was merged, and thought the
    THP swap code needn't to be changed.  But apparently, I was wrong.  I
    should have done this at that time.
    
    Link: http://lkml.kernel.org/r/20190624075515.31040-1-ying.huang@intel.com
    Fixes: 6861428921b5 ("block: always define BIO_MAX_PAGES as 256")
    Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    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 00553cdd3377b0ff11a0d4e39e0b824049eab013
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Jun 28 12:07:05 2019 -0700

    mm/page_idle.c: fix oops because end_pfn is larger than max_pfn
    
    commit 7298e3b0a149c91323b3205d325e942c3b3b9ef6 upstream.
    
    Currently the calcuation of end_pfn can round up the pfn number to more
    than the actual maximum number of pfns, causing an Oops.  Fix this by
    ensuring end_pfn is never more than max_pfn.
    
    This can be easily triggered when on systems where the end_pfn gets
    rounded up to more than max_pfn using the idle-page stress-ng stress test:
    
    sudo stress-ng --idle-page 0
    
      BUG: unable to handle kernel paging request at 00000000000020d8
      #PF error: [normal kernel read fault]
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      CPU: 1 PID: 11039 Comm: stress-ng-idle- Not tainted 5.0.0-5-generic #6-Ubuntu
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:page_idle_get_page+0xc8/0x1a0
      Code: 0f b1 0a 75 7d 48 8b 03 48 89 c2 48 c1 e8 33 83 e0 07 48 c1 ea 36 48 8d 0c 40 4c 8d 24 88 49 c1 e4 07 4c 03 24 d5 00 89 c3 be <49> 8b 44 24 58 48 8d b8 80 a1 02 00 e8 07 d5 77 00 48 8b 53 08 48
      RSP: 0018:ffffafd7c672fde8 EFLAGS: 00010202
      RAX: 0000000000000005 RBX: ffffe36341fff700 RCX: 000000000000000f
      RDX: 0000000000000284 RSI: 0000000000000275 RDI: 0000000001fff700
      RBP: ffffafd7c672fe00 R08: ffffa0bc34056410 R09: 0000000000000276
      R10: ffffa0bc754e9b40 R11: ffffa0bc330f6400 R12: 0000000000002080
      R13: ffffe36341fff700 R14: 0000000000080000 R15: ffffa0bc330f6400
      FS: 00007f0ec1ea5740(0000) GS:ffffa0bc7db00000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000020d8 CR3: 0000000077d68000 CR4: 00000000000006e0
      Call Trace:
        page_idle_bitmap_write+0x8c/0x140
        sysfs_kf_bin_write+0x5c/0x70
        kernfs_fop_write+0x12e/0x1b0
        __vfs_write+0x1b/0x40
        vfs_write+0xab/0x1b0
        ksys_write+0x55/0xc0
        __x64_sys_write+0x1a/0x20
        do_syscall_64+0x5a/0x110
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Link: http://lkml.kernel.org/r/20190618124352.28307-1-colin.king@canonical.com
    Fixes: 33c3fc71c8cf ("mm: introduce idle page tracking")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.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 59d44003b0a91800abc17bfe4fdb00682bfdc364
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Fri Jun 28 12:06:56 2019 -0700

    mm: hugetlb: soft-offline: dissolve_free_huge_page() return zero on !PageHuge
    
    commit faf53def3b143df11062d87c12afe6afeb6f8cc7 upstream.
    
    madvise(MADV_SOFT_OFFLINE) often returns -EBUSY when calling soft offline
    for hugepages with overcommitting enabled.  That was caused by the
    suboptimal code in current soft-offline code.  See the following part:
    
        ret = migrate_pages(&pagelist, new_page, NULL, MPOL_MF_MOVE_ALL,
                                MIGRATE_SYNC, MR_MEMORY_FAILURE);
        if (ret) {
                ...
        } else {
                /*
                 * We set PG_hwpoison only when the migration source hugepage
                 * was successfully dissolved, because otherwise hwpoisoned
                 * hugepage remains on free hugepage list, then userspace will
                 * find it as SIGBUS by allocation failure. That's not expected
                 * in soft-offlining.
                 */
                ret = dissolve_free_huge_page(page);
                if (!ret) {
                        if (set_hwpoison_free_buddy_page(page))
                                num_poisoned_pages_inc();
                }
        }
        return ret;
    
    Here dissolve_free_huge_page() returns -EBUSY if the migration source page
    was freed into buddy in migrate_pages(), but even in that case we actually
    has a chance that set_hwpoison_free_buddy_page() succeeds.  So that means
    current code gives up offlining too early now.
    
    dissolve_free_huge_page() checks that a given hugepage is suitable for
    dissolving, where we should return success for !PageHuge() case because
    the given hugepage is considered as already dissolved.
    
    This change also affects other callers of dissolve_free_huge_page(), which
    are cleaned up together.
    
    [n-horiguchi@ah.jp.nec.com: v3]
      Link: http://lkml.kernel.org/r/1560761476-4651-3-git-send-email-n-horiguchi@ah.jp.nec.comLink: http://lkml.kernel.org/r/1560154686-18497-3-git-send-email-n-horiguchi@ah.jp.nec.com
    Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reported-by: Chen, Jerry T <jerry.t.chen@intel.com>
    Tested-by: Chen, Jerry T <jerry.t.chen@intel.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Xishi Qiu <xishi.qiuxishi@alibaba-inc.com>
    Cc: "Chen, Jerry T" <jerry.t.chen@intel.com>
    Cc: "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>
    Cc: <stable@vger.kernel.org>    [4.19+]
    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 897b17e012adce36976ce76f1ca36f2831927159
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Fri Jun 28 12:06:53 2019 -0700

    mm: soft-offline: return -EBUSY if set_hwpoison_free_buddy_page() fails
    
    commit b38e5962f8ed0d2a2b28a887fc2221f7f41db119 upstream.
    
    The pass/fail of soft offline should be judged by checking whether the
    raw error page was finally contained or not (i.e.  the result of
    set_hwpoison_free_buddy_page()), but current code do not work like
    that.  It might lead us to misjudge the test result when
    set_hwpoison_free_buddy_page() fails.
    
    Without this fix, there are cases where madvise(MADV_SOFT_OFFLINE) may
    not offline the original page and will not return an error.
    
    Link: http://lkml.kernel.org/r/1560154686-18497-2-git-send-email-n-horiguchi@ah.jp.nec.com
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Xishi Qiu <xishi.qiuxishi@alibaba-inc.com>
    Cc: "Chen, Jerry T" <jerry.t.chen@intel.com>
    Cc: "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>
    Cc: <stable@vger.kernel.org>    [4.19+]
    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 ec73bed9027f26336ab9f4a40970324e42e478a5
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Mar 27 12:13:21 2019 +0200

    drm/i915: Skip modeset for cdclk changes if possible
    
    commit 59f9e9cab3a1e6762fb707d0d829b982930f1349 upstream.
    
    If we have only a single active pipe and the cdclk change only requires
    the cd2x divider to be updated bxt+ can do the update with forcing a full
    modeset on the pipe. Try to hook that up.
    
    v2:
    - Wait for vblank after an optimized CDCLK change.
    - Avoid optimization if the pipe needs a modeset (or was disabled).
    - Split CDCLK change to a pre/post plane update step.
    v3:
    - Use correct version of CDCLK state as old state. (Ville)
    - Remove unused intel_cdclk_can_skip_modeset()
    v4:
    - For consistency call intel_set_cdclk_post_plane_update() only during
      modesets (and not fastsets).
    v5:
    - Remove the logic to update the CD2X divider on-the-fly on ICL, since
      only a divider of 1 is supported there. Clint also noticed that the
      pipe select bits in CDCLK_CTL are oddly defined on ICL, it's not clear
      yet whether that's only an error in the specification.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
    Tested-by: Abhay Kumar <abhay.kumar@intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190327101321.3095-1-imre.deak@intel.com
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 994f9ddbd1a5fbfea297b5760f862d3e866e1149
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Mar 20 15:54:38 2019 +0200

    drm/i915: Remove redundant store of logical CDCLK state
    
    commit 2b21dfbeee725778daed2c3dd45a3fc808176feb upstream.
    
    We copied the original state into the atomic state already earlier in
    the function, so no need to do it a second time.
    
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190320135439.12201-3-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>

commit ca2d66597e7456c0cbfd68067db14239730a4fac
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Mar 20 15:54:37 2019 +0200

    drm/i915: Save the old CDCLK atomic state
    
    commit 48d9f87ddd2108663fd866b254e05d422243cc56 upstream.
    
    The old state will be needed by an upcoming patch to determine if the
    commit increases or decreases CDCLK, so move the old state to the atomic
    state (while keeping the new one in dev_priv). cdclk.logical and
    cdclk.actual in the atomic state isn't used atm anywhere after the
    atomic check phase, so this should be safe.
    
    v2:
    - Use swap() instead of opencoding it. (Ville)
    
    Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190320135439.12201-2-imre.deak@intel.com
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64e3d1c9f0e8001d0bd5ecedc0641b88755d255c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Mar 20 15:54:36 2019 +0200

    drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
    
    commit 905801fe72377b4dc53c6e13eea1a91c6a4aa0c4 upstream.
    
    CDCLK has to be at least twice the BLCK regardless of audio. Audio
    driver has to probe using this hook and increase the clock even in
    absence of any display.
    
    v2: Use atomic refcount for get_power, put_power so that we can
        call each once(Abhay).
    v3: Reset power well 2 to avoid any transaction on iDisp link
        during cdclk change(Abhay).
    v4: Remove Power well 2 reset workaround(Ville).
    v5: Remove unwanted Power well 2 register defined in v4(Abhay).
    v6:
    - Use a dedicated flag instead of state->modeset for min CDCLK changes
    - Make get/put audio power domain symmetric
    - Rebased on top of intel_wakeref tracking changes.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
    Tested-by: Abhay Kumar <abhay.kumar@intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190320135439.12201-1-imre.deak@intel.com
    Cc: <stable@vger.kernel.org> # 5.1.x
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203623
    Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=110916
    Link: https://www.spinics.net/lists/stable/msg310910.html
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 261b9429c577f913d3a5c60aa914901ed699e97a
Author: Dinh Nguyen <dinguyen@kernel.org>
Date:   Fri Jun 7 10:12:46 2019 -0500

    clk: socfpga: stratix10: fix divider entry for the emac clocks
    
    commit 74684cce5ebd567b01e9bc0e9a1945c70a32f32f upstream.
    
    The fixed dividers for the emac clocks should be 2 not 4.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87cdb0596c561b150683cdad0f9bdf0faa4d7424
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Wed Jun 5 15:01:39 2019 +0100

    clk: tegra210: Fix default rates for HDA clocks
    
    commit 9caec6620f25b6d15646bbdb93062c872ba3b56f upstream.
    
    Currently the default clock rates for the HDA and HDA2CODEC_2X clocks
    are both 19.2MHz. However, the default rates for these clocks should
    actually be 51MHz and 48MHz, respectively. The current clock settings
    results in a distorted output during audio playback. Correct the default
    clock rates for these clocks by specifying them in the clock init table
    for Tegra210.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecace84283e77c2ac21ba0ef398fc433636fe686
Author: Jann Horn <jannh@google.com>
Date:   Fri Jun 28 12:06:46 2019 -0700

    fs/binfmt_flat.c: make load_flat_shared_library() work
    
    commit 867bfa4a5fcee66f2b25639acae718e8b28b25a5 upstream.
    
    load_flat_shared_library() is broken: It only calls load_flat_file() if
    prepare_binprm() returns zero, but prepare_binprm() returns the number of
    bytes read - so this only happens if the file is empty.
    
    Instead, call into load_flat_file() if the number of bytes read is
    non-negative. (Even if the number of bytes is zero - in that case,
    load_flat_file() will see nullbytes and return a nice -ENOEXEC.)
    
    In addition, remove the code related to bprm creds and stop using
    prepare_binprm() - this code is loading a library, not a main executable,
    and it only actually uses the members "buf", "file" and "filename" of the
    linux_binprm struct. Instead, call kernel_read() directly.
    
    Link: http://lkml.kernel.org/r/20190524201817.16509-1-jannh@google.com
    Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
    Signed-off-by: Jann Horn <jannh@google.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Greg Ungerer <gerg@linux-m68k.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41ceb21b7dc18e9369e9b903b46b8334744f5cfb
Author: zhong jiang <zhongjiang@huawei.com>
Date:   Fri Jun 28 12:06:43 2019 -0700

    mm/mempolicy.c: fix an incorrect rebind node in mpol_rebind_nodemask
    
    commit 29b190fa774dd1b72a1a6f19687d55dc72ea83be upstream.
    
    mpol_rebind_nodemask() is called for MPOL_BIND and MPOL_INTERLEAVE
    mempoclicies when the tasks's cpuset's mems_allowed changes.  For
    policies created without MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES,
    it works by remapping the policy's allowed nodes (stored in v.nodes)
    using the previous value of mems_allowed (stored in
    w.cpuset_mems_allowed) as the domain of map and the new mems_allowed
    (passed as nodes) as the range of the map (see the comment of
    bitmap_remap() for details).
    
    The result of remapping is stored back as policy's nodemask in v.nodes,
    and the new value of mems_allowed should be stored in
    w.cpuset_mems_allowed to facilitate the next rebind, if it happens.
    
    However, 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies
    when updating cpusets") introduced a bug where the result of remapping
    is stored in w.cpuset_mems_allowed instead.  Thus, a mempolicy's
    allowed nodes can evolve in an unexpected way after a series of
    rebinding due to cpuset mems_allowed changes, possibly binding to a
    wrong node or a smaller number of nodes which may e.g.  overload them.
    This patch fixes the bug so rebinding again works as intended.
    
    [vbabka@suse.cz: new changlog]
      Link: http://lkml.kernel.org/r/ef6a69c6-c052-b067-8f2c-9d615c619bb9@suse.cz
    Link: http://lkml.kernel.org/r/1558768043-23184-1-git-send-email-zhongjiang@huawei.com
    Fixes: 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies when updating cpusets")
    Signed-off-by: zhong jiang <zhongjiang@huawei.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Ralph Campbell <rcampbell@nvidia.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 f1fb34c22786829fb58564d36609a05483ea9002
Author: John Ogness <john.ogness@linutronix.de>
Date:   Fri Jun 28 12:06:40 2019 -0700

    fs/proc/array.c: allow reporting eip/esp for all coredumping threads
    
    commit cb8f381f1613cafe3aec30809991cd56e7135d92 upstream.
    
    0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat")
    stopped reporting eip/esp and fd7d56270b52 ("fs/proc: Report eip/esp in
    /prod/PID/stat for coredumping") reintroduced the feature to fix a
    regression with userspace core dump handlers (such as minicoredumper).
    
    Because PF_DUMPCORE is only set for the primary thread, this didn't fix
    the original problem for secondary threads.  Allow reporting the eip/esp
    for all threads by checking for PF_EXITING as well.  This is set for all
    the other threads when they are killed.  coredump_wait() waits for all the
    tasks to become inactive before proceeding to invoke a core dumper.
    
    Link: http://lkml.kernel.org/r/87y32p7i7a.fsf@linutronix.de
    Link: http://lkml.kernel.org/r/20190522161614.628-1-jlu@pengutronix.de
    Fixes: fd7d56270b526ca3 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reported-by: Jan Luebbe <jlu@pengutronix.de>
    Tested-by: Jan Luebbe <jlu@pengutronix.de>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d750447128f20c74fb89b3bdff8fc7fb7ccdec9
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jun 24 18:45:11 2019 +0200

    qmi_wwan: Fix out-of-bounds read
    
    [ Upstream commit 904d88d743b0c94092c5117955eab695df8109e8 ]
    
    The syzbot reported
    
     Call Trace:
      __dump_stack lib/dump_stack.c:77 [inline]
      dump_stack+0xca/0x13e lib/dump_stack.c:113
      print_address_description+0x67/0x231 mm/kasan/report.c:188
      __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
      kasan_report+0xe/0x20 mm/kasan/common.c:614
      qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
      usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
      really_probe+0x281/0x660 drivers/base/dd.c:509
      driver_probe_device+0x104/0x210 drivers/base/dd.c:670
      __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
      bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
    
    Caused by too many confusing indirections and casts.
    id->driver_info is a pointer stored in a long.  We want the
    pointer here, not the address of it.
    
    Thanks-to: Hillf Danton <hdanton@sina.com>
    Reported-by: syzbot+b68605d7fadd21510de1@syzkaller.appspotmail.com
    Cc: Kristian Evensen <kristian.evensen@gmail.com>
    Fixes: e4bf63482c30 ("qmi_wwan: Add quirk for Quectel dynamic config")
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d1d924485133dca882e8fcebc9003acd7188724
Author: Sasha Levin <sashal@kernel.org>
Date:   Tue Jun 25 07:36:40 2019 -0400

    Revert "x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP"
    
    This reverts commit b65b70ba068b7cdbfeb65eee87cce84a74618603, which was
    upstream commit 4a6c91fbdef846ec7250b82f2eeeb87ac5f18cf9.
    
    On Tue, Jun 25, 2019 at 09:39:45AM +0200, Sebastian Andrzej Siewior wrote:
    >Please backport commit e74deb11931ff682b59d5b9d387f7115f689698e to
    >stable _or_ revert the backport of commit 4a6c91fbdef84 ("x86/uaccess,
    >ftrace: Fix ftrace_likely_update() vs. SMAP"). It uses
    >user_access_{save|restore}() which has been introduced in the following
    >commit.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 507ad93ad22b58d1690c65851f4b2b7dd9965ef8
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Jun 11 10:19:32 2019 -0700

    arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS
    
    commit fa63da2ab046b885a7f70291aafc4e8ce015429b upstream.
    
    This is a GCC only option, which warns about ABI changes within GCC, so
    unconditionally adding it breaks Clang with tons of:
    
    warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
    
    and link time failures:
    
    ld.lld: error: undefined symbol: __efistub___stack_chk_guard
    >>> referenced by arm-stub.c:73
    (/home/nathan/cbl/linux/drivers/firmware/efi/libstub/arm-stub.c:73)
    >>>               arm-stub.stub.o:(__efistub_install_memreserve_table)
    in archive ./drivers/firmware/efi/libstub/lib.a
    
    These failures come from the lack of -fno-stack-protector, which is
    added via cc-option in drivers/firmware/efi/libstub/Makefile. When an
    unknown flag is added to KBUILD_CFLAGS, clang will noisily warn that it
    is ignoring the option like above, unlike gcc, who will just error.
    
    $ echo "int main() { return 0; }" > tmp.c
    
    $ clang -Wno-psabi tmp.c; echo $?
    warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
    1 warning generated.
    0
    
    $ gcc -Wsometimes-uninitialized tmp.c; echo $?
    gcc: error: unrecognized command line option
    ‘-Wsometimes-uninitialized’; did you mean ‘-Wmaybe-uninitialized’?
    1
    
    For cc-option to work properly with clang and behave like gcc, -Werror
    is needed, which was done in commit c3f0d0bc5b01 ("kbuild, LLVMLinux:
    Add -Werror to cc-option to support clang").
    
    $ clang -Werror -Wno-psabi tmp.c; echo $?
    error: unknown warning option '-Wno-psabi'
    [-Werror,-Wunknown-warning-option]
    1
    
    As a consequence of this, when an unknown flag is unconditionally added
    to KBUILD_CFLAGS, it will cause cc-option to always fail and those flags
    will never get added:
    
    $ clang -Werror -Wno-psabi -fno-stack-protector tmp.c; echo $?
    error: unknown warning option '-Wno-psabi'
    [-Werror,-Wunknown-warning-option]
    1
    
    This can be seen when compiling the whole kernel as some warnings that
    are normally disabled (see below) show up. The full list of flags
    missing from drivers/firmware/efi/libstub are the following (gathered
    from diffing .arm64-stub.o.cmd):
    
    -fno-delete-null-pointer-checks
    -Wno-address-of-packed-member
    -Wframe-larger-than=2048
    -Wno-unused-const-variable
    -fno-strict-overflow
    -fno-merge-all-constants
    -fno-stack-check
    -Werror=date-time
    -Werror=incompatible-pointer-types
    -ffreestanding
    -fno-stack-protector
    
    Use cc-disable-warning so that it gets disabled for GCC and does nothing
    for Clang.
    
    Fixes: ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift")
    Link: https://github.com/ClangBuiltLinux/linux/issues/511
    Reported-by: Qian Cai <cai@lca.pw>
    Acked-by: Dave Martin <Dave.Martin@arm.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0fae702de30331a8ce913cdb87ac0bdf990d85f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 25 11:34:56 2019 +0800

    Linux 5.1.15

commit 1d7446deafa4111acbbeca0ac8ae7ac4340577fa
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Jun 12 23:35:07 2019 +1000

    powerpc/mm/64s/hash: Reallocate context ids on fork
    
    commit ca72d88378b2f2444d3ec145dd442d449d3fefbc upstream.
    
    When using the Hash Page Table (HPT) MMU, userspace memory mappings
    are managed at two levels. Firstly in the Linux page tables, much like
    other architectures, and secondly in the SLB (Segment Lookaside
    Buffer) and HPT. It's the SLB and HPT that are actually used by the
    hardware to do translations.
    
    As part of the series adding support for 4PB user virtual address
    space using the hash MMU, we added support for allocating multiple
    "context ids" per process, one for each 512TB chunk of address space.
    These are tracked in an array called extended_id in the mm_context_t
    of a process that has done a mapping above 512TB.
    
    If such a process forks (ie. clone(2) without CLONE_VM set) it's mm is
    copied, including the mm_context_t, and then init_new_context() is
    called to reinitialise parts of the mm_context_t as appropriate to
    separate the address spaces of the two processes.
    
    The key step in ensuring the two processes have separate address
    spaces is to allocate a new context id for the process, this is done
    at the beginning of hash__init_new_context(). If we didn't allocate a
    new context id then the two processes would share mappings as far as
    the SLB and HPT are concerned, even though their Linux page tables
    would be separate.
    
    For mappings above 512TB, which use the extended_id array, we
    neglected to allocate new context ids on fork, meaning the parent and
    child use the same ids and therefore share those mappings even though
    they're supposed to be separate. This can lead to the parent seeing
    writes done by the child, which is essentially memory corruption.
    
    There is an additional exposure which is that if the child process
    exits, all its context ids are freed, including the context ids that
    are still in use by the parent for mappings above 512TB. One or more
    of those ids can then be reallocated to a third process, that process
    can then read/write to the parent's mappings above 512TB. Additionally
    if the freed id is used for the third process's primary context id,
    then the parent is able to read/write to the third process's mappings
    *below* 512TB.
    
    All of these are fundamental failures to enforce separation between
    processes. The only mitigating factor is that the bug only occurs if a
    process creates mappings above 512TB, and most applications still do
    not create such mappings.
    
    Only machines using the hash page table MMU are affected, eg. PowerPC
    970 (G5), PA6T, Power5/6/7/8/9. By default Power9 bare metal machines
    (powernv) use the Radix MMU and are not affected, unless the machine
    has been explicitly booted in HPT mode (using disable_radix on the
    kernel command line). KVM guests on Power9 may be affected if the host
    or guest is configured to use the HPT MMU. LPARs under PowerVM on
    Power9 are affected as they always use the HPT MMU. Kernels built with
    PAGE_SIZE=4K are not affected.
    
    The fix is relatively simple, we need to reallocate context ids for
    all extended mappings on fork.
    
    Fixes: f384796c40dc ("powerpc/mm: Add support for handling > 512TB address in SLB miss")
    Cc: stable@vger.kernel.org # v4.17+
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0dcce78db667c7c1d37df0de077aad86fe84d54
Author: James Morse <james.morse@arm.com>
Date:   Mon Jun 3 18:25:31 2019 +0100

    x86/resctrl: Don't stop walking closids when a locksetup group is found
    
    commit 87d3aa28f345bea77c396855fa5d5fec4c24461f upstream.
    
    When a new control group is created __init_one_rdt_domain() walks all
    the other closids to calculate the sets of used and unused bits.
    
    If it discovers a pseudo_locksetup group, it breaks out of the loop.  This
    means any later closid doesn't get its used bits added to used_b.  These
    bits will then get set in unused_b, and added to the new control group's
    configuration, even if they were marked as exclusive for a later closid.
    
    When encountering a pseudo_locksetup group, we should continue. This is
    because "a resource group enters 'pseudo-locked' mode after the schemata is
    written while the resource group is in 'pseudo-locksetup' mode." When we
    find a pseudo_locksetup group, its configuration is expected to be
    overwritten, we can skip it.
    
    Fixes: dfe9674b04ff6 ("x86/intel_rdt: Enable entering of pseudo-locksetup mode")
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Reinette Chatre <reinette.chatre@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: H Peter Avin <hpa@zytor.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20190603172531.178830-1-james.morse@arm.com
    [Dropped comment due to lack of space]
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a6638862b1dc1b15b0069a70779f9c924697b7d
Author: Jouni Malinen <j@w1.fi>
Date:   Tue May 28 01:46:43 2019 +0300

    mac80211: Do not use stack memory with scatterlist for GMAC
    
    commit a71fd9dac23613d96ba3c05619a8ef4fd6cdf9b9 upstream.
    
    ieee80211_aes_gmac() uses the mic argument directly in sg_set_buf() and
    that does not allow use of stack memory (e.g., BUG_ON() is hit in
    sg_set_buf() with CONFIG_DEBUG_SG). BIP GMAC TX side is fine for this
    since it can use the skb data buffer, but the RX side was using a stack
    variable for deriving the local MIC value to compare against the
    received one.
    
    Fix this by allocating heap memory for the mic buffer.
    
    This was found with hwsim test case ap_cipher_bip_gmac_128 hitting that
    BUG_ON() and kernel panic.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34e22e35d487eb5024d5bf2ad046e99fbd35f55c
Author: Andy Strohman <andrew@andrewstrohman.com>
Date:   Fri May 24 23:27:29 2019 -0700

    nl80211: fix station_info pertid memory leak
    
    commit f77bf4863dc2218362f4227d56af4a5f3f08830c upstream.
    
    When dumping stations, memory allocated for station_info's
    pertid member will leak if the nl80211 header cannot be added to
    the sk_buff due to insufficient tail room.
    
    I noticed this leak in the kmalloc-2048 cache.
    
    Cc: stable@vger.kernel.org
    Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info")
    Signed-off-by: Andy Strohman <andy@uplevelsystems.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8caf5aae52f7a8e258eceae4f622841ee504bf5
Author: Yu Wang <yyuwang@codeaurora.org>
Date:   Fri May 10 17:04:52 2019 +0800

    mac80211: handle deauthentication/disassociation from TDLS peer
    
    commit 79c92ca42b5a3e0ea172ea2ce8df8e125af237da upstream.
    
    When receiving a deauthentication/disassociation frame from a TDLS
    peer, a station should not disconnect the current AP, but only
    disable the current TDLS link if it's enabled.
    
    Without this change, a TDLS issue can be reproduced by following the
    steps as below:
    
    1. STA-1 and STA-2 are connected to AP, bidirection traffic is running
       between STA-1 and STA-2.
    2. Set up TDLS link between STA-1 and STA-2, stay for a while, then
       teardown TDLS link.
    3. Repeat step #2 and monitor the connection between STA and AP.
    
    During the test, one STA may send a deauthentication/disassociation
    frame to another, after TDLS teardown, with reason code 6/7, which
    means: Class 2/3 frame received from nonassociated STA.
    
    On receive this frame, the receiver STA will disconnect the current
    AP and then reconnect. It's not a expected behavior, purpose of this
    frame should be disabling the TDLS link, not the link with AP.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Yu Wang <yyuwang@codeaurora.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0dd7d335f896e2f8d6b154fa2c07c6b9b5ccd00d
Author: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Date:   Wed May 8 14:55:33 2019 +0530

    {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
    
    commit 33d915d9e8ce811d8958915ccd18d71a66c7c495 upstream.
    
    As per the current design, in the case of sw crypto controlled devices,
    it is the device which advertises the support for AP/VLAN iftype based
    on it's ability to tranmsit packets encrypted in software
    (In VLAN functionality, group traffic generated for a specific
    VLAN group is always encrypted in software). Commit db3bdcb9c3ff
    ("mac80211: allow AP_VLAN operation on crypto controlled devices")
    has introduced this change.
    
    Since 4addr AP operation also uses AP/VLAN iftype, this conditional
    way of advertising AP/VLAN support has broken 4addr AP mode operation on
    crypto controlled devices which do not support VLAN functionality.
    
    In the case of ath10k driver, not all firmwares have support for VLAN
    functionality but all can support 4addr AP operation. Because AP/VLAN
    support is not advertised for these devices, 4addr AP operations are
    also blocked.
    
    Fix this by allowing 4addr operation on devices which do not support
    AP/VLAN iftype but can support 4addr AP operation (decision is based on
    the wiphy flag WIPHY_FLAG_4ADDR_AP).
    
    Cc: stable@vger.kernel.org
    Fixes: db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices")
    Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61113ed908d86ad06319a9c774800cfa3f6f8766
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Feb 13 15:13:30 2019 +0100

    mac80211: drop robust management frames from unknown TA
    
    commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream.
    
    When receiving a robust management frame, drop it if we don't have
    rx->sta since then we don't have a security association and thus
    couldn't possibly validate the frame.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a6d3e2fcada25b61745c71afb09c35383ef0b3f
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Jun 10 13:02:19 2019 -0700

    cfg80211: fix memory leak of wiphy device name
    
    commit 4f488fbca2a86cc7714a128952eead92cac279ab upstream.
    
    In wiphy_new_nm(), if an error occurs after dev_set_name() and
    device_initialize() have already been called, it's necessary to call
    put_device() (via wiphy_free()) to avoid a memory leak.
    
    Reported-by: syzbot+7fddca22578bc67c3fe4@syzkaller.appspotmail.com
    Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bb1bedcf3479b05567513ee21734524b838d794
Author: Christian Brauner <christian@brauner.io>
Date:   Mon Jun 17 23:22:14 2019 +0200

    fs/namespace: fix unprivileged mount propagation
    
    commit d728cf79164bb38e9628d15276e636539f857ef1 upstream.
    
    When propagating mounts across mount namespaces owned by different user
    namespaces it is not possible anymore to move or umount the mount in the
    less privileged mount namespace.
    
    Here is a reproducer:
    
      sudo mount -t tmpfs tmpfs /mnt
      sudo --make-rshared /mnt
    
      # create unprivileged user + mount namespace and preserve propagation
      unshare -U -m --map-root --propagation=unchanged
    
      # now change back to the original mount namespace in another terminal:
      sudo mkdir /mnt/aaa
      sudo mount -t tmpfs tmpfs /mnt/aaa
    
      # now in the unprivileged user + mount namespace
      mount --move /mnt/aaa /opt
    
    Unfortunately, this is a pretty big deal for userspace since this is
    e.g. used to inject mounts into running unprivileged containers.
    So this regression really needs to go away rather quickly.
    
    The problem is that a recent change falsely locked the root of the newly
    added mounts by setting MNT_LOCKED. Fix this by only locking the mounts
    on copy_mnt_ns() and not when adding a new mount.
    
    Fixes: 3bd045cc9c4b ("separate copying and locking mount tree on cross-userns copies")
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: <stable@vger.kernel.org>
    Tested-by: Christian Brauner <christian@brauner.io>
    Acked-by: Christian Brauner <christian@brauner.io>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Christian Brauner <christian@brauner.io>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf37b1a0902944f17ac95eb62177219b65c413cb
Author: Andy Lutomirski <luto@kernel.org>
Date:   Fri Jun 21 08:43:04 2019 -0700

    x86/vdso: Prevent segfaults due to hoisted vclock reads
    
    commit ff17bbe0bb405ad8b36e55815d381841f9fdeebc upstream.
    
    GCC 5.5.0 sometimes cleverly hoists reads of the pvclock and/or hvclock
    pages before the vclock mode checks.  This creates a path through
    vclock_gettime() in which no vclock is enabled at all (due to disabled
    TSC on old CPUs, for example) but the pvclock or hvclock page
    nevertheless read.  This will segfault on bare metal.
    
    This fixes commit 459e3a21535a ("gcc-9: properly declare the
    {pv,hv}clock_page storage") in the sense that, before that commit, GCC
    didn't seem to generate the offending code.  There was nothing wrong
    with that commit per se, and -stable maintainers should backport this to
    all supported kernels regardless of whether the offending commit was
    present, since the same crash could just as easily be triggered by the
    phase of the moon.
    
    On GCC 9.1.1, this doesn't seem to affect the generated code at all, so
    I'm not too concerned about performance regressions from this fix.
    
    Cc: stable@vger.kernel.org
    Cc: x86@kernel.org
    Cc: Borislav Petkov <bp@alien8.de>
    Reported-by: Duncan Roe <duncan_roe@optusnet.com.au>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df2d313511bdb39ac6b11bc61ea65feba8acac05
Author: Steve French <stfrench@microsoft.com>
Date:   Mon Jun 17 14:49:07 2019 -0500

    SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write
    
    commit 8d526d62db907e786fd88948c75d1833d82bd80e upstream.
    
    Some servers such as Windows 10 will return STATUS_INSUFFICIENT_RESOURCES
    as the number of simultaneous SMB3 requests grows (even though the client
    has sufficient credits).  Return EAGAIN on STATUS_INSUFFICIENT_RESOURCES
    so that we can retry writes which fail with this status code.
    
    This (for example) fixes large file copies to Windows 10 on fast networks.
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit caf37f6d6a29827acae2ae415645e96dff5c25f1
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Sat Jun 22 15:47:01 2019 +0200

    Bluetooth: Fix regression with minimum encryption key size alignment
    
    commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream.
    
    When trying to align the minimum encryption key size requirement for
    Bluetooth connections, it turns out doing this in a central location in
    the HCI connection handling code is not possible.
    
    Original Bluetooth version up to 2.0 used a security model where the
    L2CAP service would enforce authentication and encryption.  Starting
    with Bluetooth 2.1 and Secure Simple Pairing that model has changed into
    that the connection initiator is responsible for providing an encrypted
    ACL link before any L2CAP communication can happen.
    
    Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and
    before devices are causing a regression.  The encryption key size check
    needs to be moved out of the HCI connection handling into the L2CAP
    channel setup.
    
    To achieve this, the current check inside hci_conn_security() has been
    moved into l2cap_check_enc_key_size() helper function and then called
    from four decisions point inside L2CAP to cover all combinations of
    Secure Simple Pairing enabled devices and device using legacy pairing
    and legacy service security model.
    
    Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 640a7f2a52610efbfdffcb4a8b165da954e86a3c
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Wed Apr 24 22:19:17 2019 +0200

    Bluetooth: Align minimum encryption key size for LE and BR/EDR connections
    
    commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
    
    The minimum encryption key size for LE connections is 56 bits and to
    align LE with BR/EDR, enforce 56 bits of minimum encryption key size for
    BR/EDR connections as well.
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d327913b274d2866a94fed817d01592ea66a269
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Thu Jun 13 16:35:41 2019 +0800

    staging: erofs: add requirements field in superblock
    
    commit 5efe5137f05bbb4688890620934538c005e7d1d6 upstream.
    
    There are some backward incompatible features pending
    for months, mainly due to on-disk format expensions.
    
    However, we should ensure that it cannot be mounted with
    old kernels. Otherwise, it will causes unexpected behaviors.
    
    Fixes: ba2b77a82022 ("staging: erofs: add super block operations")
    Cc: <stable@vger.kernel.org> # 4.19+
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e3b977a8f1be01dcfa0baae68851b1f55f2a0a9
Author: Todd Kjos <tkjos@android.com>
Date:   Wed Jun 12 13:29:27 2019 -0700

    binder: fix possible UAF when freeing buffer
    
    commit a370003cc301d4361bae20c9ef615f89bf8d1e8a upstream.
    
    There is a race between the binder driver cleaning
    up a completed transaction via binder_free_transaction()
    and a user calling binder_ioctl(BC_FREE_BUFFER) to
    release a buffer. It doesn't matter which is first but
    they need to be protected against running concurrently
    which can result in a UAF.
    
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91a7616a65da342d57b1c3fbef45d3a352158032
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Jun 19 15:09:29 2019 +0300

    drm/i915: Don't clobber M/N values during fastset check
    
    commit 475df5d0f3eb2d031e4505f84d8fba75baaf2e80 upstream.
    
    We're now calling intel_pipe_config_compare(..., true) uncoditionally
    which means we're always going clobber the calculated M/N values with
    the old values if the fuzzy M/N check passes. That causes problems
    because the fuzzy check allows for a huge difference in the values.
    
    I'm actually tempted to just make the M/N checks exact, but that might
    prevent fastboot from kicking in when people want it. So for now let's
    overwrite the computed values with the old values only if decide to skip
    the modeset.
    
    v2: Copy has_drrs along with M/N M2/N2 values
    
    Cc: stable@vger.kernel.org
    Cc: Blubberbub@protonmail.com
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Blubberbub@protonmail.com
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110782
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110675
    Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190612172423.25231-1-ville.syrjala@linux.intel.com
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    (cherry picked from commit f0521558a2a89d58a08745e225025d338572e60a)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190619120929.4057-1-ville.syrjala@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f7779fc33da24b592f4e10d54e936dea965de46
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Wed May 29 08:15:19 2019 +0200

    drm/vmwgfx: Use the backdoor port if the HB port is not available
    
    commit cc0ba0d8624f210995924bb57a8b181ce8976606 upstream.
    
    The HB port may not be available for various reasons. Either it has been
    disabled by a config option or by the hypervisor for other reasons.
    In that case, make sure we have a backup plan and use the backdoor port
    instead with a performance penalty.
    
    Cc: stable@vger.kernel.org
    Fixes: 89da76fde68d ("drm/vmwgfx: Add VMWare host messaging capability")
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Deepak Rawat <drawat@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e10e064bf6c263d760fcc8f842e89bb1bd3cdf89
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sun Jun 9 19:03:44 2019 +0300

    ovl: make i_ino consistent with st_ino in more cases
    
    commit 6dde1e42f497b2d4e22466f23019016775607947 upstream.
    
    Relax the condition that overlayfs supports nfs export, to require
    that i_ino is consistent with st_ino/d_ino.
    
    It is enough to require that st_ino and d_ino are consistent.
    
    This fixes the failure of xfstest generic/504, due to mismatch of
    st_ino to inode number in the output of /proc/locks.
    
    Fixes: 12574a9f4c9c ("ovl: consistent i_ino for non-samefs with xino")
    Cc: <stable@vger.kernel.org> # v4.19
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 480776dd3cb5fb97d01d154c85ddacf332176dbe
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Jun 13 10:22:23 2019 -0700

    KVM: x86/mmu: Allocate PAE root array when using SVM's 32-bit NPT
    
    commit b6b80c78af838bef17501416d5d383fedab0010a upstream.
    
    SVM's Nested Page Tables (NPT) reuses x86 paging for the host-controlled
    page walk.  For 32-bit KVM, this means PAE paging is used even when TDP
    is enabled, i.e. the PAE root array needs to be allocated.
    
    Fixes: ee6268ba3a68 ("KVM: x86: Skip pae_root shadow allocation if tdp enabled")
    Cc: stable@vger.kernel.org
    Reported-by: Jiri Palecek <jpalecek@web.de>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba867ef4081c6ad19b65d3c7b3ccf8387e4c1b36
Author: Anisse Astier <aastier@freebox.fr>
Date:   Mon Jun 17 15:22:21 2019 +0200

    arm64: ssbd: explicitly depend on <linux/prctl.h>
    
    commit adeaa21a4b6954e878f3f7d1c5659ed9c1fe567a upstream.
    
    Fix ssbd.c which depends implicitly on asm/ptrace.h including
    linux/prctl.h (through for example linux/compat.h, then linux/time.h,
    linux/seqlock.h, linux/spinlock.h and linux/irqflags.h), and uses
    PR_SPEC* defines.
    
    This is an issue since we'll soon be removing the include from
    asm/ptrace.h.
    
    Fixes: 9cdc0108baa8 ("arm64: ssbd: Add prctl interface for per-thread mitigation")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anisse Astier <aastier@freebox.fr>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea352712b0738205d8220ec2fc705b192a59a3ee
Author: Anisse Astier <aastier@freebox.fr>
Date:   Mon Jun 17 15:22:22 2019 +0200

    arm64/sve: <uapi/asm/ptrace.h> should not depend on <uapi/linux/prctl.h>
    
    commit 35341ca0614ab13e1ef34ad4f29a39e15ef31fa8 upstream.
    
    Pulling linux/prctl.h into asm/ptrace.h in the arm64 UAPI headers causes
    userspace build issues for any program (e.g. strace and qemu) that
    includes both <sys/prctl.h> and <linux/ptrace.h> when using musl libc:
    
      | error: redefinition of 'struct prctl_mm_map'
      |  struct prctl_mm_map {
    
    See https://github.com/foundriesio/meta-lmp/commit/6d4a106e191b5d79c41b9ac78fd321316d3013c0
    for a public example of people working around this issue.
    
    Although it's a bit grotty, fix this breakage by duplicating the prctl
    constant definitions. Since these are part of the kernel ABI, they
    cannot be changed in future and so it's not the end of the world to have
    them open-coded.
    
    Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support")
    Cc: stable@vger.kernel.org
    Acked-by: Dave Martin <Dave.Martin@arm.com>
    Signed-off-by: Anisse Astier <aastier@freebox.fr>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e56759725d6e9b641296bcd8deead47d572a162e
Author: Faiz Abbas <faiz_abbas@ti.com>
Date:   Thu May 2 14:17:48 2019 +0530

    ARM: dts: am57xx-idk: Remove support for voltage switching for SD card
    
    commit 88a748419b84187fd1da05637b8e5928b04a1e06 upstream.
    
    If UHS speed modes are enabled, a compatible SD card switches down to
    1.8V during enumeration. If after this a software reboot/crash takes
    place and on-chip ROM tries to enumerate the SD card, the difference in
    IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card.
    
    The fix for this is to have support for power cycling the card in
    hardware (with a PORz/soft-reset line causing a power cycle of the
    card). Since am571x-, am572x- and am574x-idk don't have this
    capability, disable voltage switching for these boards.
    
    The major effect of this is that the maximum supported speed
    mode is now high speed(50 MHz) down from SDR104(200 MHz).
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cf95590ecee866791172ff4cb273eb6a8e96b34
Author: Faiz Abbas <faiz_abbas@ti.com>
Date:   Tue Apr 30 11:38:56 2019 +0530

    ARM: dts: dra76x: Update MMC2_HS200_MANUAL1 iodelay values
    
    commit c3c0b70cd3f801bded7a548198ee1c9851a0ca82 upstream.
    
    Update the MMC2_HS200_MANUAL1 iodelay values to match with the latest
    dra76x data manual[1]. The new iodelay values will have better marginality
    and should prevent issues in corner cases.
    
    Also this particular pinctrl-array is using spaces instead of tabs for
    spacing between the values and the comments. Fix this as well.
    
    [1] http://www.ti.com/lit/ds/symlink/dra76p.pdf
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
    [tony@atomide.com: updated description with a bit more info]
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 092686925bf5026e2d517aa5593ca9a2a313af6f
Author: Jan Kundrát <jan.kundrat@cesnet.cz>
Date:   Fri May 17 17:01:42 2019 +0200

    ARM: mvebu_v7_defconfig: fix Ethernet on Clearfog
    
    commit cc538ca4308372e81b824be08561c466b1d73b72 upstream.
    
    Compared to kernel 5.0, patches merged for 5.1 added support for A38x'
    PHY guarded by a config option which was not enabled by default. As a
    result, there was no eth1 and eth2 on a Solid Run Clearfog Base.
    
    Ensure that A38x PHY is enabled on mvebu.
    
    [gregory: issue appeared in 5.1 not in 5.2 and added Fixes tag]
    
    Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Cc: Baruch Siach <baruch@tkos.co.il>
    Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
    Cc: Russell King <rmk+kernel@armlinux.org.uk>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Fixes: a10c1c8191e0 ("net: marvell: neta: add comphy support")
    Cc: stable@kernel.org
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84d2456e0c0cadb7843339f61eeabb005401f328
Author: Fabio Estevam <festevam@gmail.com>
Date:   Mon May 13 00:15:31 2019 -0300

    ARM: imx: cpuidle-imx6sx: Restrict the SW2ISO increase to i.MX6SX
    
    commit b25af2ff7c07bd19af74e3f64ff82e2880d13d81 upstream.
    
    Since commit 1e434b703248 ("ARM: imx: update the cpu power up timing
    setting on i.mx6sx") some characters loss is noticed on i.MX6ULL UART
    as reported by Christoph Niedermaier.
    
    The intention of such commit was to increase the SW2ISO field for i.MX6SX
    only, but since cpuidle-imx6sx is also used on i.MX6UL/i.MX6ULL this caused
    unintended side effects on other SoCs.
    
    Fix this problem by keeping the original SW2ISO value for i.MX6UL/i.MX6ULL
    and only increase SW2ISO in the i.MX6SX case.
    
    Cc: stable@vger.kernel.org
    Fixes: 1e434b703248 ("ARM: imx: update the cpu power up timing setting on i.mx6sx")
    Reported-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Tested-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
    Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0d9022a587742f0ea91f683b1b3737748fd7c3d
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Jun 13 00:21:40 2019 +0530

    powerpc/bpf: use unsigned division instruction for 64-bit operations
    
    commit 758f2046ea040773ae8ea7f72dd3bbd8fa984501 upstream.
    
    BPF_ALU64 div/mod operations are currently using signed division, unlike
    BPF_ALU32 operations. Fix the same. DIV64 and MOD64 overflow tests pass
    with this fix.
    
    Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
    Cc: stable@vger.kernel.org # v4.8+
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1243385929aec703ff57ad0bc1eed3fead3a351d
Author: ShihPo Hung <shihpo.hung@sifive.com>
Date:   Mon Jun 17 12:26:17 2019 +0800

    riscv: mm: synchronize MMU after pte change
    
    commit bf587caae305ae3b4393077fb22c98478ee55755 upstream.
    
    Because RISC-V compliant implementations can cache invalid entries
    in TLB, an SFENCE.VMA is necessary after changes to the page table.
    This patch adds an SFENCE.vma for the vmalloc_fault path.
    
    Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com>
    [paul.walmsley@sifive.com: reversed tab->whitespace conversion,
     wrapped comment lines]
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Palmer Dabbelt <palmer@sifive.com>
    Cc: Albert Ou <aou@eecs.berkeley.edu>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: linux-riscv@lists.infradead.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3688ea1f176b148149460a8f7321ecd764cda4ae
Author: Willem de Bruijn <willemb@google.com>
Date:   Fri Jun 7 16:46:07 2019 -0400

    can: purge socket error queue on sock destruct
    
    commit fd704bd5ee749d560e86c4f1fd2ef486d8abf7cf upstream.
    
    CAN supports software tx timestamps as of the below commit. Purge
    any queued timestamp packets on socket destroy.
    
    Fixes: 51f31cabe3ce ("ip: support for TX timestamps on UDP and RAW sockets")
    Reported-by: syzbot+a90604060cb40f5bdd16@syzkaller.appspotmail.com
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d4258f850f6eb3f5ed8b18b36827680d669c81c
Author: Joakim Zhang <qiangqing.zhang@nxp.com>
Date:   Thu Jan 31 09:37:22 2019 +0000

    can: flexcan: fix timeout when set small bitrate
    
    commit 247e5356a709eb49a0d95ff2a7f07dac05c8252c upstream.
    
    Current we can meet timeout issue when setting a small bitrate like
    10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock =
    30MHZ):
    
    | root@imx6ul7d:~# ip link set can0 up type can bitrate 10000
    
    A link change request failed with some changes committed already.
    Interface can0 may have been left with an inconsistent configuration,
    please check.
    
    | RTNETLINK answers: Connection timed out
    
    It is caused by calling of flexcan_chip_unfreeze() timeout.
    
    Originally the code is using usleep_range(10, 20) for unfreeze
    operation, but the patch (8badd65 can: flexcan: avoid calling
    usleep_range from interrupt context) changed it into udelay(10) which is
    only a half delay of before, there're also some other delay changes.
    
    After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
    
    Meanwhile, Rasmus Villemoes reported that even with a timeout of 100,
    flexcan_probe() fails on the MPC8309, which requires a value of at least
    140 to work reliably. 250 works for everyone.
    
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e2e23c33be8015ac2a8bfdece183588e92dcbf2
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Tue Sep 11 14:47:46 2018 +0300

    can: xilinx_can: use correct bittiming_const for CAN FD core
    
    commit 904044dd8fff43e289c11a2f90fa532e946a1d8b upstream.
    
    Commit 9e5f1b273e6a ("can: xilinx_can: add support for Xilinx CAN FD
    core") added a new can_bittiming_const structure for CAN FD cores that
    support larger values for tseg1, tseg2, and sjw than previous Xilinx CAN
    cores, but the commit did not actually take that into use.
    
    Fix that.
    
    Tested with CAN FD core on a ZynqMP board.
    
    Fixes: 9e5f1b273e6a ("can: xilinx_can: add support for Xilinx CAN FD core")
    Reported-by: Shubhrajyoti Datta <shubhrajyoti.datta@gmail.com>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@gmail.com>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e15e6f7922c695fb6e9387a18e5bd8cb7d6c02a
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Thu Jun 6 16:54:44 2019 +0900

    btrfs: start readahead also in seed devices
    
    commit c4e0540d0ad49c8ceab06cceed1de27c4fe29f6e upstream.
    
    Currently, btrfs does not consult seed devices to start readahead. As a
    result, if readahead zone is added to the seed devices, btrfs_reada_wait()
    indefinitely wait for the reada_ctl to finish.
    
    You can reproduce the hung by modifying btrfs/163 to have larger initial
    file size (e.g. xfs_io pwrite 4M instead of current 256K).
    
    Fixes: 7414a03fbf9e ("btrfs: initial readahead code and prototypes")
    Cc: stable@vger.kernel.org # 3.2+: ce7791ffee1e: Btrfs: fix race between readahead and device replace/removal
    Cc: stable@vger.kernel.org # 3.2+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b8bd98e23a92b4fa6b1f3dd9e381c47ce575642
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jun 17 14:39:29 2019 +0200

    ovl: fix bogus -Wmaybe-unitialized warning
    
    [ Upstream commit 1dac6f5b0ed2601be21bb4e27a44b0c3e667b7f4 ]
    
    gcc gets a bit confused by the logic in ovl_setup_trap() and
    can't figure out whether the local 'trap' variable in the caller
    was initialized or not:
    
    fs/overlayfs/super.c: In function 'ovl_fill_super':
    fs/overlayfs/super.c:1333:4: error: 'trap' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        iput(trap);
        ^~~~~~~~~~
    fs/overlayfs/super.c:1312:17: note: 'trap' was declared here
    
    Reword slightly to make it easier for the compiler to understand.
    
    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 168835bbb0bff4c6294b7040e006251f105f7599
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Jun 18 15:06:16 2019 +0200

    ovl: don't fail with disconnected lower NFS
    
    [ Upstream commit 9179c21dc6ed1c993caa5fe4da876a6765c26af7 ]
    
    NFS mounts can be disconnected from fs root.  Don't fail the overlapping
    layer check because of this.
    
    The check is not authoritative anyway, since topology can change during or
    after the check.
    
    Reported-by: Antti Antinoja <antti@fennosys.fi>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99eb836cd9a4df455ae90807bc00ee635be342f0
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Thu Apr 18 17:42:08 2019 +0300

    ovl: detect overlapping layers
    
    [ Upstream commit 146d62e5a5867fbf84490d82455718bfb10fe824 ]
    
    Overlapping overlay layers are not supported and can cause unexpected
    behavior, but overlayfs does not currently check or warn about these
    configurations.
    
    User is not supposed to specify the same directory for upper and
    lower dirs or for different lower layers and user is not supposed to
    specify directories that are descendants of each other for overlay
    layers, but that is exactly what this zysbot repro did:
    
        https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f400000
    
    Moving layer root directories into other layers while overlayfs
    is mounted could also result in unexpected behavior.
    
    This commit places "traps" in the overlay inode hash table.
    Those traps are dummy overlay inodes that are hashed by the layers
    root inodes.
    
    On mount, the hash table trap entries are used to verify that overlay
    layers are not overlapping.  While at it, we also verify that overlay
    layers are not overlapping with directories "in-use" by other overlay
    instances as upperdir/workdir.
    
    On lookup, the trap entries are used to verify that overlay layers
    root inodes have not been moved into other layers after mount.
    
    Some examples:
    
    $ ./run --ov --samefs -s
    ...
    ( mkdir -p base/upper/0/u base/upper/0/w base/lower lower upper mnt
      mount -o bind base/lower lower
      mount -o bind base/upper upper
      mount -t overlay none mnt ...
            -o lowerdir=lower,upperdir=upper/0/u,workdir=upper/0/w)
    
    $ umount mnt
    $ mount -t overlay none mnt ...
            -o lowerdir=base,upperdir=upper/0/u,workdir=upper/0/w
    
      [   94.434900] overlayfs: overlapping upperdir path
      mount: mount overlay on mnt failed: Too many levels of symbolic links
    
    $ mount -t overlay none mnt ...
            -o lowerdir=upper/0/u,upperdir=upper/0/u,workdir=upper/0/w
    
      [  151.350132] overlayfs: conflicting lowerdir path
      mount: none is already mounted or mnt busy
    
    $ mount -t overlay none mnt ...
            -o lowerdir=lower:lower/a,upperdir=upper/0/u,workdir=upper/0/w
    
      [  201.205045] overlayfs: overlapping lowerdir path
      mount: mount overlay on mnt failed: Too many levels of symbolic links
    
    $ mount -t overlay none mnt ...
            -o lowerdir=lower,upperdir=upper/0/u,workdir=upper/0/w
    $ mv base/upper/0/ base/lower/
    $ find mnt/0
      mnt/0
      mnt/0/w
      find: 'mnt/0/w/work': Too many levels of symbolic links
      find: 'mnt/0/u': Too many levels of symbolic links
    
    Reported-by: syzbot+9c69c282adc4edd2b540@syzkaller.appspotmail.com
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac4ff52d177195e7e8baff20164e8c3449b11372
Author: Jaesoo Lee <jalee@purestorage.com>
Date:   Mon Jun 3 16:42:28 2019 -0700

    nvme: Fix u32 overflow in the number of namespace list calculation
    
    [ Upstream commit c8e8c77b3bdbade6e26e8e76595f141ede12b692 ]
    
    The Number of Namespaces (nn) field in the identify controller data structure is
    defined as u32 and the maximum allowed value in NVMe specification is
    0xFFFFFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP()
    operation used in nvme_scan_ns_list() by casting the nn to u64.
    
    Signed-off-by: Jaesoo Lee <jalee@purestorage.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae4e62064756dba432c3691360ba80bba7a1191e
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Thu Jun 6 11:33:43 2019 +0100

    arm64: Silence gcc warnings about arch ABI drift
    
    [ Upstream commit ebcc5928c5d925b1c8d968d9c89cdb0d0186db17 ]
    
    Since GCC 9, the compiler warns about evolution of the
    platform-specific ABI, in particular relating for the marshaling of
    certain structures involving bitfields.
    
    The kernel is a standalone binary, and of course nobody would be
    so stupid as to expose structs containing bitfields as function
    arguments in ABI.  (Passing a pointer to such a struct, however
    inadvisable, should be unaffected by this change.  perf and various
    drivers rely on that.)
    
    So these warnings do more harm than good: turn them off.
    
    We may miss warnings about future ABI drift, but that's too bad.
    Future ABI breaks of this class will have to be debugged and fixed
    the traditional way unless the compiler evolves finer-grained
    diagnostics.
    
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4cfd8b68135572f0ac45e2e12eaea07bbefe6155
Author: Robert Hancock <hancock@sedsystems.ca>
Date:   Wed Jun 5 13:49:00 2019 -0600

    hwmon: (pmbus/core) Treat parameters as paged if on multiple pages
    
    [ Upstream commit 4a60570dce658e3f8885bbcf852430b99f65aca5 ]
    
    Some chips have attributes which exist on more than one page but the
    attribute is not presently marked as paged. This causes the attributes
    to be generated with the same label, which makes it impossible for
    userspace to tell them apart.
    
    Marking all such attributes as paged would result in the page suffix
    being added regardless of whether they were present on more than one
    page or not, which might break existing setups. Therefore, we add a
    second check which treats the attribute as paged, even if not marked as
    such, if it is present on multiple pages.
    
    Fixes: b4ce237b7f7d ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers")
    Signed-off-by: Robert Hancock <hancock@sedsystems.ca>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e15a3690c332bc73d60ffedf52811fa5d03c8d13
Author: Eduardo Valentin <eduval@amazon.com>
Date:   Wed May 29 19:56:04 2019 -0700

    hwmon: (core) add thermal sensors only if dev->of_node is present
    
    [ Upstream commit c41dd48e21fae3e55b3670ccf2eb562fc1f6a67d ]
    
    Drivers may register to hwmon and request for also registering
    with the thermal subsystem (HWMON_C_REGISTER_TZ). However,
    some of these driver, e.g. marvell phy, may be probed from
    Device Tree or being dynamically allocated, and in the later
    case, it will not have a dev->of_node entry.
    
    Registering with hwmon without the dev->of_node may result in
    different outcomes depending on the device tree, which may
    be a bit misleading. If the device tree blob has no 'thermal-zones'
    node, the *hwmon_device_register*() family functions are going
    to gracefully succeed, because of-thermal,
    *thermal_zone_of_sensor_register() return -ENODEV in this case,
    and the hwmon error path handles this error code as success to
    cover for the case where CONFIG_THERMAL_OF is not set.
    However, if the device tree blob has the 'thermal-zones'
    entry, the *hwmon_device_register*() will always fail on callers
    with no dev->of_node, propagating -EINVAL.
    
    If dev->of_node is not present, calling of-thermal does not
    make sense. For this reason, this patch checks first if the
    device has a of_node before going over the process of registering
    with the thermal subsystem of-thermal interface. And in this case,
    when a caller of *hwmon_device_register*() with HWMON_C_REGISTER_TZ
    and no dev->of_node will still register with hwmon, but not with
    the thermal subsystem. If all the hwmon part bits are in place,
    the registration will succeed.
    
    Fixes: d560168b5d0f ("hwmon: (core) New hwmon registration API")
    Cc: Jean Delvare <jdelvare@suse.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: linux-hwmon@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Eduardo Valentin <eduval@amazon.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62ba45885be16f1e5f3fd909086640a1fb4f7e01
Author: Alexandra Winter <wintera@linux.ibm.com>
Date:   Wed Jun 5 13:48:50 2019 +0200

    s390/qeth: fix VLAN attribute in bridge_hostnotify udev event
    
    [ Upstream commit 335726195e460cb6b3f795b695bfd31f0ea70ef0 ]
    
    Enabling sysfs attribute bridge_hostnotify triggers a series of udev events
    for the MAC addresses of all currently connected peers. In case no VLAN is
    set for a peer, the device reports the corresponding MAC addresses with
    VLAN ID 4096. This currently results in attribute VLAN=4096 for all
    non-VLAN interfaces in the initial series of events after host-notify is
    enabled.
    
    Instead, no VLAN attribute should be reported in the udev event for
    non-VLAN interfaces.
    
    Only the initial events face this issue. For dynamic changes that are
    reported later, the device uses a validity flag.
    
    This also changes the code so that it now sets the VLAN attribute for
    MAC addresses with VID 0. On Linux, no qeth interface will ever be
    registered with VID 0: Linux kernel registers VID 0 on all network
    interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0.
    Peers with other OSs could register MACs with VID 0.
    
    Fixes: 9f48b9db9a22 ("qeth: bridgeport support - address notifications")
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4c17bff212972577d13a302e713c9cbf9869509
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Wed Jun 5 13:48:49 2019 +0200

    s390/qeth: check dst entry before use
    
    [ Upstream commit 0cd6783d3c7d40be165d1f3c811cedf0e3dfcdf1 ]
    
    While qeth_l3 uses netif_keep_dst() to hold onto the dst, a skb's dst
    may still have been obsoleted (via dst_dev_put()) by the time that we
    end up using it. The dst then points to the loopback interface, which
    means the neighbour lookup in qeth_l3_get_cast_type() determines a bogus
    cast type of RTN_BROADCAST.
    For IQD interfaces this causes us to place such skbs on the wrong
    HW queue, resulting in TX errors.
    
    Fix-up the various call sites to first validate the dst entry with
    dst_check(), and fall back accordingly.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9dfa6fba5ae1c984c71367d63788606b88c05c7
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Wed Jun 5 13:48:48 2019 +0200

    s390/qeth: handle limited IPv4 broadcast in L3 TX path
    
    [ Upstream commit 72c87976c5abbf8a834ad85f10d03c0cd58b985c ]
    
    When selecting the cast type of a neighbourless IPv4 skb (eg. on a raw
    socket), qeth_l3 falls back to the packet's destination IP address.
    For this case we should classify traffic sent to 255.255.255.255 as
    broadcast.
    This fixes DHCP requests, which were misclassified as unicast
    (and for IQD interfaces thus ended up on the wrong HW queue).
    
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6accdd40a49d3715497336afd8e71ad3b14eee5
Author: Christian Brauner <christian@brauner.io>
Date:   Wed Jun 5 15:06:32 2019 +0200

    tests: fix pidfd-test compilation
    
    [ Upstream commit 1fcd0eb356ad56c4e405f06e31dd9fde2109d5ab ]
    
    Define __NR_pidfd_send_signal if it isn't to prevent a potential
    compilation error.
    
    To make pidfd-test compile on all arches, irrespective of whether
    or not syscall numbers are assigned, define the syscall number to -1.
    If it isn't defined this will cause the kernel to return -ENOSYS.
    
    Fixes: 575a0ae9744d ("selftests: add tests for pidfd_send_signal()")
    Signed-off-by: Christian Brauner <christian@brauner.io>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fe18137a3575d9e46c7fd6d4f435c5eae5d89d7
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Tue Jun 4 22:23:31 2019 +0200

    udmabuf: actually unmap the scatterlist
    
    [ Upstream commit 283f1e383e91d96fe652fad549537ae15cf31d60 ]
    
    unmap_udmabuf fails to actually unmap the scatterlist, leaving dangling
    mappings around.
    
    Fixes: fbb0de795078 ("Add udmabuf misc device")
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Link: http://patchwork.freedesktop.org/patch/msgid/20190604202331.17482-1-l.stach@pengutronix.de
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08f02cc91dfae4670c3163d31f8b24e318f1f72e
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Tue Jun 4 06:07:34 2019 +0000

    net: ipvlan: Fix ipvlan device tso disabled while NETIF_F_IP_CSUM is set
    
    [ Upstream commit ceae266bf0ae6564ac16d086bf749a096fa90ded ]
    
    There's some NICs, such as hinic, with NETIF_F_IP_CSUM and NETIF_F_TSO
    on but NETIF_F_HW_CSUM off. And ipvlan device features will be
    NETIF_F_TSO on with NETIF_F_IP_CSUM and NETIF_F_IP_CSUM both off as
    IPVLAN_FEATURES only care about NETIF_F_HW_CSUM. So TSO will be
    disabled in netdev_fix_features.
    For example:
    Features for enp129s0f0:
    rx-checksumming: on
    tx-checksumming: on
            tx-checksum-ipv4: on
            tx-checksum-ip-generic: off [fixed]
            tx-checksum-ipv6: on
    
    Fixes: a188222b6ed2 ("net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c36d7ee19a9449c696f7d5c58f0a803b16c84b6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 29 14:07:39 2019 +0300

    scsi: smartpqi: unlock on error in pqi_submit_raid_request_synchronous()
    
    [ Upstream commit cc8f52609bb4177febade24d11713e20c0893b0a ]
    
    We need to drop the "ctrl_info->sync_request_sem" lock before returning.
    
    Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-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 284be68326b748ae365aec651da1f8a83f51da45
Author: Avri Altman <avri.altman@wdc.com>
Date:   Tue May 21 11:24:22 2019 +0300

    scsi: ufs: Check that space was properly alloced in copy_query_response
    
    [ Upstream commit 1c90836f70f9a8ef7b7ad9e1fdd8961903e6ced6 ]
    
    struct ufs_dev_cmd is the main container that supports device management
    commands. In the case of a read descriptor request, we assume that the
    proper space was allocated in dev_cmd to hold the returning descriptor.
    
    This is no longer true, as there are flows that doesn't use dev_cmd for
    device management requests, and was wrong in the first place.
    
    Fixes: d44a5f98bb49 (ufs: query descriptor API)
    Signed-off-by: Avri Altman <avri.altman@wdc.com>
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Acked-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f193786d78af356cfff0a5dd478c2a0e81ca3a1c
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Sun Jun 2 15:12:54 2019 +0100

    net: phylink: avoid reducing support mask
    
    [ Upstream commit 77316763321ee4050f0576ffd472183aa90dcb30 ]
    
    Avoid reducing the support mask as a result of the interface type
    selected for SFP modules, or when setting the link settings through
    ethtool - this should only change when the supported link modes of
    the hardware combination change.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f743ff59ea4586f0603c9db2f39177a18fe45047
Author: George G. Davis <george_davis@mentor.com>
Date:   Mon Jun 3 10:30:39 2019 -0400

    scripts/checkstack.pl: Fix arm64 wrong or unknown architecture
    
    [ Upstream commit 4f45d62a52297b10ded963412a158685647ecdec ]
    
    The following error occurs for the `make ARCH=arm64 checkstack` case:
    
    aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \
    perl ./scripts/checkstack.pl arm64
    wrong or unknown architecture "arm64"
    
    As suggested by Masahiro Yamada, fix the above error using regular
    expressions in the same way it was fixed for the `ARCH=x86` case via
    commit fda9f9903be6 ("scripts/checkstack.pl: automatically handle
    32-bit and 64-bit mode for ARCH=x86").
    
    Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89dd8c09ff047139d6d220d4cdcf0aca97d2dadd
Author: Trevor Bourget <tgb.kernel@gmail.com>
Date:   Mon May 27 16:54:23 2019 -0700

    kbuild: tar-pkg: enable communication with jobserver
    
    [ Upstream commit a6e0487709ded7cd1ba0c390d9771e5cb76a8453 ]
    
    The buildtar script might want to invoke a make, so tell the parent
    make to pass the jobserver token pipe to the subcommand by prefixing
    the command with a +.
    
    This addresses the issue seen here:
    
      /bin/sh ../scripts/package/buildtar tar-pkg
      make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
    
    See https://www.gnu.org/software/make/manual/html_node/Job-Slots.html
    for more information.
    
    Signed-off-by: Trevor Bourget <tgb.kernel@gmail.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3d4c4a7a0900daf246cfb713101f4044e9b97fa
Author: Minwoo Im <minwoo.im.dev@gmail.com>
Date:   Sun Jun 2 12:43:39 2019 +0900

    nvmet: fix data_len to 0 for bdev-backed write_zeroes
    
    [ Upstream commit 3562f5d9f21e7779ae442a45197fed6cb247fd22 ]
    
    The WRITE ZEROES command has no data transfer so that we need to
    initialize the struct (nvmet_req *req)->data_len to 0x0.  While
    (nvmet_req *req)->transfer_len is initialized in nvmet_req_init(),
    data_len will be initialized by nowhere which might cause the failure
    with status code NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR randomly.  It's
    because nvmet_req_execute() checks like:
    
            if (unlikely(req->data_len != req->transfer_len)) {
                    req->error_loc = offsetof(struct nvme_common_command, dptr);
                    nvmet_req_complete(req, NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR);
            } else
                    req->execute(req);
    
    This patch fixes req->data_len not to be a randomly assigned by
    initializing it to 0x0 when preparing the command in
    nvmet_bdev_parse_io_cmd().
    
    nvmet_file_parse_io_cmd() which is for file-backed I/O has already
    initialized the data_len field to 0x0, though.
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Cc: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
    Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7185d1119d26fce15d044730c8b09363136c06b7
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Fri May 17 17:37:22 2019 +0100

    drm/arm/hdlcd: Allow a bit of clock tolerance
    
    [ Upstream commit 1c810739097fdeb31b393b67a0a1e3d7ffdd9f63 ]
    
    On the Arm Juno platform, the HDLCD pixel clock is constrained to 250KHz
    resolution in order to avoid the tiny System Control Processor spending
    aeons trying to calculate exact PLL coefficients. This means that modes
    like my oddball 1600x1200 with 130.89MHz clock get rejected since the
    rate cannot be matched exactly. In practice, though, this mode works
    quite happily with the clock at 131MHz, so let's relax the check to
    allow a little bit of slop.
    
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3f7b4ee7a947778f1f4dd3e82f5e1c68c2e99be
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Fri May 17 17:37:21 2019 +0100

    drm/arm/hdlcd: Actually validate CRTC modes
    
    [ Upstream commit b96151edced4edb6a18aa89a5fa02c7066efff45 ]
    
    Rather than allowing any old mode through, then subsequently refusing
    unmatchable clock rates in atomic_check when it's too late to back out
    and pick a different mode, let's do that validation up-front where it
    will cause unsupported modes to be correctly pruned in the first place.
    
    This also eliminates an issue whereby a perceived clock rate of 0 would
    cause atomic disable to fail and prevent the module from being unloaded.
    
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acff41657b2f422aa8079334709b3a1739d78657
Author: Wen He <wen.he_1@nxp.com>
Date:   Wed May 8 10:58:18 2019 +0000

    drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times
    
    [ Upstream commit 6a88e0c14813d00f8520d0e16cd4136c6cf8b4d4 ]
    
    This patch trying to fix monitor freeze issue caused by drm error
    'flip_done timed out' on LS1028A platform. this set try is make a loop
    around the second setting CVAL and try like 5 times before giveing up.
    
    Signed-off-by: Wen He <wen.he_1@nxp.com>
    Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ee5cb63850542814875e247ee3ad2655f5a006e
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Jun 2 19:09:55 2019 +0800

    selftests: set sysctl bc_forwarding properly in router_broadcast.sh
    
    [ Upstream commit 67c0aaa1eaec60e9dab301012bdebe6726ae04bd ]
    
    sysctl setting bc_forwarding for $rp2 is needed when ping_test_from h2,
    otherwise the bc packets from $rp2 won't be forwarded. This patch is to
    add this setting for $rp2.
    
    Also, as ping_test_from does grep "$from" only, which could match some
    unexpected output, some test case doesn't really work, like:
    
      # ping_test_from $h2 198.51.200.255 198.51.200.2
        PING 198.51.200.255 from 198.51.100.2 veth3: 56(84) bytes of data.
        64 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.336 ms
    
    When doing grep $form (198.51.200.2), the output could still match.
    So change to grep "bytes from $from" instead.
    
    Fixes: 40f98b9af943 ("selftests: add a selftest for directed broadcast forwarding")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9bf84c0f6d542751e6f03142778c1d6c2a039a3
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Sat Jun 1 08:16:27 2019 +0800

    net: ethernet: mediatek: Use NET_IP_ALIGN to judge if HW RX_2BYTE_OFFSET is enabled
    
    [ Upstream commit 880c2d4b2fdfd580ebcd6bb7240a8027a1d34751 ]
    
    Should only enable HW RX_2BYTE_OFFSET function in the case NET_IP_ALIGN
    equals to 2.
    
    Signed-off-by: Mark Lee <mark-mc.lee@mediatek.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e04ea19909b659a287714d81ba019d8c488d767
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Sat Jun 1 08:16:26 2019 +0800

    net: ethernet: mediatek: Use hw_feature to judge if HWLRO is supported
    
    [ Upstream commit 9e4f56f1a7f3287718d0083b5cb85298dc05a5fd ]
    
    Should hw_feature as hardware capability flags to check if hardware LRO
    got support.
    
    Signed-off-by: Mark Lee <mark-mc.lee@mediatek.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65c5080a059c549b0463489c503167d56b717421
Author: Young Xiao <92siuyang@gmail.com>
Date:   Wed May 29 10:21:48 2019 +0800

    sparc: perf: fix updated event period in response to PERF_EVENT_IOC_PERIOD
    
    [ Upstream commit 56cd0aefa475079e9613085b14a0f05037518fed ]
    
    The PERF_EVENT_IOC_PERIOD ioctl command can be used to change the
    sample period of a running perf_event. Consequently, when calculating
    the next event period, the new period will only be considered after the
    previous one has overflowed.
    
    This patch changes the calculation of the remaining event ticks so that
    they are offset if the period has changed.
    
    See commit 3581fe0ef37c ("ARM: 7556/1: perf: fix updated event period in
    response to PERF_EVENT_IOC_PERIOD") for details.
    
    Signed-off-by: Young Xiao <92siuyang@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 910282a17f7329bf0d6c5027f1951bc19452b164
Author: Gen Zhang <blackgod016574@gmail.com>
Date:   Fri May 31 09:24:18 2019 +0800

    mdesc: fix a missing-check bug in get_vdev_port_node_info()
    
    [ Upstream commit 80caf43549e7e41a695c6d1e11066286538b336f ]
    
    In get_vdev_port_node_info(), 'node_info->vdev_port.name' is allcoated
    by kstrdup_const(), and it returns NULL when fails. So
    'node_info->vdev_port.name' should be checked.
    
    Signed-off-by: Gen Zhang <blackgod016574@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3c0d72279e1576e404a7e7b92b2bdb668bc0c59
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Fri May 31 16:59:50 2019 +0800

    net: hns: Fix loopback test failed at copper ports
    
    [ Upstream commit 2e1f164861e500f4e068a9d909bbd3fcc7841483 ]
    
    When doing a loopback test at copper ports, the serdes loopback
    and the phy loopback will fail, because of the adjust link had
    not finished, and phy not ready.
    
    Adds sleep between adjust link and test process to fix it.
    
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03217ebb9114bf8c2db4ba3faa709ef2590c74d2
Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date:   Fri May 31 10:35:14 2019 +0300

    net: dsa: mv88e6xxx: avoid error message on remove from VLAN 0
    
    [ Upstream commit 62394708f3e01c9f2be6be74eb6305bae1ed924f ]
    
    When non-bridged, non-vlan'ed mv88e6xxx port is moving down, error
    message is logged:
    
    failed to kill vid 0081/0 for device eth_cu_1000_4
    
    This is caused by call from __vlan_vid_del() with vin set to zero, over
    call chain this results into _mv88e6xxx_port_vlan_del() called with
    vid=0, and mv88e6xxx_vtu_get() called from there returns -EINVAL.
    
    On symmetric path moving port up, call goes through
    mv88e6xxx_port_vlan_prepare() that calls mv88e6xxx_port_check_hw_vlan()
    that returns -EOPNOTSUPP for zero vid.
    
    This patch changes mv88e6xxx_vtu_get() to also return -EOPNOTSUPP for
    zero vid, then this error code is explicitly cleared in
    dsa_slave_vlan_rx_kill_vid() and error message is no longer logged.
    
    Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
    Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3eaf80d71360d095ff07d2cb7032e987a6ec0b3a
Author: Naresh Kamboju <naresh.kamboju@linaro.org>
Date:   Tue May 28 13:18:09 2019 +0100

    selftests: vm: install test_vmalloc.sh for run_vmtests
    
    [ Upstream commit bc2cce3f2ebcae02aa4bb29e3436bf75ee674c32 ]
    
    Add test_vmalloc.sh to TEST_FILES to make sure it gets installed for
    run_vmtests.
    
    Fixed below error:
    ./run_vmtests: line 217: ./test_vmalloc.sh: No such file or directory
    
    Tested with: make TARGETS=vm install INSTALL_PATH=$PWD/x
    
    Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eec43bb04ade2c817c174a246586f5ca27623ce6
Author: Alakesh Haloi <alakesh.haloi@gmail.com>
Date:   Mon May 27 15:18:59 2019 +0000

    userfaultfd: selftest: fix compiler warning
    
    [ Upstream commit 98a13a8d253999cf25eb16d901c35fbd2a8455c4 ]
    
    Fixes following compiler warning
    
    userfaultfd.c: In function ‘usage’:
    userfaultfd.c:126:2: warning: format not a string literal and no format
            arguments [-Wformat-security]
      fprintf(stderr, examples);
    
    Signed-off-by: Alakesh Haloi <alakesh.haloi@gmail.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8af55656e2b00fa44789b365e638856127ba2b53
Author: Alex Shi <alex.shi@linux.alibaba.com>
Date:   Mon May 27 14:28:07 2019 +0800

    kselftest/cgroup: fix incorrect test_core skip
    
    [ Upstream commit f97f3f8839eb9de5843066d80819884f7722c8c5 ]
    
    The test_core will skip the
    test_cgcore_no_internal_process_constraint_on_threads test case if the
    'cpu' controller missing in root's subtree_control. In fact we need to
    set the 'cpu' in subtree_control, to make the testing meaningful.
    
    ./test_core
    ...
    ok 4 # skip test_cgcore_no_internal_process_constraint_on_threads
    ...
    
    Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Claudio Zumbo <claudioz@fb.com>
    Cc: Claudio <claudiozumbo@gmail.com>
    Cc: linux-kselftest@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Reviewed-by: Roman Gushchin <guro@fb.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 003724b3eba573502d13499d49617be1e2b53251
Author: Alex Shi <alex.shi@linux.alibaba.com>
Date:   Mon May 27 14:28:06 2019 +0800

    kselftest/cgroup: fix unexpected testing failure on test_core
    
    [ Upstream commit 00e38a5d753d7788852f81703db804a60a84c26e ]
    
    The cgroup testing relys on the root cgroup's subtree_control setting,
    If the 'memory' controller isn't set, some test cases will be failed
    as following:
    
    $sudo  ./test_core
    not ok 1 test_cgcore_internal_process_constraint
    ok 2 test_cgcore_top_down_constraint_enable
    not ok 3 test_cgcore_top_down_constraint_disable
    ...
    
    To correct this unexpected failure, this patch write the 'memory' to
    subtree_control of root to get a right result.
    
    Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Claudio Zumbo <claudioz@fb.com>
    Cc: Claudio <claudiozumbo@gmail.com>
    Cc: linux-kselftest@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Reviewed-by: Roman Gushchin <guro@fb.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed5082e72569c1eae5654688c9d31faab255403a
Author: Alex Shi <alex.shi@linux.alibaba.com>
Date:   Mon May 27 14:28:05 2019 +0800

    kselftest/cgroup: fix unexpected testing failure on test_memcontrol
    
    [ Upstream commit f6131f28057d4fd8922599339e701a2504e0f23d ]
    
    The cgroup testing relies on the root cgroup's subtree_control setting,
    If the 'memory' controller isn't set, all test cases will be failed
    as following:
    
    $ sudo ./test_memcontrol
    not ok 1 test_memcg_subtree_control
    not ok 2 test_memcg_current
    ok 3 # skip test_memcg_min
    not ok 4 test_memcg_low
    not ok 5 test_memcg_high
    not ok 6 test_memcg_max
    not ok 7 test_memcg_oom_events
    ok 8 # skip test_memcg_swap_max
    not ok 9 test_memcg_sock
    not ok 10 test_memcg_oom_group_leaf_events
    not ok 11 test_memcg_oom_group_parent_events
    not ok 12 test_memcg_oom_group_score_events
    
    To correct this unexpected failure, this patch write the 'memory' to
    subtree_control of root to get a right result.
    
    Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Jay Kamat <jgkamat@fb.com>
    Cc: linux-kselftest@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Reviewed-by: Roman Gushchin <guro@fb.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5eb93bd2f9de6aada07d12601ef8eb8cccbae050
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu May 30 05:41:38 2019 -0700

    xtensa: Fix section mismatch between memblock_reserve and mem_reserve
    
    [ Upstream commit adefd051a6707a6ca0ebad278d3c1c05c960fc3b ]
    
    Since commit 9012d011660ea5cf2 ("compiler: allow all arches to enable
    CONFIG_OPTIMIZE_INLINING"), xtensa:tinyconfig fails to build with section
    mismatch errors.
    
    WARNING: vmlinux.o(.text.unlikely+0x68): Section mismatch in reference
            from the function ___pa()
            to the function .meminit.text:memblock_reserve()
    WARNING: vmlinux.o(.text.unlikely+0x74): Section mismatch in reference
            from the function mem_reserve()
            to the function .meminit.text:memblock_reserve()
    FATAL: modpost: Section mismatches detected.
    
    This was not seen prior to the above mentioned commit because mem_reserve()
    was always inlined.
    
    Mark mem_reserve(() as __init_memblock to have it reside in the same
    section as memblock_reserve().
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Message-Id: <1559220098-9955-1-git-send-email-linux@roeck-us.net>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7348616edde5ea7f98c9b58893e953e228c25a4b
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed May 22 12:42:29 2019 -0700

    crypto: hmac - fix memory leak in hmac_init_tfm()
    
    [ Upstream commit 7829a0c1cb9c80debfb4fdb49b4d90019f2ea1ac ]
    
    When I added the sanity check of 'descsize', I missed that the child
    hash tfm needs to be freed if the sanity check fails.  Of course this
    should never happen, hence the use of WARN_ON(), but it should be fixed.
    
    Fixes: e1354400b25d ("crypto: hash - fix incorrect HASH_MAX_DESCSIZE")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62e5facae8997c6dba85c3e2f9474017f6a9fe05
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sat May 25 20:20:24 2019 +0800

    MIPS: uprobes: remove set but not used variable 'epc'
    
    [ Upstream commit f532beeeff0c0a3586cc15538bc52d249eb19e7c ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    arch/mips/kernel/uprobes.c: In function 'arch_uprobe_pre_xol':
    arch/mips/kernel/uprobes.c:115:17: warning: variable 'epc' set but not used [-Wunused-but-set-variable]
    
    It's never used since introduction in
    commit 40e084a506eb ("MIPS: Add uprobes support.")
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: <ralf@linux-mips.org>
    Cc: <jhogan@kernel.org>
    Cc: <linux-kernel@vger.kernel.org>
    Cc: <linux-mips@vger.kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f17c4c68e9b736f24d225f6c9218abe00a6e5d97
Author: Kamenee Arumugam <kamenee.arumugam@intel.com>
Date:   Fri May 24 11:45:04 2019 -0400

    IB/hfi1: Validate page aligned for a given virtual address
    
    [ Upstream commit 97736f36dbebf2cda2799db3b54717ba5b388255 ]
    
    User applications can register memory regions for TID buffers that are not
    aligned on page boundaries. Hfi1 is expected to pin those pages in memory
    and cache the pages with mmu_rb. The rb tree will fail to insert pages
    that are not aligned correctly.
    
    Validate whether a given virtual address is page aligned before pinning.
    
    Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
    Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Signed-off-by: Kamenee Arumugam <kamenee.arumugam@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ac3c4dbb126174a84b10ce95123c1546ad884d8
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri May 24 11:44:51 2019 -0400

    IB/{qib, hfi1, rdmavt}: Correct ibv_devinfo max_mr value
    
    [ Upstream commit 35164f5259a47ea756fa1deb3e463ac2a4f10dc9 ]
    
    The command 'ibv_devinfo -v' reports 0 for max_mr.
    
    Fix by assigning the query values after the mr lkey_table has been built
    rather than early on in the driver.
    
    Fixes: 7b1e2099adc8 ("IB/rdmavt: Move memory registration into rdmavt")
    Reviewed-by: Josh Collier <josh.d.collier@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52a1322ae30f47411c938a372a80cd939c13509d
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri May 24 11:44:45 2019 -0400

    IB/hfi1: Insure freeze_work work_struct is canceled on shutdown
    
    [ Upstream commit 6d517353c70bb0818b691ca003afdcb5ee5ea44e ]
    
    By code inspection, the freeze_work is never canceled.
    
    Fix by adding a cancel_work_sync in the shutdown path to insure it is no
    longer running.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a8810db7baa9e25fc852b6ecd03d74dd412fd2a
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri May 24 11:44:38 2019 -0400

    IB/rdmavt: Fix alloc_qpn() WARN_ON()
    
    [ Upstream commit 2abae62a26a265129b364d8c1ef3be55e2c01309 ]
    
    The qpn allocation logic has a WARN_ON() that intends to detect the use of
    an index that will introduce bits in the lower order bits of the QOS bits
    in the QPN.
    
    Unfortunately, it has the following bugs:
    - it misfires when wrapping QPN allocation for non-QOS
    - it doesn't correctly detect low order QOS bits (despite the comment)
    
    The WARN_ON() should not be applied to non-QOS (qos_shift == 1).
    
    Additionally, it SHOULD test the qpn bits per the table below:
    
    2 data VLs:   [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
                  [  0,   0,   0,   0,   0,   0, sc0],  qp bit 1 always 0*
    3-4 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
                  [  0,   0,   0,   0,   0, sc1, sc0], qp bits [21] always 0
    5-8 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
                  [  0,   0,   0,   0, sc2, sc1, sc0] qp bits [321] always 0
    
    Fix by qualifying the warning for qos_shift > 1 and producing the correct
    mask to insure the above bits are zero without generating a superfluous
    warning.
    
    Fixes: 501edc42446e ("IB/rdmavt: Correct warning during QPN allocation")
    Reviewed-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e787555f1bd0c6248b57957780a5c05e58765c71
Author: Oded Gabbay <oded.gabbay@gmail.com>
Date:   Tue May 28 23:03:54 2019 +0300

    habanalabs: fix bug in checking huge page optimization
    
    [ Upstream commit d724170160f800fa8dfd3c0cdebb8b093570b504 ]
    
    This patch fix a bug in the mmu code that checks whether we can use huge
    page mappings for host pages.
    
    The code is supposed to enable huge page mappings only if ALL DMA
    addresses are aligned to 2MB AND the number of pages in each DMA chunk is
    a modulo of the number of pages in 2MB. However, the code ignored the
    first requirement for the first DMA chunk.
    
    This patch fix that issue by making sure the requirement of address
    alignment is validated against all DMA chunks.
    
    Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97ff3f30338b29ecebf384facb1a5495b2c052ec
Author: Helge Deller <deller@gmx.de>
Date:   Fri May 24 23:16:25 2019 +0200

    parisc: Fix compiler warnings in float emulation code
    
    [ Upstream commit 6b98d9134e14f5ef4bcf64b27eedf484ed19a1ec ]
    
    Avoid such compiler warnings:
    arch/parisc/math-emu/cnv_float.h:71:27: warning: ‘<<’ in boolean context, did you mean ‘<’ ? [-Wint-in-bool-context]
         ((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB))
    arch/parisc/math-emu/fcnvxf.c:257:6: note: in expansion of macro ‘Dint_isinexact_to_sgl’
      if (Dint_isinexact_to_sgl(srcp1,srcp2)) {
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b2c6ad567c7458ee1c296a5a4ec10cae65f0175
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue May 14 23:24:37 2019 +0800

    parport: Fix mem leak in parport_register_dev_model
    
    [ Upstream commit 1c7ebeabc9e5ee12e42075a597de40fdb9059530 ]
    
    BUG: memory leak
    unreferenced object 0xffff8881df48cda0 (size 16):
      comm "syz-executor.0", pid 5077, jiffies 4295994670 (age 22.280s)
      hex dump (first 16 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000d2d0d5fe>] parport_register_dev_model+0x141/0x6e0 [parport]
        [<00000000782f6dab>] 0xffffffffc15d1196
        [<00000000d2ca6ae4>] platform_drv_probe+0x7e/0x100
        [<00000000628c2a94>] really_probe+0x342/0x4d0
        [<000000006874f5da>] driver_probe_device+0x8c/0x170
        [<00000000424de37a>] __device_attach_driver+0xda/0x100
        [<000000002acab09a>] bus_for_each_drv+0xfe/0x170
        [<000000003d9e5f31>] __device_attach+0x190/0x230
        [<0000000035d32f80>] bus_probe_device+0x123/0x140
        [<00000000a05ba627>] device_add+0x7cc/0xce0
        [<000000003f7560bf>] platform_device_add+0x230/0x3c0
        [<000000002a0be07d>] 0xffffffffc15d0949
        [<000000007361d8d2>] port_check+0x3b/0x50 [parport]
        [<000000004d67200f>] bus_for_each_dev+0x115/0x180
        [<000000003ccfd11c>] __parport_register_driver+0x1f0/0x210 [parport]
        [<00000000987f06fc>] 0xffffffffc15d803e
    
    After commit 4e5a74f1db8d ("parport: Revert "parport: fix
    memory leak""), free_pardevice do not free par_dev->state,
    we should free it in error path of parport_register_dev_model
    before return.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 4e5a74f1db8d ("parport: Revert "parport: fix memory leak"")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b31d306aa9ba9bd90a03e235a5e706ff4f99e13
Author: Scott Wood <swood@redhat.com>
Date:   Thu May 9 16:08:28 2019 -0500

    fpga: dfl: Add lockdep classes for pdata->lock
    
    [ Upstream commit dfe3de8d397bf878b31864d4e489d41118ec475f ]
    
    struct dfl_feature_platform_data (and it's mutex) is used
    by both fme and port devices, and when lockdep is enabled it
    complains about nesting between these locks.  Tell lockdep about
    the difference so it can track each class separately.
    
    Here's the lockdep complaint:
    [  409.680668] WARNING: possible recursive locking detected
    [  409.685983] 5.1.0-rc3.fpga+ #1 Tainted: G            E
    [  409.691469] --------------------------------------------
    [  409.696779] fpgaconf/9348 is trying to acquire lock:
    [  409.701746] 00000000a443fe2e (&pdata->lock){+.+.}, at: port_enable_set+0x24/0x60 [dfl_afu]
    [  409.710006]
    [  409.710006] but task is already holding lock:
    [  409.715837] 0000000063b78782 (&pdata->lock){+.+.}, at: fme_pr_ioctl+0x21d/0x330 [dfl_fme]
    [  409.724012]
    [  409.724012] other info that might help us debug this:
    [  409.730535]  Possible unsafe locking scenario:
    [  409.730535]
    [  409.736457]        CPU0
    [  409.738910]        ----
    [  409.741360]   lock(&pdata->lock);
    [  409.744679]   lock(&pdata->lock);
    [  409.747999]
    [  409.747999]  *** DEADLOCK ***
    [  409.747999]
    [  409.753920]  May be due to missing lock nesting notation
    [  409.753920]
    [  409.760704] 4 locks held by fpgaconf/9348:
    [  409.764805]  #0: 0000000063b78782 (&pdata->lock){+.+.}, at: fme_pr_ioctl+0x21d/0x330 [dfl_fme]
    [  409.773408]  #1: 00000000213c8a66 (&region->mutex){+.+.}, at: fpga_region_program_fpga+0x24/0x200 [fpga_region]
    [  409.783489]  #2: 00000000fe63afb9 (&mgr->ref_mutex){+.+.}, at: fpga_mgr_lock+0x15/0x40 [fpga_mgr]
    [  409.792354]  #3: 000000000b2285c5 (&bridge->mutex){+.+.}, at: __fpga_bridge_get+0x26/0xa0 [fpga_bridge]
    [  409.801740]
    [  409.801740] stack backtrace:
    [  409.806102] CPU: 45 PID: 9348 Comm: fpgaconf Kdump: loaded Tainted: G            E     5.1.0-rc3.fpga+ #1
    [  409.815658] Hardware name: Intel Corporation S2600BT/S2600BT, BIOS SE5C620.86B.01.00.0763.022420181017 02/24/2018
    [  409.825911] Call Trace:
    [  409.828369]  dump_stack+0x5e/0x8b
    [  409.831686]  __lock_acquire+0xf3d/0x10e0
    [  409.835612]  ? find_held_lock+0x3c/0xa0
    [  409.839451]  lock_acquire+0xbc/0x1d0
    [  409.843030]  ? port_enable_set+0x24/0x60 [dfl_afu]
    [  409.847823]  ? port_enable_set+0x24/0x60 [dfl_afu]
    [  409.852616]  __mutex_lock+0x86/0x970
    [  409.856195]  ? port_enable_set+0x24/0x60 [dfl_afu]
    [  409.860989]  ? port_enable_set+0x24/0x60 [dfl_afu]
    [  409.865777]  ? __mutex_unlock_slowpath+0x4b/0x290
    [  409.870486]  port_enable_set+0x24/0x60 [dfl_afu]
    [  409.875106]  fpga_bridges_disable+0x36/0x50 [fpga_bridge]
    [  409.880502]  fpga_region_program_fpga+0xea/0x200 [fpga_region]
    [  409.886338]  fme_pr_ioctl+0x13e/0x330 [dfl_fme]
    [  409.890870]  fme_ioctl+0x66/0xe0 [dfl_fme]
    [  409.894973]  do_vfs_ioctl+0xa9/0x720
    [  409.898548]  ? lockdep_hardirqs_on+0xf0/0x1a0
    [  409.902907]  ksys_ioctl+0x60/0x90
    [  409.906225]  __x64_sys_ioctl+0x16/0x20
    [  409.909981]  do_syscall_64+0x5a/0x220
    [  409.913644]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [  409.918698] RIP: 0033:0x7f9d31b9b8d7
    [  409.922276] Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
    [  409.941020] RSP: 002b:00007ffe4cae0d68 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
    [  409.948588] RAX: ffffffffffffffda RBX: 00007f9d32ade6a0 RCX: 00007f9d31b9b8d7
    [  409.955719] RDX: 00007ffe4cae0df0 RSI: 000000000000b680 RDI: 0000000000000003
    [  409.962852] RBP: 0000000000000003 R08: 00007f9d2b70a177 R09: 00007ffe4cae0e40
    [  409.969984] R10: 00007ffe4cae0160 R11: 0000000000000202 R12: 00007ffe4cae0df0
    [  409.977115] R13: 000000000000b680 R14: 0000000000000000 R15: 00007ffe4cae0f60
    
    Signed-off-by: Scott Wood <swood@redhat.com>
    Acked-by: Wu Hao <hao.wu@intel.com>
    Acked-by: Alan Tull <atull@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 940ec88924e597e245cd2a6b1fdfcc806872c883
Author: Scott Wood <swood@redhat.com>
Date:   Thu May 9 16:08:27 2019 -0500

    fpga: dfl: afu: Pass the correct device to dma_mapping_error()
    
    [ Upstream commit 13069847a475b60069918dc9971f5adb42811ce3 ]
    
    dma_mapping_error() was being called on a different device struct than
    what was passed to map/unmap.  Besides rendering the error checking
    ineffective, it caused a debug splat with CONFIG_DMA_API_DEBUG.
    
    Signed-off-by: Scott Wood <swood@redhat.com>
    Acked-by: Wu Hao <hao.wu@intel.com>
    Acked-by: Moritz Fischer <mdf@kernel.org>
    Acked-by: Alan Tull <atull@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f42d43aed4d3853e1a8cd0e0230762ac5e38e5c0
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Thu May 9 16:08:26 2019 -0500

    fpga: stratix10-soc: fix use-after-free on s10_init()
    
    [ Upstream commit f5dd87326fefe42a4b1a4b1a1a695060c33a88d6 ]
    
    The refcount of fw_np has already been decreased by of_find_matching_node()
    so it shouldn't be used anymore.
    This patch adds an of_node_get() before of_find_matching_node() to avoid
    the use-after-free problem.
    
    Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Cc: Alan Tull <atull@kernel.org>
    Cc: Moritz Fischer <mdf@kernel.org>
    Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Cc: linux-fpga@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Reviewed-by: Moritz Fischer <mdf@kernel.org>
    Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Acked-by: Alan Tull <atull@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ff0a7300513b526ea3bc95b4c91f8113e1a9a92
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Tue May 21 15:20:39 2019 +0900

    MIPS: mark ginvt() as __always_inline
    
    [ Upstream commit 6074c33c6b2eabc70867ef76d57ca256e9ea9da7 ]
    
    To meet the 'i' (immediate) constraint for the asm operands,
    this function must be always inlined.
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: linux-mips@vger.kernel.org
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b131e9d10384d2230f2d8de8f01612cf76f80e7f
Author: Jose Abreu <joabreu@synopsys.com>
Date:   Mon May 20 15:43:13 2019 +0200

    ARC: [plat-hsdk]: Add missing FIFO size entry in GMAC node
    
    [ Upstream commit 4c70850aeb2e40016722cd1abd43c679666d3ca0 ]
    
    Add the binding for RX/TX fifo size of GMAC node.
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Vineet Gupta <vgupta@synopsys.com>
    Tested-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb9e8a827e35280710ded59e56b9e6c4e0ad9e9e
Author: Jose Abreu <joabreu@synopsys.com>
Date:   Mon May 20 15:43:12 2019 +0200

    ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node
    
    [ Upstream commit ecc906a11c2a0940e1a380debd8bd5bc09faf454 ]
    
    GMAC controller on HSDK boards supports 256 Hash Table size so we need to
    add the multicast filter bins property. This allows for the Hash filter
    to work properly using stmmac driver.
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce7d789bb90bd2b53065bf097310d563044cf232
Author: Eric Long <eric.long@unisoc.com>
Date:   Mon May 6 15:28:32 2019 +0800

    dmaengine: sprd: Fix the right place to configure 2-stage transfer
    
    [ Upstream commit c434e377dad1dec05cad1870ce21bc539e1e024f ]
    
    Move the 2-stage configuration before configuring the link-list mode,
    since we will use some 2-stage configuration to fill the link-list
    configuration.
    
    Signed-off-by: Eric Long <eric.long@unisoc.com>
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 544671fac56e69b646664311c9790b89dfb3d328
Author: Eric Long <eric.long@unisoc.com>
Date:   Mon May 6 15:28:31 2019 +0800

    dmaengine: sprd: Fix block length overflow
    
    [ Upstream commit 89d03b3c126d683f7b2cd5b07178493993d12448 ]
    
    The maximum value of block length is 0xffff, so if the configured transfer length
    is more than 0xffff, that will cause block length overflow to lead a configuration
    error.
    
    Thus we can set block length as the maximum burst length to avoid this issue, since
    the maximum burst length will not be a big value which is more than 0xffff.
    
    Signed-off-by: Eric Long <eric.long@unisoc.com>
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ef397924060d1431a1a2e4aa09964276da97d92
Author: Eric Long <eric.long@unisoc.com>
Date:   Mon May 6 15:28:30 2019 +0800

    dmaengine: sprd: Fix the incorrect start for 2-stage destination channels
    
    [ Upstream commit 3d626a97f0303e9c30d063434b749de3f0f91fb5 ]
    
    The 2-stage destination channel will be triggered by source channel
    automatically, which means we should not trigger it by software request.
    
    Signed-off-by: Eric Long <eric.long@unisoc.com>
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36090046e762aa70c118b501bdf2b3aa79c112d5
Author: Baolin Wang <baolin.wang@linaro.org>
Date:   Mon May 6 15:28:29 2019 +0800

    dmaengine: sprd: Add validation of current descriptor in irq handler
    
    [ Upstream commit 58152b0e573e5581c4b9ef7cf06d2e9fafae27d4 ]
    
    When user terminates one DMA channel to free all its descriptors, but
    at the same time one transaction interrupt was triggered possibly, now
    we should not handle this interrupt by validating if the 'schan->cur_desc'
    was set as NULL to avoid crashing the kernel.
    
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af410491e083806859c7d43f5d2ddf6eef947942
Author: Baolin Wang <baolin.wang@linaro.org>
Date:   Mon May 6 15:28:28 2019 +0800

    dmaengine: sprd: Fix the possible crash when getting descriptor status
    
    [ Upstream commit 16d0f85e45b99411ac10cb12cdd9279204a72381 ]
    
    We will get a NULL virtual descriptor by vchan_find_desc() when the descriptor
    has been submitted, that will crash the kernel when getting the descriptor
    status.
    
    In this case, since the descriptor has been submitted to process, but it
    is not completed now, which means the descriptor is listed into the
    'vc->desc_submitted' list now. So we can not get current processing descriptor
    by vchan_find_desc(), but the pointer 'schan->cur_desc' will point to the
    current processing descriptor, then we can use 'schan->cur_desc' to get
    current processing descriptor's status to avoid this issue.
    
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 644d39260f9af967f92171088380b906ecd69e28
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 9 13:09:23 2019 +0300

    dmaengine: mediatek-cqdma: sleeping in atomic context
    
    [ Upstream commit 069b3c4214f27b130d0642f32438560db30f452e ]
    
    The mtk_cqdma_poll_engine_done() function takes a true/false parameter
    where true means it's called from atomic context.  There are a couple
    places where it was set to false but it's actually in atomic context
    so it should be true.
    
    All the callers for mtk_cqdma_hard_reset() are holding a spin_lock and
    in mtk_cqdma_free_chan_resources() we take a spin_lock before calling
    the mtk_cqdma_poll_engine_done() function.
    
    Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09167890636f32760cc6f90cb8e701cc85b16c3f
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed May 8 23:33:29 2019 +0100

    dmaengine: dw-axi-dmac: fix null dereference when pointer first is null
    
    [ Upstream commit 0788611c9a0925c607de536b2449de5ed98ef8df ]
    
    In the unlikely event that axi_desc_get returns a null desc in the
    very first iteration of the while-loop the error exit path ends
    up calling axi_desc_put on a null pointer 'first' and this causes
    a null pointer dereference.  Fix this by adding a null check on
    pointer 'first' before calling axi_desc_put.
    
    Addresses-Coverity: ("Explicit null dereference")
    Fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bd19c830b31676d854b24d967727618d47417e0
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Sat May 4 23:37:57 2019 +0200

    dmaengine: jz4780: Fix transfers being ACKed too soon
    
    [ Upstream commit 4e4106f5e942bff65548e82fc330d40385c89220 ]
    
    When a multi-descriptor DMA transfer is in progress, the "IRQ pending"
    flag will apparently be set for that channel as soon as the last
    descriptor loads, way before the IRQ actually happens. This behaviour
    has been observed on the JZ4725B, but maybe other SoCs are affected.
    
    In the case where another DMA transfer is running into completion on a
    separate channel, the IRQ handler would then run the completion handler
    for our previous channel even if the transfer didn't actually finish.
    
    Fix this by checking in the completion handler that we're indeed done;
    if not the interrupted DMA transfer will simply be resumed.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f23dc2c3ad8587cb2308c3f9647bd31d50b185d8
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Tue May 7 10:45:24 2019 -0700

    ARC: fix build warnings
    
    [ Upstream commit 89c92142f75eb80064f5b9f1111484b1b4d81790 ]
    
    | arch/arc/mm/tlb.c:914:2: warning: variable length array 'pd0' is used [-Wvla]
    | arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is not used [-Wunused-value]
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3656dca39b5367ceb51bfd0fa448d9bfc7012972
Author: Kees Cook <keescook@chromium.org>
Date:   Sat Apr 6 08:52:11 2019 -0700

    lkdtm/usercopy: Moves the KERNEL_DS test to non-canonical
    
    [ Upstream commit 2bf8496f6e9b7e9a557f65eb95eab16fea7958c7 ]
    
    The prior implementation of the KERNEL_DS fault checking would work on
    any unmapped kernel address, but this was narrowed to the non-canonical
    range instead. This adjusts the LKDTM test to match.
    
    Fixes: 00c42373d397 ("x86-64: add warning for non-canonical user access address dereferences")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 226fe899656a6dddf35a336ac4df67d2224fdf91
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Jun 17 10:56:53 2019 -0700

    brcmfmac: sdio: Don't tune while the card is off
    
    commit 65dade6044079a5c206fd1803642ff420061417a upstream.
    
    When Broadcom SDIO cards are idled they go to sleep and a whole
    separate subsystem takes over their SDIO communication.  This is the
    Always-On-Subsystem (AOS) and it can't handle tuning requests.
    
    Specifically, as tested on rk3288-veyron-minnie (which reports having
    BCM4354/1 in dmesg), if I force a retune in brcmf_sdio_kso_control()
    when "on = 1" (aka we're transition from sleep to wake) by whacking:
      bus->sdiodev->func1->card->host->need_retune = 1
    ...then I can often see tuning fail.  In this case dw_mmc reports "All
    phases bad!").  Note that I don't get 100% failure, presumably because
    sometimes the card itself has already transitioned away from the AOS
    itself by the time we try to wake it up.  If I force retuning when "on
    = 0" (AKA force retuning right before sending the command to go to
    sleep) then retuning is always OK.
    
    NOTE: we need _both_ this patch and the patch to avoid triggering
    tuning due to CRC errors in the sleep/wake transition, AKA ("brcmfmac:
    sdio: Disable auto-tuning around commands expected to fail").  Though
    both patches handle issues with Broadcom's AOS, the problems are
    distinct:
    1. We want to defer (but not ignore) asynchronous (like
       timer-requested) tuning requests till the card is awake.  However,
       we want to ignore CRC errors during the transition, we don't want
       to queue deferred tuning request.
    2. You could imagine that the AOS could implement retuning but we
       could still get errors while transitioning in and out of the AOS.
       Similarly you could imagine a seamless transition into and out of
       the AOS (with no CRC errors) even if the AOS couldn't handle
       tuning.
    
    ALSO NOTE: presumably there is never a desperate need to retune in
    order to wake up the card, since doing so is impossible.  Luckily the
    only way the card can get into sleep state is if we had a good enough
    tuning to send it the command to put it into sleep, so presumably that
    "good enough" tuning is enough to wake us up, at least with a few
    retries.
    
    Cc: stable@vger.kernel.org #v4.18+
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Acked-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fb27eff18a612896b83550c6bad2746f0c56223
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Jun 17 10:56:51 2019 -0700

    brcmfmac: sdio: Disable auto-tuning around commands expected to fail
    
    commit 2de0b42da263c97d330d276f5ccf7c4470e3324f upstream.
    
    There are certain cases, notably when transitioning between sleep and
    active state, when Broadcom SDIO WiFi cards will produce errors on the
    SDIO bus.  This is evident from the source code where you can see that
    we try commands in a loop until we either get success or we've tried
    too many times.  The comment in the code reinforces this by saying
    "just one write attempt may fail"
    
    Unfortunately these failures sometimes end up causing an "-EILSEQ"
    back to the core which triggers a retuning of the SDIO card and that
    blocks all traffic to the card until it's done.
    
    Let's disable retuning around the commands we expect might fail.
    
    Cc: stable@vger.kernel.org #v4.18+
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Acked-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56f92e344c81d26d6bb0a11e2394beb15407b22f
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Jun 17 10:56:49 2019 -0700

    Revert "brcmfmac: disable command decode in sdio_aos"
    
    commit abdd5dcc00207e7c38680f3754d1bfffafff1093 upstream.
    
    This reverts commit 29f6589140a10ece8c1d73f58043ea5b3473ab3e.
    
    After that patch landed I find that my kernel log on
    rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
    brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
    
    This seems to happen every time the Broadcom WiFi transitions out of
    sleep mode.  Reverting the commit fixes the problem for me, so that's
    what this patch does.
    
    Note that, in general, the justification in the original commit seemed
    a little weak.  It looked like someone was testing on a SD card
    controller that would sometimes die if there were CRC errors on the
    bus.  This used to happen back in early days of dw_mmc (the controller
    on my boards), but we fixed it.  Disabling a feature on all boards
    just because one SD card controller is broken seems bad.
    
    Fixes: 29f6589140a1 ("brcmfmac: disable command decode in sdio_aos")
    Cc: Wright Feng <wright.feng@cypress.com>
    Cc: Double Lo <double.lo@cypress.com>
    Cc: Madhan Mohan R <madhanmohan.r@cypress.com>
    Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Cc: stable@vger.kernel.org
    Acked-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db71d6e6f770246f75febc2d2d19cfbf1686012e
Author: Mike Salvatore <mike.salvatore@canonical.com>
Date:   Wed Jun 12 14:55:14 2019 -0700

    apparmor: reset pos on failure to unpack for various functions
    
    commit 156e42996bd84eccb6acf319f19ce0cb140d00e3 upstream.
    
    Each function that manipulates the aa_ext struct should reset it's "pos"
    member on failure. This ensures that, on failure, no changes are made to
    the state of the aa_ext struct.
    
    There are paths were elements are optional and the error path is
    used to indicate the optional element is not present. This means
    instead of just aborting on error the unpack stream can become
    unsynchronized on optional elements, if using one of the affected
    functions.
    
    Cc: stable@vger.kernel.org
    Fixes: 736ec752d95e ("AppArmor: policy routines for loading and unpacking policy")
    Signed-off-by: Mike Salvatore <mike.salvatore@canonical.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3fd819edcca48a4f5d4e1bbcf392450912a0f2f
Author: Jann Horn <jannh@google.com>
Date:   Tue May 28 17:32:26 2019 +0200

    apparmor: enforce nullbyte at end of tag string
    
    commit 8404d7a674c49278607d19726e0acc0cae299357 upstream.
    
    A packed AppArmor policy contains null-terminated tag strings that are read
    by unpack_nameX(). However, unpack_nameX() uses string functions on them
    without ensuring that they are actually null-terminated, potentially
    leading to out-of-bounds accesses.
    
    Make sure that the tag string is null-terminated before passing it to
    strcmp().
    
    Cc: stable@vger.kernel.org
    Fixes: 736ec752d95e ("AppArmor: policy routines for loading and unpacking policy")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80118c5ab6cfe6e9113a57425dbae095095f66eb
Author: John Johansen <john.johansen@canonical.com>
Date:   Sun May 26 06:42:23 2019 -0700

    apparmor: fix PROFILE_MEDIATES for untrusted input
    
    commit 23375b13f98c5464c2b4d15f983cc062940f1f4e upstream.
    
    While commit 11c236b89d7c2 ("apparmor: add a default null dfa") ensure
    every profile has a policy.dfa it does not resize the policy.start[]
    to have entries for every possible start value. Which means
    PROFILE_MEDIATES is not safe to use on untrusted input. Unforunately
    commit b9590ad4c4f2 ("apparmor: remove POLICY_MEDIATES_SAFE") did not
    take into account the start value usage.
    
    The input string in profile_query_cb() is user controlled and is not
    properly checked to be within the limited start[] entries, even worse
    it can't be as userspace policy is allowed to make us of entries types
    the kernel does not know about. This mean usespace can currently cause
    the kernel to access memory up to 240 entries beyond the start array
    bounds.
    
    Cc: stable@vger.kernel.org
    Fixes: b9590ad4c4f2 ("apparmor: remove POLICY_MEDIATES_SAFE")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9665c361daa7d75d5b9e2a31fb53a2a18cdad622
Author: Daniel Smith <danct12@disroot.org>
Date:   Thu May 23 12:54:18 2019 -0700

    Input: silead - add MSSL0017 to acpi_device_id
    
    commit 0e658060e5fc50dc282885dc424a94b5d95547e5 upstream.
    
    On Chuwi Hi10 Plus, the Silead device id is MSSL0017.
    
    Signed-off-by: Daniel Smith <danct12@disroot.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 251d1bd93738a23e2d257803e469b57eb69e62e8
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu May 23 12:55:26 2019 -0700

    Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD
    
    commit 7c7da40da1640ce6814dab1e8031b44e19e5a3f6 upstream.
    
    In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and
    UI_END_FF_UPLOAD need to be adjusted before being passed on
    uinput_ioctl_handler() since code built with -m32 will be passing
    slightly different values. Extend the code already covering
    UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well.
    
    Reported-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d36869b3ede316039438ab37e166885efdb99b55
Author: Alexander Mikhaylenko <exalm7659@gmail.com>
Date:   Wed Jun 12 14:59:46 2019 -0700

    Input: synaptics - enable SMBus on ThinkPad E480 and E580
    
    commit 9843f3e08e2144724be7148e08d77a195dea257a upstream.
    
    They are capable of using intertouch and it works well with
    psmouse.synaptics_intertouch=1, so add them to the list.
    
    Without it, scrolling and gestures are jumpy, three-finger pinch gesture
    doesn't work and three- or four-finger swipes sometimes get stuck.
    
    Signed-off-by: Alexander Mikhaylenko <exalm7659@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5229f10241c2562c66aca68b75d39297db5d8222
Author: Crt Mori <cmo@melexis.com>
Date:   Thu May 23 14:07:22 2019 +0200

    iio: temperature: mlx90632 Relax the compatibility check
    
    commit 389fc70b60f534d679aea9a3f05146040ce20d77 upstream.
    
    Register EE_VERSION contains mixture of calibration information and DSP
    version. So far, because calibrations were definite, the driver
    compatibility depended on whole contents, but in the newer production
    process the calibration part changes. Because of that, value in EE_VERSION
    will be changed and to avoid that calibration value is same as DSP version
    the MSB in calibration part was fixed to 1.
    That means existing calibrations (medical and consumer) will now have
    hex values (bits 8 to 15) of 83 and 84 respectively. Driver compatibility
    should be based only on DSP version part of the EE_VERSION (bits 0 to 7)
    register.
    
    Signed-off-by: Crt Mori <cmo@melexis.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a9be6a8e87b2d04516c1548e665ba5925e3c938
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sun May 19 10:58:23 2019 +0200

    iio: imu: st_lsm6dsx: fix PM support for st_lsm6dsx i2c controller
    
    commit bce0d57db388cdb1c1931d0aa7d31c77b590e0f0 upstream.
    
    Properly suspend/resume i2c slaves connected to st_lsm6dsx master
    controller if the CPU goes in suspended state
    
    Fixes: c91c1c844ebd ("imu: st_lsm6dsx: add i2c embedded controller support")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.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 0875fd7da38f9100ac74b1a2a8d0af79adc72a30
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri Jun 14 12:32:32 2019 -0400

    IB/hfi1: Silence txreq allocation warnings
    
    commit 3230f4a8d44e4a0bb7afea814b280b5129521f52 upstream.
    
    The following warning can happen when a memory shortage
    occurs during txreq allocation:
    
    [10220.939246] SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
    [10220.939246] Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS SE5C610.86B.01.01.0018.C4.072020161249 07/20/2016
    [10220.939247]   cache: mnt_cache, object size: 384, buffer size: 384, default order: 2, min order: 0
    [10220.939260] Workqueue: hfi0_0 _hfi1_do_send [hfi1]
    [10220.939261]   node 0: slabs: 1026568, objs: 43115856, free: 0
    [10220.939262] Call Trace:
    [10220.939262]   node 1: slabs: 820872, objs: 34476624, free: 0
    [10220.939263]  dump_stack+0x5a/0x73
    [10220.939265]  warn_alloc+0x103/0x190
    [10220.939267]  ? wake_all_kswapds+0x54/0x8b
    [10220.939268]  __alloc_pages_slowpath+0x86c/0xa2e
    [10220.939270]  ? __alloc_pages_nodemask+0x2fe/0x320
    [10220.939271]  __alloc_pages_nodemask+0x2fe/0x320
    [10220.939273]  new_slab+0x475/0x550
    [10220.939275]  ___slab_alloc+0x36c/0x520
    [10220.939287]  ? hfi1_make_rc_req+0x90/0x18b0 [hfi1]
    [10220.939299]  ? __get_txreq+0x54/0x160 [hfi1]
    [10220.939310]  ? hfi1_make_rc_req+0x90/0x18b0 [hfi1]
    [10220.939312]  __slab_alloc+0x40/0x61
    [10220.939323]  ? hfi1_make_rc_req+0x90/0x18b0 [hfi1]
    [10220.939325]  kmem_cache_alloc+0x181/0x1b0
    [10220.939336]  hfi1_make_rc_req+0x90/0x18b0 [hfi1]
    [10220.939348]  ? hfi1_verbs_send_dma+0x386/0xa10 [hfi1]
    [10220.939359]  ? find_prev_entry+0xb0/0xb0 [hfi1]
    [10220.939371]  hfi1_do_send+0x1d9/0x3f0 [hfi1]
    [10220.939372]  process_one_work+0x171/0x380
    [10220.939374]  worker_thread+0x49/0x3f0
    [10220.939375]  kthread+0xf8/0x130
    [10220.939377]  ? max_active_store+0x80/0x80
    [10220.939378]  ? kthread_bind+0x10/0x10
    [10220.939379]  ret_from_fork+0x35/0x40
    [10220.939381] SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
    
    The shortage is handled properly so the message isn't needed. Silence by
    adding the no warn option to the slab allocation.
    
    Fixes: 45842abbb292 ("staging/rdma/hfi1: move txreq header code")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 065d452e1ffc27ef797df550c29482e09ce80e99
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Mon Jun 10 12:28:18 2019 -0400

    IB/hfi1: Correct tid qp rcd to match verbs context
    
    commit cc78076af14e1478c1a8fb18997674b5f8cbe3c8 upstream.
    
    The qp priv rcd pointer doesn't match the context being used for verbs
    causing issues when 9B and kdeth packets are processed by different
    receive contexts and hence different CPUs.
    
    When running on different CPUs the following panic can occur:
    
     WARNING: CPU: 3 PID: 2584 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0
     list_del corruption. prev->next should be ffff9a7ac31f7a30, but was ffff9a7c3bc89230
     CPU: 3 PID: 2584 Comm: z_wr_iss Kdump: loaded Tainted: P           OE  ------------   3.10.0-862.2.3.el7_lustre.x86_64 #1
     Call Trace:
      <IRQ>  [<ffffffffb7b0d78e>] dump_stack+0x19/0x1b
      [<ffffffffb74916d8>] __warn+0xd8/0x100
      [<ffffffffb749175f>] warn_slowpath_fmt+0x5f/0x80
      [<ffffffffb7768671>] __list_del_entry+0xa1/0xd0
      [<ffffffffc0c7a945>] process_rcv_qp_work+0xb5/0x160 [hfi1]
      [<ffffffffc0c7bc2b>] handle_receive_interrupt_nodma_rtail+0x20b/0x2b0 [hfi1]
      [<ffffffffc0c70683>] receive_context_interrupt+0x23/0x40 [hfi1]
      [<ffffffffb7540a94>] __handle_irq_event_percpu+0x44/0x1c0
      [<ffffffffb7540c42>] handle_irq_event_percpu+0x32/0x80
      [<ffffffffb7540ccc>] handle_irq_event+0x3c/0x60
      [<ffffffffb7543a1f>] handle_edge_irq+0x7f/0x150
      [<ffffffffb742d504>] handle_irq+0xe4/0x1a0
      [<ffffffffb7b23f7d>] do_IRQ+0x4d/0xf0
      [<ffffffffb7b16362>] common_interrupt+0x162/0x162
      <EOI>  [<ffffffffb775a326>] ? memcpy+0x6/0x110
      [<ffffffffc109210d>] ? abd_copy_from_buf_off_cb+0x1d/0x30 [zfs]
      [<ffffffffc10920f0>] ? abd_copy_to_buf_off_cb+0x30/0x30 [zfs]
      [<ffffffffc1093257>] abd_iterate_func+0x97/0x120 [zfs]
      [<ffffffffc10934d9>] abd_copy_from_buf_off+0x39/0x60 [zfs]
      [<ffffffffc109b828>] arc_write_ready+0x178/0x300 [zfs]
      [<ffffffffb7b11032>] ? mutex_lock+0x12/0x2f
      [<ffffffffb7b11032>] ? mutex_lock+0x12/0x2f
      [<ffffffffc1164d05>] zio_ready+0x65/0x3d0 [zfs]
      [<ffffffffc04d725e>] ? tsd_get_by_thread+0x2e/0x50 [spl]
      [<ffffffffc04d1318>] ? taskq_member+0x18/0x30 [spl]
      [<ffffffffc115ef22>] zio_execute+0xa2/0x100 [zfs]
      [<ffffffffc04d1d2c>] taskq_thread+0x2ac/0x4f0 [spl]
      [<ffffffffb74cee80>] ? wake_up_state+0x20/0x20
      [<ffffffffc115ee80>] ? zio_taskq_member.isra.7.constprop.10+0x80/0x80 [zfs]
      [<ffffffffc04d1a80>] ? taskq_thread_spawn+0x60/0x60 [spl]
      [<ffffffffb74bae31>] kthread+0xd1/0xe0
      [<ffffffffb74bad60>] ? insert_kthread_work+0x40/0x40
      [<ffffffffb7b1f5f7>] ret_from_fork_nospec_begin+0x21/0x21
      [<ffffffffb74bad60>] ? insert_kthread_work+0x40/0x40
    
    Fix by reading the map entry in the same manner as the hardware so that
    the kdeth and verbs contexts match.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 5190f052a365 ("IB/hfi1: Allow the driver to initialize QP priv struct")
    Reviewed-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3db7d8f09caf7c818ffd4de95803f95f7b16d6cc
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri Jun 14 12:32:26 2019 -0400

    IB/hfi1: Avoid hardlockup with flushlist_lock
    
    commit cf131a81967583ae737df6383a0893b9fee75b4e upstream.
    
    Heavy contention of the sde flushlist_lock can cause hard lockups at
    extreme scale when the flushing logic is under stress.
    
    Mitigate by replacing the item at a time copy to the local list with
    an O(1) list_splice_init() and using the high priority work queue to
    do the flushes.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2df772b397a120b10deae3d070e209a5581cfbe
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri Jun 7 08:25:31 2019 -0400

    IB/hfi1: Close PSM sdma_progress sleep window
    
    commit da9de5f8527f4b9efc82f967d29a583318c034c7 upstream.
    
    The call to sdma_progress() is called outside the wait lock.
    
    In this case, there is a race condition where sdma_progress() can return
    false and the sdma_engine can idle.  If that happens, there will be no
    more sdma interrupts to cause the wakeup and the user_sdma xmit will hang.
    
    Fix by moving the lock to enclose the sdma_progress() call.
    
    Also, delete busycount. The need for this was removed by:
    commit bcad29137a97 ("IB/hfi1: Serve the most starved iowait entry first")
    
    Cc: <stable@vger.kernel.org>
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Reviewed-by: Gary Leshner <Gary.S.Leshner@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7a285f7c2e70e0c9be871a100b1c96af820f295
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Fri Jun 7 08:25:25 2019 -0400

    IB/hfi1: Validate fault injection opcode user input
    
    commit 5f90677ed31963abb184ee08ebee4a4a68225dd8 upstream.
    
    The opcode range for fault injection from user should be validated before
    it is applied to the fault->opcodes[] bitmap to avoid out-of-bound
    error.
    
    Cc: <stable@vger.kernel.org>
    Fixes: a74d5307caba ("IB/hfi1: Rework fault injection machinery")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e4fd61d08e41df508ce06efb3c4db9de2eddc08
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Fri Jun 14 13:02:29 2019 +1000

    cifs: fix GlobalMid_Lock bug in cifs_reconnect
    
    commit 61cabc7b0a5cf0d3c532cfa96594c801743fe7f6 upstream.
    
    We can not hold the GlobalMid_Lock spinlock during the
    dfs processing in cifs_reconnect since it invokes things that may sleep
    and thus trigger :
    
    BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:23
    
    Thus we need to drop the spinlock during this code block.
    
    RHBZ: 1716743
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e941b47b47276d95d5670e3f131a798ed9dacad
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Wed Jun 5 10:38:38 2019 +1000

    cifs: add spinlock for the openFileList to cifsInodeInfo
    
    commit 487317c99477d00f22370625d53be3239febabbe upstream.
    
    We can not depend on the tcon->open_file_lock here since in multiuser mode
    we may have the same file/inode open via multiple different tcons.
    
    The current code is race prone and will crash if one user deletes a file
    at the same time a different user opens/create the file.
    
    To avoid this we need to have a spinlock attached to the inode and not the tcon.
    
    RHBZ:  1580165
    
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a79a60f05cffb98111cad4d53a8caa822ef263e
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Jun 18 17:27:47 2019 +0300

    usb: xhci: Don't try to recover an endpoint if port is in error state.
    
    commit b8c3b718087bf7c3c8e388eb1f72ac1108a4926e upstream.
    
    A USB3 device needs to be reset and re-enumarated if the port it
    connects to goes to a error state, with link state inactive.
    
    There is no use in trying to recover failed transactions by resetting
    endpoints at this stage. Tests show that in rare cases, after multiple
    endpoint resets of a roothub port the whole host controller might stop
    completely.
    
    Several retries to recover from transaction error can happen as
    it can take a long time before the hub thread discovers the USB3
    port error and inactive link.
    
    We can't reliably detect the port error from slot or endpoint context
    due to a limitation in xhci, see xhci specs section 4.8.3:
    "There are several cases where the EP State field in the Output
    Endpoint Context may not reflect the current state of an endpoint"
    and
    "Software should maintain an accurate value for EP State, by tracking it
    with an internal variable that is driven by Events and Doorbell accesses"
    
    Same appears to be true for slot state.
    
    set a flag to the corresponding slot if a USB3 roothub port link goes
    inactive to prevent both queueing new URBs and resetting endpoints.
    
    Reported-by: Rapolu Chiranjeevi <chiranjeevi.rapolu@intel.com>
    Tested-by: Rapolu Chiranjeevi <chiranjeevi.rapolu@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee742005831ce1ab34cefe7e9a9183609735cadc
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Jun 18 17:27:48 2019 +0300

    xhci: detect USB 3.2 capable host controllers correctly
    
    commit ddd57980a0fde30f7b5d14b888a2cc84d01610e8 upstream.
    
    USB 3.2 capability in a host can be detected from the
    xHCI Supported Protocol Capability major and minor revision fields.
    
    If major is 0x3 and minor 0x20 then the host is USB 3.2 capable.
    
    For USB 3.2 capable hosts set the root hub lane count to 2.
    
    The Major Revision and Minor Revision fields contain a BCD version number.
    The value of the Major Revision field is JJh and the value of the Minor
    Revision field is MNh for version JJ.M.N, where JJ = major revision number,
    M - minor version number, N = sub-minor version number,
    e.g. version 3.1 is represented with a value of 0310h.
    
    Also fix the extra whitespace printed out when announcing regular
    SuperSpeed hosts.
    
    Cc: <stable@vger.kernel.org> # v4.18+
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94207779337a5cf47dbb3218995c33a4041ebd12
Author: Peter Chen <peter.chen@nxp.com>
Date:   Mon Jun 17 09:49:07 2019 +0800

    usb: chipidea: udc: workaround for endpoint conflict issue
    
    commit c19dffc0a9511a7d7493ec21019aefd97e9a111b upstream.
    
    An endpoint conflict occurs when the USB is working in device mode
    during an isochronous communication. When the endpointA IN direction
    is an isochronous IN endpoint, and the host sends an IN token to
    endpointA on another device, then the OUT transaction may be missed
    regardless the OUT endpoint number. Generally, this occurs when the
    device is connected to the host through a hub and other devices are
    connected to the same hub.
    
    The affected OUT endpoint can be either control, bulk, isochronous, or
    an interrupt endpoint. After the OUT endpoint is primed, if an IN token
    to the same endpoint number on another device is received, then the OUT
    endpoint may be unprimed (cannot be detected by software), which causes
    this endpoint to no longer respond to the host OUT token, and thus, no
    corresponding interrupt occurs.
    
    There is no good workaround for this issue, the only thing the software
    could do is numbering isochronous IN from the highest endpoint since we
    have observed most of device number endpoint from the lowest.
    
    Cc: <stable@vger.kernel.org> #v3.14+
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Cc: Jun Li <jun.li@nxp.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0d4c85bc39fb5639cf6377eff98cee03af2d5a5
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Wed Jun 12 23:19:05 2019 +0800

    scsi: ufs: Avoid runtime suspend possibly being blocked forever
    
    commit 24e2e7a19f7e4b83d0d5189040d997bce3596473 upstream.
    
    UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
    in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
    before binding ufs_hba structure to ufs device structure via
    platform_set_drvdata(), then UFS runtime suspend will be no longer
    triggered in the future because its dev->power.runtime_error was set in the
    first triggering and does not have any chance to be cleared.
    
    To be more clear, dev->power.runtime_error is set if hba is NULL in
    ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
    dev->power.runtime_error is set as -EINVAL. In this case, any future
    rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
    fails due to non-zero
    dev->power.runtime_error.
    
    To resolve this issue, make sure the first UFS runtime suspend get valid
    "hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
    successfully bound to UFS device structure.
    
    Fixes: 62694735ca95 ([SCSI] ufs: Add runtime PM support for UFS host controller driver)
    Cc: stable@vger.kernel.org
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec959de3d3a45a24c9ffb2a4aaa6c3b5df61031f
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Jun 18 14:05:17 2019 +0200

    mmc: core: Prevent processing SDIO IRQs when the card is suspended
    
    commit 83293386bc95cf5e9f0c0175794455835bd1cb4a upstream.
    
    Processing of SDIO IRQs must obviously be prevented while the card is
    system suspended, otherwise we may end up trying to communicate with an
    uninitialized SDIO card.
    
    Reports throughout the years shows that this is not only a theoretical
    problem, but a real issue. So, let's finally fix this problem, by keeping
    track of the state for the card and bail out before processing the SDIO
    IRQ, in case the card is suspended.
    
    Cc: stable@vger.kernel.org
    Reported-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55dc448847c9edaf128234bc6f14ac9d16c11e6c
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Jun 17 10:56:52 2019 -0700

    mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
    
    commit b4c9f938d542d5f88c501744d2d12fad4fd2915f upstream.
    
    We want SDIO drivers to be able to temporarily stop retuning when the
    driver knows that the SDIO card is not in a state where retuning will
    work (maybe because the card is asleep).  We'll move the relevant
    functions to a place where drivers can call them.
    
    Cc: stable@vger.kernel.org #v4.18+
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Acked-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ea454840793b8c8022d242cba3ad8f92cae5313
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Jun 17 10:56:50 2019 -0700

    mmc: core: API to temporarily disable retuning for SDIO CRC errors
    
    commit 0a55f4ab9678413a01e740c86e9367ba0c612b36 upstream.
    
    Normally when the MMC core sees an "-EILSEQ" error returned by a host
    controller then it will trigger a retuning of the card.  This is
    generally a good idea.
    
    However, if a command is expected to sometimes cause transfer errors
    then these transfer errors shouldn't cause a re-tuning.  This
    re-tuning will be a needless waste of time.  One example case where a
    transfer is expected to cause errors is when transitioning between
    idle (sometimes referred to as "sleep" in Broadcom code) and active
    state on certain Broadcom WiFi SDIO cards.  Specifically if the card
    was already transitioning between states when the command was sent it
    could cause an error on the SDIO bus.
    
    Let's add an API that the SDIO function drivers can call that will
    temporarily disable the auto-tuning functionality.  Then we can add a
    call to this in the Broadcom WiFi driver and any other driver that
    might have similar needs.
    
    NOTE: this makes the assumption that the card is already tuned well
    enough that it's OK to disable the auto-retuning during one of these
    error-prone situations.  Presumably the driver code performing the
    error-prone transfer knows how to recover / retry from errors.  ...and
    after we can get back to a state where transfers are no longer
    error-prone then we can enable the auto-retuning again.  If we truly
    find ourselves in a case where the card needs to be retuned sometimes
    to handle one of these error-prone transfers then we can always try a
    few transfers first without auto-retuning and then re-try with
    auto-retuning if the first few fail.
    
    Without this change on rk3288-veyron-minnie I periodically see this in
    the logs of a machine just sitting there idle:
      dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ
    
    Cc: stable@vger.kernel.org #v4.18+
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Acked-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e9ff1ef4f32432ba7ee8f6cfc9a4eaee3472698
Author: jjian zhou <jjian.zhou@mediatek.com>
Date:   Mon Jun 17 19:04:08 2019 +0800

    mmc: mediatek: fix SDIO IRQ detection issue
    
    commit 20314ce30af197963b0c239f0952db6aaef73f99 upstream.
    
    If cmd19 timeout or response crcerr occurs during execute_tuning(),
    it need invoke msdc_reset_hw(). Otherwise SDIO IRQ can't be detected.
    
    Signed-off-by: jjian zhou <jjian.zhou@mediatek.com>
    Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
    Signed-off-by: Yong Mao <yong.mao@mediatek.com>
    Fixes: 5215b2e952f3 ("mmc: mediatek: Add MMC_CAP_SDIO_IRQ support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 121d0ccd34e6f009965b4d4faac73f4ce621d07c
Author: jjian zhou <jjian.zhou@mediatek.com>
Date:   Mon Jun 17 19:04:07 2019 +0800

    mmc: mediatek: fix SDIO IRQ interrupt handle flow
    
    commit 8a5df8ac628f4febea1e6cd3044bff2d536dd096 upstream.
    
    SDIO IRQ is triggered by low level. It need disable SDIO IRQ
    detected function. Otherwise the interrupt register can't be cleared.
    It will process the interrupt more.
    
    Signed-off-by: Jjian Zhou <jjian.zhou@mediatek.com>
    Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
    Signed-off-by: Yong Mao <yong.mao@mediatek.com>
    Fixes: 5215b2e952f3 ("mmc: mediatek: Add MMC_CAP_SDIO_IRQ support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 952202198396c47bc42144fa6f7bde8510eee9e5
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jun 6 13:35:35 2019 +0200

    mmc: sdhi: disallow HS400 for M3-W ES1.2, RZ/G2M, and V3H
    
    commit 97bf85b6ec9e6597ce81c79b26a28f7918fc4eaf upstream.
    
    Our HW engineers informed us that HS400 is not working on these SoC
    revisions.
    
    Fixes: 0f4e2054c971 ("mmc: renesas_sdhi: disable HS400 on H3 ES1.x and M3-W ES1.[012]")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7f0a215d7d351f009d05563a56252d424c99c5e
Author: Raul E Rangel <rrangel@chromium.org>
Date:   Mon Jun 17 14:10:12 2019 -0600

    mmc: sdhci: sdhci-pci-o2micro: Correctly set bus width when tuning
    
    commit 0f7b79a44e7d7dd3ef1f59758c1a341f217ff5e5 upstream.
    
    The O2Micro controller only supports tuning at 4-bits. So the host driver
    needs to change the bus width while tuning and then set it back when done.
    
    There was a bug in the original implementation in that mmc->ios.bus_width
    also wasn't updated. Thus setting the incorrect blocksize in
    sdhci_send_tuning which results in a tuning failure.
    
    Signed-off-by: Raul E Rangel <rrangel@chromium.org>
    Fixes: 0086fc217d5d7 ("mmc: sdhci: Add support for O2 hardware tuning")
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c64cefcb9e959efb2c6dd20460fce17e21ea6b4a
Author: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Thu May 23 14:45:35 2019 +0200

    tracing: Silence GCC 9 array bounds warning
    
    commit 0c97bf863efce63d6ab7971dad811601e6171d2f upstream.
    
    Starting with GCC 9, -Warray-bounds detects cases when memset is called
    starting on a member of a struct but the size to be cleared ends up
    writing over further members.
    
    Such a call happens in the trace code to clear, at once, all members
    after and including `seq` on struct trace_iterator:
    
        In function 'memset',
            inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3:
        ./include/linux/string.h:344:9: warning: '__builtin_memset' offset
        [8505, 8560] from the object at 'iter' is out of the bounds of
        referenced subobject 'seq' with type 'struct trace_seq' at offset
        4368 [-Warray-bounds]
          344 |  return __builtin_memset(p, c, size);
              |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    In order to avoid GCC complaining about it, we compute the address
    ourselves by adding the offsetof distance instead of referring
    directly to the member.
    
    Since there are two places doing this clear (trace.c and trace_kdb.c),
    take the chance to move the workaround into a single place in
    the internal header.
    
    Link: http://lkml.kernel.org/r/20190523124535.GA12931@gmail.com
    
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    [ Removed unnecessary parenthesis around "iter" ]
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>