commit 0f7c162c1df596e0bba04c26fc9cc497983bf32b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 27 10:09:58 2019 +0100

    Linux 4.20.13

commit d1384133127ecfa699371852e90d38174d9a112d
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Mon Feb 11 15:04:24 2019 +0000

    net: phylink: avoid resolving link state too early
    
    commit 87454b6edc1b0143fdb3d9853285477e95af74a4 upstream.
    
    During testing on Armada 388 platforms, it was found with a certain
    module configuration that it was possible to trigger a kernel oops
    during the module load process, caused by the phylink resolver being
    triggered for a currently disabled interface.
    
    This problem was introduced by changing the way the SFP registration
    works, which now can result in the sfp link down notification being
    called during phylink_create().
    
    Fixes: b5bfc21af5cb ("net: sfp: do not probe SFP module before we're attached")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84b68a1b05ff454efa99b973bccccfc7939dc79b
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Wed Oct 31 17:50:21 2018 -0700

    pinctrl: max77620: Use define directive for max77620_pinconf_param values
    
    commit 1f60652dd586d1b3eee7c4602892a97a62fa937a upstream.
    
    Clang warns when one enumerated type is implicitly converted to another:
    
    drivers/pinctrl/pinctrl-max77620.c:56:12: warning: implicit conversion
    from enumeration type 'enum max77620_pinconf_param' to different
    enumeration type 'enum pin_config_param' [-Wenum-conversion]
                    .param = MAX77620_ACTIVE_FPS_SOURCE,
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~
    
    It is expected that pinctrl drivers can extend pin_config_param because
    of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
    isn't an issue. Most drivers that take advantage of this define the
    PIN_CONFIG variables as constants, rather than enumerated values. Do the
    same thing here so that Clang no longer warns.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/139
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 685aa44734513c808bf448ca0dd874d1faa3f67b
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Nov 5 18:23:13 2018 +0900

    netfilter: ipt_CLUSTERIP: fix sleep-in-atomic bug in clusterip_config_entry_put()
    
    commit 2a61d8b883bbad26b06d2e6cc3777a697e78830d upstream.
    
    A proc_remove() can sleep. so that it can't be inside of spin_lock.
    Hence proc_remove() is moved to outside of spin_lock. and it also
    adds mutex to sync create and remove of proc entry(config->pde).
    
    test commands:
    SHELL#1
       %while :; do iptables -A INPUT -p udp -i enp2s0 -d 192.168.1.100 \
               --dport 9000  -j CLUSTERIP --new --hashmode sourceip \
               --clustermac 01:00:5e:00:00:21 --total-nodes 3 --local-node 3; \
               iptables -F; done
    
    SHELL#2
       %while :; do echo +1 > /proc/net/ipt_CLUSTERIP/192.168.1.100; \
               echo -1 > /proc/net/ipt_CLUSTERIP/192.168.1.100; done
    
    [ 2949.569864] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
    [ 2949.579944] in_atomic(): 1, irqs_disabled(): 0, pid: 5472, name: iptables
    [ 2949.587920] 1 lock held by iptables/5472:
    [ 2949.592711]  #0: 000000008f0ebcf2 (&(&cn->lock)->rlock){+...}, at: refcount_dec_and_lock+0x24/0x50
    [ 2949.603307] CPU: 1 PID: 5472 Comm: iptables Tainted: G        W         4.19.0-rc5+ #16
    [ 2949.604212] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
    [ 2949.604212] Call Trace:
    [ 2949.604212]  dump_stack+0xc9/0x16b
    [ 2949.604212]  ? show_regs_print_info+0x5/0x5
    [ 2949.604212]  ___might_sleep+0x2eb/0x420
    [ 2949.604212]  ? set_rq_offline.part.87+0x140/0x140
    [ 2949.604212]  ? _rcu_barrier_trace+0x400/0x400
    [ 2949.604212]  wait_for_completion+0x94/0x710
    [ 2949.604212]  ? wait_for_completion_interruptible+0x780/0x780
    [ 2949.604212]  ? __kernel_text_address+0xe/0x30
    [ 2949.604212]  ? __lockdep_init_map+0x10e/0x5c0
    [ 2949.604212]  ? __lockdep_init_map+0x10e/0x5c0
    [ 2949.604212]  ? __init_waitqueue_head+0x86/0x130
    [ 2949.604212]  ? init_wait_entry+0x1a0/0x1a0
    [ 2949.604212]  proc_entry_rundown+0x208/0x270
    [ 2949.604212]  ? proc_reg_get_unmapped_area+0x370/0x370
    [ 2949.604212]  ? __lock_acquire+0x4500/0x4500
    [ 2949.604212]  ? complete+0x18/0x70
    [ 2949.604212]  remove_proc_subtree+0x143/0x2a0
    [ 2949.708655]  ? remove_proc_entry+0x390/0x390
    [ 2949.708655]  clusterip_tg_destroy+0x27a/0x630 [ipt_CLUSTERIP]
    [ ... ]
    
    Fixes: b3e456fce9f5 ("netfilter: ipt_CLUSTERIP: fix a race condition of proc file creation")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8316b60582facd4068fb0916c4db2418c21b7174
Author: Fernando Fernandez Mancera <ffmancera@riseup.net>
Date:   Mon Jan 21 12:53:21 2019 +0100

    netfilter: nfnetlink_osf: add missing fmatch check
    
    commit 1a6a0951fc009f6d9fe8ebea2d2417d80d54097b upstream.
    
    When we check the tcp options of a packet and it doesn't match the current
    fingerprint, the tcp packet option pointer must be restored to its initial
    value in order to do the proper tcp options check for the next fingerprint.
    
    Here we can see an example.
    Assumming the following fingerprint base with two lines:
    
    S10:64:1:60:M*,S,T,N,W6:      Linux:3.0::Linux 3.0
    S20:64:1:60:M*,S,T,N,W7:      Linux:4.19:arch:Linux 4.1
    
    Where TCP options are the last field in the OS signature, all of them overlap
    except by the last one, ie. 'W6' versus 'W7'.
    
    In case a packet for Linux 4.19 kicks in, the osf finds no matching because the
    TCP options pointer is updated after checking for the TCP options in the first
    line.
    
    Therefore, reset pointer back to where it should be.
    
    Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match")
    Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6977be15bb4ea68bbd60582c62215a9a848e4d95
Author: Eli Cooper <elicooper@gmx.com>
Date:   Mon Jan 21 18:45:27 2019 +0800

    netfilter: ipv6: Don't preserve original oif for loopback address
    
    commit 15df03c661cb362366ecfc3a21820cb934f3e4ca upstream.
    
    Commit 508b09046c0f ("netfilter: ipv6: Preserve link scope traffic
    original oif") made ip6_route_me_harder() keep the original oif for
    link-local and multicast packets. However, it also affected packets
    for the loopback address because it used rt6_need_strict().
    
    REDIRECT rules in the OUTPUT chain rewrite the destination to loopback
    address; thus its oif should not be preserved. This commit fixes the bug
    that redirected local packets are being dropped. Actually the packet was
    not exactly dropped; Instead it was sent out to the original oif rather
    than lo. When a packet with daddr ::1 is sent to the router, it is
    effectively dropped.
    
    Fixes: 508b09046c0f ("netfilter: ipv6: Preserve link scope traffic original oif")
    Signed-off-by: Eli Cooper <elicooper@gmx.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52e337e8d1552aacf89b964a3dc6ff0fc9498493
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Feb 13 13:03:53 2019 +0100

    netfilter: nft_compat: use-after-free when deleting targets
    
    commit 753c111f655e38bbd52fc01321266633f022ebe2 upstream.
    
    Fetch pointer to module before target object is released.
    
    Fixes: 29e3880109e3 ("netfilter: nf_tables: fix use-after-free when deleting compat expressions")
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9d90bfcf3d75f097144b6038530117bc88b7686
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Feb 15 12:50:24 2019 +0100

    netfilter: nf_tables: fix flush after rule deletion in the same batch
    
    commit 23b7ca4f745f21c2b9cfcb67fdd33733b3ae7e66 upstream.
    
    Flush after rule deletion bogusly hits -ENOENT. Skip rules that have
    been already from nft_delrule_by_chain() which is always called from the
    flush path.
    
    Fixes: cf9dc09d0949 ("netfilter: nf_tables: fix missing rules flushing per table")
    Reported-by: Phil Sutter <phil@nwl.cc>
    Acked-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 848a7f2421d8e186dfbbb5b277d0e889c76d5825
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Fri Feb 22 21:22:32 2019 +0800

    Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"
    
    commit 278e2148c07559dd4ad8602f22366d61eb2ee7b7 upstream.
    
    This reverts commit 5a2de63fd1a5 ("bridge: do not add port to router list
    when receives query with source 0.0.0.0") and commit 0fe5119e267f ("net:
    bridge: remove ipv6 zero address check in mcast queries")
    
    The reason is RFC 4541 is not a standard but suggestive. Currently we
    will elect 0.0.0.0 as Querier if there is no ip address configured on
    bridge. If we do not add the port which recives query with source
    0.0.0.0 to router list, the IGMP reports will not be about to forward
    to Querier, IGMP data will also not be able to forward to dest.
    
    As Nikolay suggested, revert this change first and add a boolopt api
    to disable none-zero election in future if needed.
    
    Reported-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Reported-by: Sebastian Gottschall <s.gottschall@newmedia-net.de>
    Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
    Fixes: 0fe5119e267f ("net: bridge: remove ipv6 zero address check in mcast queries")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66985cda74a7ab67a964589ef6052626d7924452
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Tue Dec 11 15:17:50 2018 +0800

    staging: erofs: unzip_vle_lz4.c,utils.c: rectify BUG_ONs
    
    commit b8e076a6ef253e763bfdb81e5c72bcc828b0fbeb upstream.
    
    remove all redundant BUG_ONs, and turn the rest
    useful usages to DBG_BUGONs.
    
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 611169f52c6b677b0f38f9ee2748ee04775603e1
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Tue Dec 11 15:17:49 2018 +0800

    staging: erofs: unzip_{pagevec.h,vle.c}: rectify BUG_ONs
    
    commit 70b17991d89554cdd16f3e4fb0179bcc03c808d9 upstream.
    
    remove all redundant BUG_ONs, and turn the rest
    useful usages to DBG_BUGONs.
    
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 817c30321c9eab24c5264104d67f822e191ee013
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Wed Dec 5 21:23:13 2018 +0800

    staging: erofs: {dir,inode,super}.c: rectify BUG_ONs
    
    commit 8b987bca2d09649683cbe496419a011df8c08493 upstream.
    
    remove all redundant BUG_ONs, and turn the rest
    useful usages to DBG_BUGONs.
    
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 194a0837376dd783b212c2b99687ec7e447517da
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Fri Nov 23 01:16:03 2018 +0800

    staging: erofs: add a full barrier in erofs_workgroup_unfreeze
    
    commit 948bbdb1818b7ad6e539dad4fbd2dd4650793ea9 upstream.
    
    Just like other generic locks, insert a full barrier
    in case of memory reorder.
    
    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 78c46113413bea1cc345757112aa2642e0f66de5
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Fri Nov 23 01:16:02 2018 +0800

    staging: erofs: fix `erofs_workgroup_{try_to_freeze, unfreeze}'
    
    commit 73f5c66df3e26ab750cefcb9a3e08c71c9f79cad upstream.
    
    There are two minor issues in the current freeze interface:
    
       1) Freeze interfaces have not related with CONFIG_DEBUG_SPINLOCK,
          therefore fix the incorrect conditions;
    
       2) For SMP platforms, it should also disable preemption before
          doing atomic_cmpxchg in case that some high priority tasks
          preempt between atomic_cmpxchg and disable_preempt, then spin
          on the locked refcount later.
    
    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 c6e083d1450c6e5434cd169ff78ce268909b6717
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Fri Nov 23 01:16:01 2018 +0800

    staging: erofs: atomic_cond_read_relaxed on ref-locked workgroup
    
    commit df134b8d17b90c1e7720e318d36416b57424ff7a upstream.
    
    It's better to use atomic_cond_read_relaxed, which is implemented
    in hardware instructions to monitor a variable changes currently
    for ARM64, instead of open-coded busy waiting.
    
    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 49dbec864f3f52ee6ae582de0524d1ef9ad76573
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Sat Nov 3 17:23:56 2018 +0800

    staging: erofs: remove the redundant d_rehash() for the root dentry
    
    commit e9c892465583c8f42d61fafe30970d36580925df upstream.
    
    There is actually no need at all to d_rehash() for the root dentry
    as Al pointed out, fix it.
    
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0dab7eb86ea06ce8c530785f1999948c6f223c96
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Feb 18 23:37:12 2019 -0500

    net: avoid false positives in untrusted gso validation
    
    commit 9e8db5913264d3967b93c765a6a9e464d9c473db upstream.
    
    GSO packets with vnet_hdr must conform to a small set of gso_types.
    The below commit uses flow dissection to drop packets that do not.
    
    But it has false positives when the skb is not fully initialized.
    Dissection needs skb->protocol and skb->network_header.
    
    Infer skb->protocol from gso_type as the two must agree.
    SKB_GSO_UDP can use both ipv4 and ipv6, so try both.
    
    Exclude callers for which network header offset is not known.
    
    Fixes: d5be7f632bad ("net: validate untrusted gso packets without csum offload")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f709f7b28d76de327373598a0fda9f916c36b5e6
Author: Willem de Bruijn <willemb@google.com>
Date:   Fri Feb 15 12:15:47 2019 -0500

    net: validate untrusted gso packets without csum offload
    
    commit d5be7f632bad0f489879eed0ff4b99bd7fe0b74c upstream.
    
    Syzkaller again found a path to a kernel crash through bad gso input.
    By building an excessively large packet to cause an skb field to wrap.
    
    If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dropped in
    skb_partial_csum_set.
    
    GSO packets that do not set checksum offload are suspicious and rare.
    Most callers of virtio_net_hdr_to_skb already pass them to
    skb_probe_transport_header.
    
    Move that test forward, change it to detect parse failure and drop
    packets on failure as those cleary are not one of the legitimate
    VIRTIO_NET_HDR_GSO types.
    
    Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
    Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df33b662c0f97a6506e4218070011cc19a171ac9
Author: Curtis Malainey <cujomalainey@chromium.org>
Date:   Thu Jan 10 16:21:04 2019 -0800

    ASoC: soc-core: fix init platform memory handling
    
    commit 09ac6a817bd687e7f5dac00470262efdd72f9319 upstream.
    
    snd_soc_init_platform initializes pointers to snd_soc_dai_link which is
    statically allocated and it does this by devm_kzalloc. In the event of
    an EPROBE_DEFER the memory will be freed and the pointers are left
    dangling. snd_soc_init_platform sees the dangling pointers and assumes
    they are pointing to initialized memory and does not reallocate them on
    the second probe attempt which results in a use after free bug since
    devm has freed the memory from the first probe attempt.
    
    Since the intention for snd_soc_dai_link->platform is that it can be set
    statically by the machine driver we need to respect the pointer in the
    event we did not set it but still catch dangling pointers. The solution
    is to add a flag to track whether the pointer was dynamically allocated
    or not.
    
    Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af8159d97c2c368e04acbd64aabb16e8f3b0cab7
Author: Pierre Morel <pmorel@linux.ibm.com>
Date:   Mon Feb 11 10:20:49 2019 +0100

    s390: vsie: Use effective CRYCBD.31 to check CRYCBD validity
    
    commit b10bd9a256aec504c14a7c9b6fccb6301ecf290a upstream.
    
    When facility.76 MSAX3 is present for the guest we must issue a validity
    interception if the CRYCBD is not valid.
    
    The bit CRYCBD.31 is an effective field and tested at each guest level
    and has for effect to mask the facility.76
    
    It follows that if CRYCBD.31 is clear and AP is not in use  we do not
    have to test the CRYCBD validatity even if facility.76 is present in the
    host.
    
    Fixes: 6ee74098201b ("KVM: s390: vsie: allow CRYCB FORMAT-0")
    Cc: stable@vger.kernel.org
    
    Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
    Reported-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Acked-by: Cornelia Huck <cohuck@redhat.com>
    Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Message-Id: <1549876849-32680-1-git-send-email-pmorel@linux.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31e48b91d320343f960050a51ad80c3d55aeeee4
Author: Yu Zhang <yu.c.zhang@linux.intel.com>
Date:   Fri Feb 1 00:09:43 2019 +0800

    kvm: x86: Return LA57 feature based on hardware capability
    
    commit 511da98d207d5c0675a10351b01e37cbe50a79e5 upstream.
    
    Previously, 'commit 372fddf70904 ("x86/mm: Introduce the 'no5lvl' kernel
    parameter")' cleared X86_FEATURE_LA57 in boot_cpu_data, if Linux chooses
    to not run in 5-level paging mode. Yet boot_cpu_data is queried by
    do_cpuid_ent() as the host capability later when creating vcpus, and Qemu
    will not be able to detect this feature and create VMs with LA57 feature.
    
    As discussed earlier, VMs can still benefit from extended linear address
    width, e.g. to enhance features like ASLR. So we would like to fix this,
    by return the true hardware capability when Qemu queries.
    
    Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74ddf52fdad887b2ecbc9f11f7b027d548d3db65
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Fri Feb 22 17:45:01 2019 +0100

    x86/kvm/mmu: fix switch between root and guest MMUs
    
    commit ad7dc69aeb23138cc23c406cac25003b97e8ee17 upstream.
    
    Commit 14c07ad89f4d ("x86/kvm/mmu: introduce guest_mmu") brought one subtle
    change: previously, when switching back from L2 to L1, we were resetting
    MMU hooks (like mmu->get_cr3()) in kvm_init_mmu() called from
    nested_vmx_load_cr3() and now we do that in nested_ept_uninit_mmu_context()
    when we re-target vcpu->arch.mmu pointer.
    The change itself looks logical: if nested_ept_init_mmu_context() changes
    something than nested_ept_uninit_mmu_context() restores it back. There is,
    however, one thing: the following call chain:
    
     nested_vmx_load_cr3()
      kvm_mmu_new_cr3()
        __kvm_mmu_new_cr3()
          fast_cr3_switch()
            cached_root_available()
    
    now happens with MMU hooks pointing to the new MMU (root MMU in our case)
    while previously it was happening with the old one. cached_root_available()
    tries to stash current root but it is incorrect to read current CR3 with
    mmu->get_cr3(), we need to use old_mmu->get_cr3() which in case we're
    switching from L2 to L1 is guest_mmu. (BTW, in shadow page tables case this
    is a non-issue because we don't switch MMU).
    
    While we could've tried to guess that we're switching between MMUs and call
    the right ->get_cr3() from cached_root_available() this seems to be overly
    complicated. Instead, just stash the corresponding CR3 when setting
    root_hpa and make cached_root_available() use the stashed value.
    
    Fixes: 14c07ad89f4d ("x86/kvm/mmu: introduce guest_mmu")
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7f1be401d8a7cd37bb976154f1c884cf6649a24
Author: Yu Zhang <yu.c.zhang@linux.intel.com>
Date:   Fri Feb 1 00:09:23 2019 +0800

    KVM: MMU: record maximum physical address width in kvm_mmu_extended_role
    
    commit de3ccd26fafc707b09792d9b633c8b5b48865315 upstream.
    
    Previously, commit 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow
    MMU reconfiguration is needed") offered some optimization to avoid
    the unnecessary reconfiguration. Yet one scenario is broken - when
    cpuid changes VM's maximum physical address width, reconfiguration
    is needed to reset the reserved bits.  Also, the TDP may need to
    reset its shadow_root_level when this value is changed.
    
    To fix this, a new field, maxphyaddr, is introduced in the extended
    role structure to keep track of the configured guest physical address
    width.
    
    Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b983c699984ae046be507ff3cba96fb260acc7e
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Feb 22 13:21:15 2019 +0100

    mac80211: allocate tailroom for forwarded mesh packets
    
    commit 51d0af222f6fa43134c6187ab4f374630f6e0d96 upstream.
    
    Forwarded packets enter the tx path through ieee80211_add_pending_skb,
    which skips the ieee80211_skb_resize call.
    Fixes WARN_ON in ccmp_encrypt_skb and resulting packet loss.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8050aa445a84cdc65ae4f4a2a668b79f74fdf97d
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Thu Feb 21 18:29:36 2019 +0100

    mac80211: Change default tx_sk_pacing_shift to 7
    
    commit 5c14a4d05f68415af9e41a4e667d1748d41d1baf upstream.
    
    When we did the original tests for the optimal value of sk_pacing_shift, we
    came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
    two, so when picking the shift value I erred on the size of less buffering
    and picked 4 ms instead of 8. This was probably wrong; those 2 ms of extra
    buffering makes a larger difference than I thought.
    
    So, change the default pacing shift to 7, which corresponds to 8 ms of
    buffering. The point of diminishing returns really kicks in after 8 ms, and
    so having this as a default should cut down on the need for extensive
    per-device testing and overrides needed in the drivers.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96410002d57a46b28641782739f7034c3bebfdb0
Author: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Date:   Thu Jan 24 15:07:52 2019 -0500

    drm/amd/display: Fix MST reboot/poweroff sequence
    
    commit d2f0b53bda3193874f3905bc839888f895d1c0cf upstream.
    
    [Why]
    
    drm_dp_mst_topology_mgr_suspend() is added into the new reboot
    sequence, which disables the UP request at the beginning.
    Therefore sideband messages are blocked.
    
    [How]
    
    Finish MST sideband message transaction before UP request is
    suppressed.
    
    Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
    Reviewed-by: Roman Li <Roman.Li@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6d8b85f22fa0728c1584c25dcc0270416439e5e
Author: Christian König <ckoenig.leichtzumerken@gmail.com>
Date:   Wed Feb 20 15:16:06 2019 +0100

    drm/amdgpu: disable bulk moves for now
    
    commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a upstream.
    
    The changes to fix those are two invasive for backporting.
    
    Just disable the feature in 4.20 and 5.0.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Cc: <stable@vger.kernel.org>    [4.20+]
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 218b6d525b036463f3af0e9a1da9d0285ee2bc5b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Feb 15 12:30:19 2019 +0000

    drm/i915/fbdev: Actually configure untiled displays
    
    commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 upstream.
    
    If we skipped all the connectors that were not part of a tile, we would
    leave conn_seq=0 and conn_configured=0, convincing ourselves that we
    had stagnated in our configuration attempts. Avoid this situation by
    starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
    connectors to configure.
    
    Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on stagnation")
    Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-chris@chris-wilson.co.uk
    Cc: <stable@vger.kernel.org> # v3.19+
    (cherry picked from commit d9b308b1f8a1acc0c3279f443d4fe0f9f663252e)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7016c394013cbd5a204b54b26f561bd1f4e666d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Feb 14 23:46:19 2019 +0100

    gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime
    
    commit 450d007d199e632a1a4c4b91302deacd7d56815f upstream.
    
    On HP ProBook 4540s, if PM-runtime is enabled in the radeon driver
    and the direct-complete optimization is used for the radeon device
    during system-wide suspend, the system doesn't resume.
    
    Preventing direct-complete from being used with the radeon device by
    setting the DPM_FLAG_NEVER_SKIP driver flag for it makes the problem
    go away, which indicates that direct-complete is not safe for the
    radeon driver in general and should not be used with it (at least
    for now).
    
    This fixes a regression introduced by commit c62ec4610c40
    ("PM / core: Fix direct_complete handling for devices with no
    callbacks") which allowed direct-complete to be applied to
    devices without PM callbacks (again) which in turn unlocked
    direct-complete for radeon on HP ProBook 4540s.
    
    Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=201519
    Reported-by: Ярослав Семченко <ukrkyi@gmail.com>
    Tested-by: Ярослав Семченко <ukrkyi@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 653e691b69332e6fa2b330e777ae7d6b35e22a34
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Feb 18 17:11:38 2019 -0500

    drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime
    
    commit d33158530660bc89be3cc870a2152e4e9a76cac7 upstream.
    
    Based on a similar patch from Rafael for radeon.
    
    When using ATPX to control dGPU power, the state is not retained
    across suspend and resume cycles by default.  This can probably
    be loosened for Hybrid Graphics (_PR3) laptops where I think the
    state is properly retained.
    
    Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks")
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58940d7855f12381cb44368d106061ff327c0405
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Sat Feb 16 11:31:48 2019 -0500

    cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
    
    commit 8cbd468bdeb5ed3acac2d7a9f7494d5b77e46297 upstream.
    
    This issue was detected with the help of Coccinelle. So
    change the order of function calls to fix it.
    
    Fixes: 1690d8bb91e37 (cpufreq: scpi/scmi: Fix freeing of dynamic OPPs)
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Acked-by: Sudeep Holla <sudeep.holla@arm.com>
    Cc: 4.20+ <stable@vger.kernel.org> # 4.20+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 283c27e398a8f6f6177fa521843eea7ceca3829e
Author: Alexey Brodkin <abrodkin@synopsys.com>
Date:   Fri Feb 8 13:55:19 2019 +0300

    ARC: define ARCH_SLAB_MINALIGN = 8
    
    commit b6835ea77729e7faf4656ca637ba53f42b8ee3fd upstream.
    
    The default value of ARCH_SLAB_MINALIGN in "include/linux/slab.h" is
    "__alignof__(unsigned long long)" which for ARC unexpectedly turns out
    to be 4. This is not a compiler bug, but as defined by ARC ABI [1]
    
    Thus slab allocator would allocate a struct which is 32-bit aligned,
    which is generally OK even if struct has long long members.
    There was however potetial problem when it had any atomic64_t which
    use LLOCKD/SCONDD instructions which are required by ISA to take
    64-bit addresses. This is the problem we ran into
    
    [    4.015732] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
    [    4.167881] Misaligned Access
    [    4.172356] Path: /bin/busybox.nosuid
    [    4.176004] CPU: 2 PID: 171 Comm: rm Not tainted 4.19.14-yocto-standard #1
    [    4.182851]
    [    4.182851] [ECR   ]: 0x000d0000 => Check Programmer's Manual
    [    4.190061] [EFA   ]: 0xbeaec3fc
    [    4.190061] [BLINK ]: ext4_delete_entry+0x210/0x234
    [    4.190061] [ERET  ]: ext4_delete_entry+0x13e/0x234
    [    4.202985] [STAT32]: 0x80080002 : IE K
    [    4.207236] BTA: 0x9009329c   SP: 0xbe5b1ec4  FP: 0x00000000
    [    4.212790] LPS: 0x9074b118  LPE: 0x9074b120 LPC: 0x00000000
    [    4.218348] r00: 0x00000040  r01: 0x00000021 r02: 0x00000001
    ...
    ...
    [    4.270510] Stack Trace:
    [    4.274510]   ext4_delete_entry+0x13e/0x234
    [    4.278695]   ext4_rmdir+0xe0/0x238
    [    4.282187]   vfs_rmdir+0x50/0xf0
    [    4.285492]   do_rmdir+0x9e/0x154
    [    4.288802]   EV_Trap+0x110/0x114
    
    The fix is to make sure slab allocations are 64-bit aligned.
    
    Do note that atomic64_t is __attribute__((aligned(8)) which means gcc
    does generate 64-bit aligned references, relative to beginning of
    container struct. However the issue is if the container itself is not
    64-bit aligned, atomic64_t ends up unaligned which is what this patch
    ensures.
    
    [1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf
    
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Cc: <stable@vger.kernel.org> # 4.8+
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    [vgupta: reworked changelog, added dependency on LL64+LLSC]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 075a1a664e180842087e20bf9c3b971debbc8000
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date:   Thu Feb 14 18:07:44 2019 +0300

    ARC: U-boot: check arguments paranoidly
    
    commit a66f2e57bd566240d8b3884eedf503928fbbe557 upstream.
    
    Handle U-boot arguments paranoidly:
     * don't allow to pass unknown tag.
     * try to use external device tree blob only if corresponding tag
       (TAG_DTB) is set.
     * don't check uboot_tag if kernel build with no ARC_UBOOT_SUPPORT.
    
    NOTE:
    If U-boot args are invalid we skip them and try to use embedded device
    tree blob. We can't panic on invalid U-boot args as we really pass
    invalid args due to bug in U-boot code.
    This happens if we don't provide external DTB to U-boot and
    don't set 'bootargs' U-boot environment variable (which is default
    case at least for HSDK board) In that case we will pass
    {r0 = 1 (bootargs in r2); r1 = 0; r2 = 0;} to linux which is invalid.
    
    While I'm at it refactor U-boot arguments handling code.
    
    Cc: stable@vger.kernel.org
    Tested-by: Corentin LABBE <clabbe@baylibre.com>
    Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de3bd3e1327f43b96434cca916b7d0af104d37f7
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date:   Wed Jan 16 14:29:50 2019 +0300

    ARCv2: Enable unaligned access in early ASM code
    
    commit 252f6e8eae909bc075a1b1e3b9efb095ae4c0b56 upstream.
    
    It is currently done in arc_init_IRQ() which might be too late
    considering gcc 7.3.1 onwards (GNU 2018.03) generates unaligned
    memory accesses by default
    
    Cc: stable@vger.kernel.org #4.4+
    Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    [vgupta: rewrote changelog]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 594b5b09ba0bb4d6b715f43b4b849935a827f27b
Author: Dmitry V. Levin <ldv@altlinux.org>
Date:   Sat Feb 16 16:10:39 2019 +0300

    parisc: Fix ptrace syscall number modification
    
    commit b7dc5a071ddf69c0350396b203cba32fe5bab510 upstream.
    
    Commit 910cd32e552e ("parisc: Fix and enable seccomp filter support")
    introduced a regression in ptrace-based syscall tampering: when tracer
    changes syscall number to -1, the kernel fails to initialize %r28 with
    -ENOSYS and subsequently fails to return the error code of the failed
    syscall to userspace.
    
    This erroneous behaviour could be observed with a simple strace syscall
    fault injection command which is expected to print something like this:
    
    $ strace -a0 -ewrite -einject=write:error=enospc echo hello
    write(1, "hello\n", 6) = -1 ENOSPC (No space left on device) (INJECTED)
    write(2, "echo: ", 6) = -1 ENOSPC (No space left on device) (INJECTED)
    write(2, "write error", 11) = -1 ENOSPC (No space left on device) (INJECTED)
    write(2, "\n", 1) = -1 ENOSPC (No space left on device) (INJECTED)
    +++ exited with 1 +++
    
    After commit 910cd32e552ea09caa89cdbe328e468979b030dd it loops printing
    something like this instead:
    
    write(1, "hello\n", 6../strace: Failed to tamper with process 12345: unexpectedly got no error (return value 0, error 0)
    ) = 0 (INJECTED)
    
    This bug was found by strace test suite.
    
    Fixes: 910cd32e552e ("parisc: Fix and enable seccomp filter support")
    Cc: stable@vger.kernel.org # v4.5+
    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
    Tested-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1854d8ef67703995cf9ca8fc1ae965d2549d1996
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Tue Feb 19 17:51:14 2019 +0100

    clk: at91: fix at91sam9x5 peripheral clock number
    
    commit 1b328a2e095a009518ebac05e937cc0fc242fede upstream.
    
    nck() looks at the last id in an array and unfortunately,
    at91sam9x35_periphck has a sentinel, hence the id is 0 and the calculated
    number of peripheral clocks is 1 instead of a maximum of 31.
    
    Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver")
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Cc: <stable@vger.kernel.org> # v4.20+
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15ff5c78f03b1bebe3f86298345cf601a0d9b04f
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Fri Feb 8 15:40:59 2019 +0100

    clk: at91: fix masterck name
    
    commit 65a91e2e597dea62a798a8b771edc44859037e7f upstream.
    
    The master clock is actually named masterck earlier in the driver. Having
    "mck" in the parent list means that it can never be selected.
    
    Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver")
    Fixes: a2038077de9a ("clk: at91: add sama5d2 PMC driver")
    Fixes: 084b696bb509 ("clk: at91: add sama5d4 pmc driver")
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Cc: <stable@vger.kernel.org> # v4.20+
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b08addb4476532054aee5cdc721a60360bb8cf9
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Feb 22 15:36:18 2019 +0000

    KEYS: always initialize keyring_index_key::desc_len
    
    commit ede0fa98a900e657d1fcd80b50920efc896c1a4c upstream.
    
    syzbot hit the 'BUG_ON(index_key->desc_len == 0);' in __key_link_begin()
    called from construct_alloc_key() during sys_request_key(), because the
    length of the key description was never calculated.
    
    The problem is that we rely on ->desc_len being initialized by
    search_process_keyrings(), specifically by search_nested_keyrings().
    But, if the process isn't subscribed to any keyrings that never happens.
    
    Fix it by always initializing keyring_index_key::desc_len as soon as the
    description is set, like we already do in some places.
    
    The following program reproduces the BUG_ON() when it's run as root and
    no session keyring has been installed.  If it doesn't work, try removing
    pam_keyinit.so from /etc/pam.d/login and rebooting.
    
        #include <stdlib.h>
        #include <unistd.h>
        #include <keyutils.h>
    
        int main(void)
        {
                int id = add_key("keyring", "syz", NULL, 0, KEY_SPEC_USER_KEYRING);
    
                keyctl_setperm(id, KEY_OTH_WRITE);
                setreuid(5000, 5000);
                request_key("user", "desc", "", id);
        }
    
    Reported-by: syzbot+ec24e95ea483de0a24da@syzkaller.appspotmail.com
    Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: James Morris <james.morris@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfc7fbe679813c4e4f77fac11bf8b4392205d808
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Feb 20 13:32:11 2019 +0000

    KEYS: user: Align the payload buffer
    
    commit cc1780fc42c76c705dd07ea123f1143dc5057630 upstream.
    
    Align the payload of "user" and "logon" keys so that users of the
    keyrings service can access it as a struct that requires more than
    2-byte alignment.  fscrypt currently does this which results in the read
    of fscrypt_key::size being misaligned as it needs 4-byte alignment.
    
    Align to __alignof__(u64) rather than __alignof__(long) since in the
    future it's conceivable that people would use structs beginning with
    u64, which on some platforms would require more than 'long' alignment.
    
    Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Fixes: 2aa349f6e37c ("[PATCH] Keys: Export user-defined keyring operations")
    Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: James Morris <james.morris@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2258993b48bfbcea8fef547f83f45a77b395ea57
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Jan 30 14:05:55 2019 -0800

    RDMA/srp: Rework SCSI device reset handling
    
    commit 48396e80fb6526ea5ed267bd84f028bae56d2f9e upstream.
    
    Since .scsi_done() must only be called after scsi_queue_rq() has
    finished, make sure that the SRP initiator driver does not call
    .scsi_done() while scsi_queue_rq() is in progress. Although
    invoking sg_reset -d while I/O is in progress works fine with kernel
    v4.20 and before, that is not the case with kernel v5.0-rc1. This
    patch avoids that the following crash is triggered with kernel
    v5.0-rc1:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000138
    CPU: 0 PID: 360 Comm: kworker/0:1H Tainted: G    B             5.0.0-rc1-dbg+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
    Workqueue: kblockd blk_mq_run_work_fn
    RIP: 0010:blk_mq_dispatch_rq_list+0x116/0xb10
    Call Trace:
     blk_mq_sched_dispatch_requests+0x2f7/0x300
     __blk_mq_run_hw_queue+0xd6/0x180
     blk_mq_run_work_fn+0x27/0x30
     process_one_work+0x4f1/0xa20
     worker_thread+0x67/0x5b0
     kthread+0x1cf/0x1f0
     ret_from_fork+0x24/0x30
    
    Cc: <stable@vger.kernel.org>
    Fixes: 94a9174c630c ("IB/srp: reduce lock coverage of command completion")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85b8532e8151a917eac4111601e9242a7038ebdd
Author: Masato Suzuki <masato.suzuki@wdc.com>
Date:   Thu Feb 14 15:01:18 2019 +0900

    scsi: sd_zbc: Fix sd_zbc_report_zones() buffer allocation
    
    commit 515ce60613128be7a176a8b82b20c7624f3b440d upstream.
    
    The function sd_zbc_do_report_zones() issues a REPORT ZONES command with a
    buffer size calculated based on the number of zones requested by the
    caller. This value should however not exceed the capabilities of the
    hardware maximum command size, that is, should not exceed the
    max_hw_sectors limit of the device. This problem leads to failures of
    report zones commands when re-validating disks with some SAS HBAs.
    
    Fix this by limiting a report zone command buffer size to the minimum of
    the device max_hw_sectors and calculated value based on the requested
    number of zones. This does not change the semantic of the report_zones file
    operation as report zones can always return less zone reports than
    requested. Short reports are handled using a loop execution of the
    report_zones file operation in the function blk_report_zones().
    
    [Damien]
    Before patch 'e76239a3748c ("block: add a report_zones method")', report
    zones buffer allocation was limited to max_sectors when allocated in
    blk_report_zones(). This however does not consider the actual format of the
    device reply which is interface dependent.  Limiting the allocation based
    on the size of the expected reply format rather than the size of the array
    of generic sturct blkzone passed by blk_report_zones() makes more sense.
    
    Fixes: e76239a3748c ("block: add a report_zones method")
    Cc: stable@vger.kernel.org
    Signed-off-by: Masato Suzuki <masato.suzuki@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9622d9fbbbed9080d2eea750306fdd4febf0732f
Author: Saeed Mahameed <saeedm@mellanox.com>
Date:   Mon Feb 11 16:27:02 2019 -0800

    net/mlx5e: XDP, fix redirect resources availability check
    
    [ Upstream commit 407e17b1a69a51ba9a512a04342da56c1f931df4 ]
    
    Currently mlx5 driver creates xdp redirect hw queues unconditionally on
    netdevice open, This is great until someone starts redirecting XDP traffic
    via ndo_xdp_xmit on mlx5 device and changes the device configuration at
    the same time, this might cause crashes, since the other device's napi
    is not aware of the mlx5 state change (resources un-availability).
    
    To fix this we must synchronize with other devices napi's on the system.
    Added a new flag under mlx5e_priv to determine XDP TX resources are
    available, set/clear it up when necessary and use synchronize_rcu()
    when the flag is turned off, so other napi's are in-sync with it, before
    we actually cleanup the hw resources.
    
    The flag is tested prior to committing to transmit on mlx5e_xdp_xmit, and
    it is sufficient to determine if it safe to transmit or not. The other
    two internal flags (MLX5E_STATE_OPENED and MLX5E_SQ_STATE_ENABLED) become
    unnecessary. Thus, they are removed from data path.
    
    Fixes: 58b99ee3e3eb ("net/mlx5e: Add support for XDP_REDIRECT in device-out side")
    Reported-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe20fb066e9eec175bb558aa6976bc046ff57e78
Author: Raed Salem <raeds@mellanox.com>
Date:   Mon Dec 17 11:40:06 2018 +0200

    net/mlx5e: FPGA, fix Innova IPsec TX offload data path performance
    
    [ Upstream commit 82eaa1fa0448da1852d7b80832e67e80a08dcc27 ]
    
    At Innova IPsec TX offload data path a special software parser metadata
    is used to pass some packet attributes to the hardware, this metadata
    is passed using the Ethernet control segment of a WQE (a HW descriptor)
    header.
    
    The cited commit might nullify this header, hence the metadata is lost,
    this caused a significant performance drop during hw offloading
    operation.
    
    Fix by restoring the metadata at the Ethernet control segment in case
    it was nullified.
    
    Fixes: 37fdffb217a4 ("net/mlx5: WQ, fixes for fragmented WQ buffers API")
    Signed-off-by: Raed Salem <raeds@mellanox.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0860fb3ace6ae4d7c5a776d38d60228ed2ea7548
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Feb 11 13:06:16 2019 -0800

    net_sched: fix two more memory leaks in cls_tcindex
    
    [ Upstream commit 1db817e75f5b9387b8db11e37d5f0624eb9223e0 ]
    
    struct tcindex_filter_result contains two parts:
    struct tcf_exts and struct tcf_result.
    
    For the local variable 'cr', its exts part is never used but
    initialized without being released properly on success path. So
    just completely remove the exts part to fix this leak.
    
    For the local variable 'new_filter_result', it is never properly
    released if not used by 'r' on success path.
    
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b386a4b2e449c548733fe1f538792607e814dc21
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Feb 11 13:06:15 2019 -0800

    net_sched: fix a memory leak in cls_tcindex
    
    [ Upstream commit 033b228e7f26b29ae37f8bfa1bc6b209a5365e9f ]
    
    When tcindex_destroy() destroys all the filter results in
    the perfect hash table, it invokes the walker to delete
    each of them. However, results with class==0 are skipped
    in either tcindex_walk() or tcindex_delete(), which causes
    a memory leak reported by kmemleak.
    
    This patch fixes it by skipping the walker and directly
    deleting these filter results so we don't miss any filter
    result.
    
    As a result of this change, we have to initialize exts->net
    properly in tcindex_alloc_perfect_hash(). For net-next, we
    need to consider whether we should initialize ->net in
    tcf_exts_init() instead, before that just directly test
    CONFIG_NET_CLS_ACT=y.
    
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bf6ec8eb026ba17d2e184d37eecdb8e9ddb8695
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Feb 11 13:06:14 2019 -0800

    net_sched: fix a race condition in tcindex_destroy()
    
    [ Upstream commit 8015d93ebd27484418d4952284fd02172fa4b0b2 ]
    
    tcindex_destroy() invokes tcindex_destroy_element() via
    a walker to delete each filter result in its perfect hash
    table, and tcindex_destroy_element() calls tcindex_delete()
    which schedules tcf RCU works to do the final deletion work.
    Unfortunately this races with the RCU callback
    __tcindex_destroy(), which could lead to use-after-free as
    reported by Adrian.
    
    Fix this by migrating this RCU callback to tcf RCU work too,
    as that workqueue is ordered, we will not have use-after-free.
    
    Note, we don't need to hold netns refcnt because we don't call
    tcf_exts_destroy() here.
    
    Fixes: 27ce4f05e2ab ("net_sched: use tcf_queue_work() in tcindex filter")
    Reported-by: Adrian <bugs@abtelecom.ro>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3875c3d6a36f841f6ef36dd09aae45b1a0a4aad8
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Feb 7 18:36:11 2019 +0800

    sit: check if IPv6 enabled before calling ip6_err_gen_icmpv6_unreach()
    
    [ Upstream commit 173656accaf583698bac3f9e269884ba60d51ef4 ]
    
    If we disabled IPv6 from the kernel command line (ipv6.disable=1), we should
    not call ip6_err_gen_icmpv6_unreach(). This:
    
      ip link add sit1 type sit local 192.0.2.1 remote 192.0.2.2 ttl 1
      ip link set sit1 up
      ip addr add 198.51.100.1/24 dev sit1
      ping 198.51.100.2
    
    if IPv6 is disabled at boot time, will crash the kernel.
    
    v2: there's no need to use in6_dev_get(), use __in6_dev_get() instead,
        as we only need to check that idev exists and we are under
        rcu_read_lock() (from netif_receive_skb_internal()).
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Fixes: ca15a078bd90 ("sit: generate icmpv6 error when receiving icmpv4 error")
    Cc: Oussama Ghorbel <ghorbel@pivasoftware.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7088034349aa4ddbd6b06b6ed3bdc52d4c08ced0
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Feb 7 18:36:10 2019 +0800

    geneve: should not call rt6_lookup() when ipv6 was disabled
    
    [ Upstream commit c0a47e44c0980b3b23ee31fa7936d70ea5dce491 ]
    
    When we add a new GENEVE device with IPv6 remote, checking only for
    IS_ENABLED(CONFIG_IPV6) is not enough as we may disable IPv6 in the
    kernel command line (ipv6.disable=1), and calling rt6_lookup() would
    cause a NULL pointer dereference.
    
    v2:
    - don't mix declarations and code (reported by Stefano Brivio, Eric Dumazet)
    - there's no need to use in6_dev_get() as we only need to check that
      idev exists (reported by David Ahern). This is under RTNL, so we can
      simply use __in6_dev_get() instead (Stefano, Eric).
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Fixes: c40e89fd358e9 ("geneve: configure MTU based on a lower device")
    Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f96ea091cd193c9ec7e4f480b9020d19ac085e7e
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 25 22:43:20 2019 +0100

    net: socket: make bond ioctls go through compat_ifreq_ioctl()
    
    [ Upstream commit 98406133dd9cb9f195676eab540c270dceca879a ]
    
    Same story as before, these use struct ifreq and thus need
    to be read with the shorter version to not cause faults.
    
    Cc: stable@vger.kernel.org
    Fixes: f92d4fc95341 ("kill bond_ioctl()")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10c7a022fe5041c10473eca479835a2170936c87
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 25 22:43:19 2019 +0100

    net: socket: fix SIOCGIFNAME in compat
    
    [ Upstream commit c6c9fee35dc27362b7bac34b2fc9f5b8ace2e22c ]
    
    As reported by Robert O'Callahan in
    https://bugzilla.kernel.org/show_bug.cgi?id=202273
    reverting the previous changes in this area broke
    the SIOCGIFNAME ioctl in compat again (I'd previously
    fixed it after his previous report of breakage in
    https://bugzilla.kernel.org/show_bug.cgi?id=199469).
    
    This is obviously because I fixed SIOCGIFNAME more or
    less by accident.
    
    Fix it explicitly now by making it pass through the
    restored compat translation code.
    
    Cc: stable@vger.kernel.org
    Fixes: 4cf808e7ac32 ("kill dev_ifname32()")
    Reported-by: Robert O'Callahan <robert@ocallahan.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06a3df441458c4bb3a3340fa579e315baa6836d9
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 25 22:43:18 2019 +0100

    Revert "kill dev_ifsioc()"
    
    [ Upstream commit 37ac39bdddc528c998a9f36db36937de923fdf2a ]
    
    This reverts commit bf4405737f9f ("kill dev_ifsioc()").
    
    This wasn't really unused as implied by the original commit,
    it still handles the copy to/from user differently, and the
    commit thus caused issues such as
      https://bugzilla.kernel.org/show_bug.cgi?id=199469
    and
      https://bugzilla.kernel.org/show_bug.cgi?id=202273
    
    However, deviating from a strict revert, rename dev_ifsioc()
    to compat_ifreq_ioctl() to be clearer as to its purpose and
    add a comment.
    
    Cc: stable@vger.kernel.org
    Fixes: bf4405737f9f ("kill dev_ifsioc()")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7b068e578055a409e07cbb93b670b01a762864c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 25 22:43:17 2019 +0100

    Revert "socket: fix struct ifreq size in compat ioctl"
    
    [ Upstream commit 63ff03ab786ab1bc6cca01d48eacd22c95b9b3eb ]
    
    This reverts commit 1cebf8f143c2 ("socket: fix struct ifreq
    size in compat ioctl"), it's a bugfix for another commit that
    I'll revert next.
    
    This is not a 'perfect' revert, I'm keeping some coding style
    intact rather than revert to the state with indentation errors.
    
    Cc: stable@vger.kernel.org
    Fixes: 1cebf8f143c2 ("socket: fix struct ifreq size in compat ioctl")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28f7d528b3f0588adbf2400bed8b9863bd43add1
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Mon Feb 18 14:30:11 2019 -0800

    net: dsa: Fix NPD checking for br_vlan_enabled()
    
    [ Upstream not applicable ]
    
    It is possible for the DSA slave network device not to be part of a
    bridge, yet have an upper device like a VLAN device be part of a bridge.
    When that VLAN device is enslaved, since it does not define any
    switchdev_ops, we will recurse down to the lower/physical port device,
    call switchdev_port_obj_add() with a VLAN, and here we will check
    br_vlan_enabled() on a NULL dp->bridge_dev, thus causing a NULL pointer
    de-reference.
    
    This is no longer a problem upstream after commit d17d9f5e5143
    ("switchdev: Replace port obj add/del SDO with a notification").
    
    Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
    Reported-by: Frank Wunderlich <frank-w@public-files.de>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 671f2db54520890943e337be15ca55772014d688
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Feb 11 21:59:51 2019 -0800

    team: avoid complex list operations in team_nl_cmd_options_set()
    
    [ Upstream commit 2fdeee2549231b1f989f011bb18191f5660d3745 ]
    
    The current opt_inst_list operations inside team_nl_cmd_options_set()
    is too complex to track:
    
        LIST_HEAD(opt_inst_list);
        nla_for_each_nested(...) {
            list_for_each_entry(opt_inst, &team->option_inst_list, list) {
                if (__team_option_inst_tmp_find(&opt_inst_list, opt_inst))
                    continue;
                list_add(&opt_inst->tmp_list, &opt_inst_list);
            }
        }
        team_nl_send_event_options_get(team, &opt_inst_list);
    
    as while we retrieve 'opt_inst' from team->option_inst_list, it could
    be added to the local 'opt_inst_list' for multiple times. The
    __team_option_inst_tmp_find() doesn't work, as the setter
    team_mode_option_set() still calls team->ops.exit() which uses
    ->tmp_list too in __team_options_change_check().
    
    Simplify the list operations by moving the 'opt_inst_list' and
    team_nl_send_event_options_get() into the nla_for_each_nested() loop so
    that it can be guranteed that we won't insert a same list entry for
    multiple times. Therefore, __team_option_inst_tmp_find() can be removed
    too.
    
    Fixes: 4fb0534fb7bb ("team: avoid adding twice the same option to the event list")
    Fixes: 2fcdb2c9e659 ("team: allow to send multiple set events in one message")
    Reported-by: syzbot+4d4af685432dc0e56c91@syzkaller.appspotmail.com
    Reported-by: syzbot+68ee510075cf64260cc4@syzkaller.appspotmail.com
    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Reviewed-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b050bf7ac6037bb0c908b490ffd7a9e024758637
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Feb 12 18:51:01 2019 +0800

    sctp: set stream ext to NULL after freeing it in sctp_stream_outq_migrate
    
    [ Upstream commit af98c5a78517c04adb5fd68bb64b1ad6fe3d473f ]
    
    In sctp_stream_init(), after sctp_stream_outq_migrate() freed the
    surplus streams' ext, but sctp_stream_alloc_out() returns -ENOMEM,
    stream->outcnt will not be set to 'outcnt'.
    
    With the bigger value on stream->outcnt, when closing the assoc and
    freeing its streams, the ext of those surplus streams will be freed
    again since those stream exts were not set to NULL after freeing in
    sctp_stream_outq_migrate(). Then the invalid-free issue reported by
    syzbot would be triggered.
    
    We fix it by simply setting them to NULL after freeing.
    
    Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
    Reported-by: syzbot+58e480e7b28f2d890bfd@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5802a5c5d8d4949814da3b3677cee55dcc5b89a6
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Feb 12 18:47:30 2019 +0800

    sctp: call gso_reset_checksum when computing checksum in sctp_gso_segment
    
    [ Upstream commit fc228abc2347e106a44c0e9b29ab70b712c4ca51 ]
    
    Jianlin reported a panic when running sctp gso over gre over vlan device:
    
      [   84.772930] RIP: 0010:do_csum+0x6d/0x170
      [   84.790605] Call Trace:
      [   84.791054]  csum_partial+0xd/0x20
      [   84.791657]  gre_gso_segment+0x2c3/0x390
      [   84.792364]  inet_gso_segment+0x161/0x3e0
      [   84.793071]  skb_mac_gso_segment+0xb8/0x120
      [   84.793846]  __skb_gso_segment+0x7e/0x180
      [   84.794581]  validate_xmit_skb+0x141/0x2e0
      [   84.795297]  __dev_queue_xmit+0x258/0x8f0
      [   84.795949]  ? eth_header+0x26/0xc0
      [   84.796581]  ip_finish_output2+0x196/0x430
      [   84.797295]  ? skb_gso_validate_network_len+0x11/0x80
      [   84.798183]  ? ip_finish_output+0x169/0x270
      [   84.798875]  ip_output+0x6c/0xe0
      [   84.799413]  ? ip_append_data.part.50+0xc0/0xc0
      [   84.800145]  iptunnel_xmit+0x144/0x1c0
      [   84.800814]  ip_tunnel_xmit+0x62d/0x930 [ip_tunnel]
      [   84.801699]  gre_tap_xmit+0xac/0xf0 [ip_gre]
      [   84.802395]  dev_hard_start_xmit+0xa5/0x210
      [   84.803086]  sch_direct_xmit+0x14f/0x340
      [   84.803733]  __dev_queue_xmit+0x799/0x8f0
      [   84.804472]  ip_finish_output2+0x2e0/0x430
      [   84.805255]  ? skb_gso_validate_network_len+0x11/0x80
      [   84.806154]  ip_output+0x6c/0xe0
      [   84.806721]  ? ip_append_data.part.50+0xc0/0xc0
      [   84.807516]  sctp_packet_transmit+0x716/0xa10 [sctp]
      [   84.808337]  sctp_outq_flush+0xd7/0x880 [sctp]
    
    It was caused by SKB_GSO_CB(skb)->csum_start not set in sctp_gso_segment.
    sctp_gso_segment() calls skb_segment() with 'feature | NETIF_F_HW_CSUM',
    which causes SKB_GSO_CB(skb)->csum_start not to be set in skb_segment().
    
    For TCP/UDP, when feature supports HW_CSUM, CHECKSUM_PARTIAL will be set
    and gso_reset_checksum will be called to set SKB_GSO_CB(skb)->csum_start.
    
    So SCTP should do the same as TCP/UDP, to call gso_reset_checksum() when
    computing checksum in sctp_gso_segment.
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73751cfa29c55fc24c254d20beed0f1bd91c8633
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Wed Feb 6 10:52:30 2019 +0000

    net: sfp: do not probe SFP module before we're attached
    
    [ Upstream commit b5bfc21af5cb3d53f9cee0ef82eaa43762a90f81 ]
    
    When we probe a SFP module, we expect to be able to call the upstream
    device's module_insert() function so that the upstream link can be
    configured.  However, when the upstream device is delayed, we currently
    may end up probing the module before the upstream device is available,
    and lose the module_insert() call.
    
    Avoid this by holding off probing the module until the SFP bus is
    properly connected to both the SFP socket driver and the upstream
    driver.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e75f0ed2d10e71823c198b105d780631b32cecfa
Author: Kal Conley <kal.conley@dectris.com>
Date:   Sun Feb 10 09:57:11 2019 +0100

    net/packet: fix 4gb buffer limit due to overflow check
    
    [ Upstream commit fc62814d690cf62189854464f4bd07457d5e9e50 ]
    
    When calculating rb->frames_per_block * req->tp_block_nr the result
    can overflow. Check it for overflow without limiting the total buffer
    size to UINT_MAX.
    
    This change fixes support for packet ring buffers >= UINT_MAX.
    
    Fixes: 8f8d28e4d6d8 ("net/packet: fix overflow in check for tp_frame_nr")
    Signed-off-by: Kal Conley <kal.conley@dectris.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad7770d240eb88e49e2542810f421786084d84d1
Author: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Date:   Mon Jan 28 15:28:06 2019 -0800

    net/mlx5e: Don't overwrite pedit action when multiple pedit used
    
    [ Upstream commit 218d05ce326f9e1b40a56085431fa1068b43d5d9 ]
    
    In some case, we may use multiple pedit actions to modify packets.
    The command shown as below: the last pedit action is effective.
    
    $ tc filter add dev netdev_rep parent ffff: protocol ip prio 1    \
            flower skip_sw ip_proto icmp dst_ip 3.3.3.3        \
            action pedit ex munge ip dst set 192.168.1.100 pipe    \
            action pedit ex munge eth src set 00:00:00:00:00:01 pipe    \
            action pedit ex munge eth dst set 00:00:00:00:00:02 pipe    \
            action csum ip pipe    \
            action tunnel_key set src_ip 1.1.1.100 dst_ip 1.1.1.200 dst_port 4789 id 100 \
            action mirred egress redirect dev vxlan0
    
    To fix it, we add max_mod_hdr_actions to mlx5e_tc_flow_parse_attr struction,
    max_mod_hdr_actions will store the max pedit action number we support and
    num_mod_hdr_actions indicates how many pedit action we used, and store all
    pedit action to mod_hdr_actions.
    
    Fixes: d79b6df6b10a ("net/mlx5e: Add parsing of TC pedit actions to HW format")
    Cc: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
    Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
    Acked-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9e5bd539fb532ce1ff48097cfe0befcf0dc079f
Author: Saeed Mahameed <saeedm@mellanox.com>
Date:   Mon Feb 11 18:04:17 2019 +0200

    net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames
    
    [ Upstream commit 29dded89e80e3fff61efb34f07a8a3fba3ea146d ]
    
    When an ethernet frame is padded to meet the minimum ethernet frame
    size, the padding octets are not covered by the hardware checksum.
    Fortunately the padding octets are usually zero's, which don't affect
    checksum. However, it is not guaranteed. For example, switches might
    choose to make other use of these octets.
    This repeatedly causes kernel hardware checksum fault.
    
    Prior to the cited commit below, skb checksum was forced to be
    CHECKSUM_NONE when padding is detected. After it, we need to keep
    skb->csum updated. However, fixing up CHECKSUM_COMPLETE requires to
    verify and parse IP headers, it does not worth the effort as the packets
    are so small that CHECKSUM_COMPLETE has no significant advantage.
    
    Future work: when reporting checksum complete is not an option for
    IP non-TCP/UDP packets, we can actually fallback to report checksum
    unnecessary, by looking at cqe IPOK bit.
    
    Fixes: 88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 729c41043f743a3380a89d46d1e41b302ffddd06
Author: Arthur Kiyanovski <akiyano@amazon.com>
Date:   Mon Feb 11 19:17:43 2019 +0200

    net: ena: fix race between link up and device initalization
    
    [ Upstream commit e1f1bd9bfbedcfce428ee7e1b82a6ec12d4c3863 ]
    
    Fix race condition between ena_update_on_link_change() and
    ena_restore_device().
    
    This race can occur if link notification arrives while the driver
    is performing a reset sequence. In this case link can be set up,
    enabling the device, before it is fully restored. If packets are
    sent at this time, the driver might access uninitialized data
    structures, causing kernel crash.
    
    Move the clearing of ENA_FLAG_ONGOING_RESET and netif_carrier_on()
    after ena_up() to ensure the device is ready when link is set up.
    
    Fixes: d18e4f683445 ("net: ena: fix race condition between device reset and link up setup")
    Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01965b35f903ca77544ded28e7e41dee2d786735
Author: Li RongQing <lirongqing@baidu.com>
Date:   Mon Feb 11 19:32:20 2019 +0800

    ipv6: propagate genlmsg_reply return code
    
    [ Upstream commit d1f20798a119be71746949ba9b2e2ff330fdc038 ]
    
    genlmsg_reply can fail, so propagate its return code
    
    Fixes: 915d7e5e593 ("ipv6: sr: add code base for control plane support of SR-IPv6")
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25b3f56a20fd73ad05769a192cad8b9a66e7e3d3
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Sat Feb 9 13:35:52 2019 +0300

    inet_diag: fix reporting cgroup classid and fallback to priority
    
    [ Upstream commit 1ec17dbd90f8b638f41ee650558609c1af63dfa0 ]
    
    Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
    extensions has only 8 bits. Thus extensions starting from DCTCPINFO
    cannot be requested directly. Some of them included into response
    unconditionally or hook into some of lower 8 bits.
    
    Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
    
    This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
    reservation, and documents behavior for other extensions.
    
    Also this patch adds fallback to reporting socket priority. This filed
    is more widely used for traffic classification because ipv4 sockets
    automatically maps TOS to priority and default qdisc pfifo_fast knows
    about that. But priority could be changed via setsockopt SO_PRIORITY so
    INET_DIAG_TOS isn't enough for predicting class.
    
    Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
    reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
    
    So, after this patch INET_DIAG_CLASS_ID will report socket priority
    for most common setup when net_cls isn't set and/or cgroup2 in use.
    
    Fixes: 0888e372c37f ("net: inet: diag: expose sockets cgroup classid")
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fa116e68c6151a1e78a0baeee1bc034472493ad
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Feb 11 14:41:22 2019 -0800

    batman-adv: fix uninit-value in batadv_interface_tx()
    
    [ Upstream commit 4ffcbfac60642f63ae3d80891f573ba7e94a265c ]
    
    KMSAN reported batadv_interface_tx() was possibly using a
    garbage value [1]
    
    batadv_get_vid() does have a pskb_may_pull() call
    but batadv_interface_tx() does not actually make sure
    this did not fail.
    
    [1]
    BUG: KMSAN: uninit-value in batadv_interface_tx+0x908/0x1e40 net/batman-adv/soft-interface.c:231
    CPU: 0 PID: 10006 Comm: syz-executor469 Not tainted 4.20.0-rc7+ #5
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x173/0x1d0 lib/dump_stack.c:113
     kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
     __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
     batadv_interface_tx+0x908/0x1e40 net/batman-adv/soft-interface.c:231
     __netdev_start_xmit include/linux/netdevice.h:4356 [inline]
     netdev_start_xmit include/linux/netdevice.h:4365 [inline]
     xmit_one net/core/dev.c:3257 [inline]
     dev_hard_start_xmit+0x607/0xc40 net/core/dev.c:3273
     __dev_queue_xmit+0x2e42/0x3bc0 net/core/dev.c:3843
     dev_queue_xmit+0x4b/0x60 net/core/dev.c:3876
     packet_snd net/packet/af_packet.c:2928 [inline]
     packet_sendmsg+0x8306/0x8f30 net/packet/af_packet.c:2953
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     __sys_sendto+0x8c4/0xac0 net/socket.c:1788
     __do_sys_sendto net/socket.c:1800 [inline]
     __se_sys_sendto+0x107/0x130 net/socket.c:1796
     __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x441889
    Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007ffdda6fd468 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000441889
    RDX: 000000000000000e RSI: 00000000200000c0 RDI: 0000000000000003
    RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000216 R12: 00007ffdda6fd4c0
    R13: 00007ffdda6fd4b0 R14: 0000000000000000 R15: 0000000000000000
    
    Uninit was created at:
     kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
     kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
     kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
     kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185
     slab_post_alloc_hook mm/slab.h:446 [inline]
     slab_alloc_node mm/slub.c:2759 [inline]
     __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383
     __kmalloc_reserve net/core/skbuff.c:137 [inline]
     __alloc_skb+0x309/0xa20 net/core/skbuff.c:205
     alloc_skb include/linux/skbuff.h:998 [inline]
     alloc_skb_with_frags+0x1c7/0xac0 net/core/skbuff.c:5220
     sock_alloc_send_pskb+0xafd/0x10e0 net/core/sock.c:2083
     packet_alloc_skb net/packet/af_packet.c:2781 [inline]
     packet_snd net/packet/af_packet.c:2872 [inline]
     packet_sendmsg+0x661a/0x8f30 net/packet/af_packet.c:2953
     sock_sendmsg_nosec net/socket.c:621 [inline]
     sock_sendmsg net/socket.c:631 [inline]
     __sys_sendto+0x8c4/0xac0 net/socket.c:1788
     __do_sys_sendto net/socket.c:1800 [inline]
     __se_sys_sendto+0x107/0x130 net/socket.c:1796
     __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc:     Marek Lindner <mareklindner@neomailbox.ch>
    Cc:     Simon Wunderlich <sw@simonwunderlich.de>
    Cc:     Antonio Quartulli <a@unstable.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dedb455c3bcaa72d84818084183a5b17d930a5c9
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Wed Jan 9 22:41:08 2019 -0700

    isdn: avm: Fix string plus integer warning from Clang
    
    [ Upstream commit 7afa81c55fca0cad589722cb4bce698b4803b0e1 ]
    
    A recent commit in Clang expanded the -Wstring-plus-int warning, showing
    some odd behavior in this file.
    
    drivers/isdn/hardware/avm/b1.c:426:30: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
                    cinfo->version[j] = "\0\0" + 1;
                                        ~~~~~~~^~~
    drivers/isdn/hardware/avm/b1.c:426:30: note: use array indexing to silence this warning
                    cinfo->version[j] = "\0\0" + 1;
                                               ^
                                        &      [  ]
    1 warning generated.
    
    This is equivalent to just "\0". Nick pointed out that it is smarter to
    use "" instead of "\0" because "" is used elsewhere in the kernel and
    can be deduplicated at the linking stage.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/309
    Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22b5eb84a8a2ac0fd35c81b0bda92d497f39083e
Author: Tariq Toukan <tariqt@mellanox.com>
Date:   Thu Nov 8 12:06:53 2018 +0200

    net/mlx5e: Fix wrong (zero) TX drop counter indication for representor
    
    [ Upstream commit 7fdc1adc52d3975740547a78c2df329bb207f15d ]
    
    For representors, the TX dropped counter is not folded from the
    per-ring counters. Fix it.
    
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e443f41edebeb9f44be02f7238a93f702639cc16
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Jan 17 16:15:09 2019 +0100

    bpf: pull in pkt_sched.h header for tooling to fix bpftool build
    
    [ Upstream commit ad6dd7a9c47ba587c0aba57f73737764cd31136f ]
    
    Dan reported that bpftool does not compile for him:
    
      $ make tools/bpf
        DESCEND  bpf
    
      Auto-detecting system features:
      ..                        libbfd: [ on  ]
      ..        disassembler-four-args: [ OFF ]
    
        DESCEND  bpftool
    
      Auto-detecting system features:
      ..                        libbfd: [ on  ]
      ..        disassembler-four-args: [ OFF ]
    
        CC       /opt/linux.git/tools/bpf/bpftool/net.o
      In file included from /opt/linux.git/tools/include/uapi/linux/pkt_cls.h:6:0,
                     from /opt/linux.git/tools/include/uapi/linux/tc_act/tc_bpf.h:14,
                     from net.c:13:
      net.c: In function 'show_dev_tc_bpf':
      net.c:164:21: error: 'TC_H_CLSACT' undeclared (first use in this function)
        handle = TC_H_MAKE(TC_H_CLSACT, TC_H_MIN_INGRESS);
      [...]
    
    Fix it by importing pkt_sched.h header copy into tooling
    infrastructure.
    
    Fixes: 49a249c38726 ("tools/bpftool: copy a few net uapi headers to tools directory")
    Fixes: f6f3bac08ff9 ("tools/bpf: bpftool: add net support")
    Reported-by: Dan Gilson <dan_gilson@yahoo.com>
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=202315
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2db7aeefb5152d99cf407cca0a8f1cc36c715cef
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Fri Jan 18 15:58:03 2019 +0000

    selftests: forwarding: Add a test case for externally learned FDB entries
    
    [ Upstream commit 479a2b761d61c04e2ae97325aa391a8a8c99c23e ]
    
    Test that externally learned FDB entries can roam, but not age out.
    
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Petr Machata <petrm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 134152e837bbfd663e71c57e0bac0f47bae00939
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Fri Jan 18 15:58:01 2019 +0000

    mlxsw: spectrum_switchdev: Do not treat static FDB entries as sticky
    
    [ Upstream commit 64254a2054611205798e6bde634639bc704573ac ]
    
    The driver currently treats static FDB entries as both static and
    sticky. This is incorrect and prevents such entries from being roamed to
    a different port via learning.
    
    Fix this by configuring static entries with ageing disabled and roaming
    enabled.
    
    In net-next we can add proper support for the newly introduced 'sticky'
    flag.
    
    Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Alexander Petrovskiy <alexpe@mellanox.com>
    Reviewed-by: Petr Machata <petrm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b248b716f07c7313bc5f64ced37fa7da664013b
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Fri Jan 18 15:58:00 2019 +0000

    net: bridge: Mark FDB entries that were added by user as such
    
    [ Upstream commit 710ae72877378e7cde611efd30fe90502a6e5b30 ]
    
    Externally learned entries can be added by a user or by a switch driver
    that is notifying the bridge driver about entries that were learned in
    hardware.
    
    In the first case, the entries are not marked with the 'added_by_user'
    flag, which causes switch drivers to ignore them and not offload them.
    
    The 'added_by_user' flag can be set on externally learned FDB entries
    based on the 'swdev_notify' parameter in br_fdb_external_learn_add(),
    which effectively means if the created / updated FDB entry was added by
    a user or not.
    
    Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Alexander Petrovskiy <alexpe@mellanox.com>
    Reviewed-by: Petr Machata <petrm@mellanox.com>
    Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
    Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Cc: bridge@lists.linux-foundation.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb07fe31e609406f85e788b4b71514953c3df1ce
Author: Nir Dotan <nird@mellanox.com>
Date:   Fri Jan 18 15:57:57 2019 +0000

    mlxsw: pci: Return error on PCI reset timeout
    
    [ Upstream commit 67c14cc9b35055264fc0efed00159a7de1819f1b ]
    
    Return an appropriate error in the case when the driver timeouts on waiting
    for firmware to go out of PCI reset.
    
    Fixes: 233fa44bd67a ("mlxsw: pci: Implement reset done check")
    Signed-off-by: Nir Dotan <nird@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e12b76892d7899677901add483f173b3b68b5685
Author: Madalin Bucur <madalin.bucur@nxp.com>
Date:   Thu Jan 17 11:42:27 2019 +0200

    dpaa_eth: NETIF_F_LLTX requires to do our own update of trans_start
    
    [ Upstream commit c6ddfb9a963f0cac0f7365acfc87f3f3b33a3b69 ]
    
    As txq_trans_update() only updates trans_start when the lock is held,
    trans_start does not get updated if NETIF_F_LLTX is declared.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a6ff44bac272c618e3c5956ceccc6528aa6b927
Author: Yuchung Cheng <ycheng@google.com>
Date:   Thu Jan 17 08:51:01 2019 -0800

    bpf: fix SO_MAX_PACING_RATE to support TCP internal pacing
    
    [ Upstream commit e224c390a6259c529f7b2a6bd215a087b3344f5c ]
    
    If sch_fq packet scheduler is not used, TCP can fallback to
    internal pacing, but this requires sk_pacing_status to
    be properly set.
    
    Fixes: 8c4b4c7e9ff0 ("bpf: Add setsockopt helper function to bpf")
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Lawrence Brakmo <brakmo@fb.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75412b414a7cd475dd4648f2777857ac8c844bb9
Author: Peter Oskolkov <posk@google.com>
Date:   Wed Jan 16 08:47:54 2019 -0800

    bpf: bpf_setsockopt: reset sock dst on SO_MARK changes
    
    [ Upstream commit f4924f24da8c7ef64195096817f3cde324091d97 ]
    
    In sock_setsockopt() (net/core/sock.h), when SO_MARK option is used
    to change sk_mark, sk_dst_reset(sk) is called. The same should be
    done in bpf_setsockopt().
    
    Fixes: 8c4b4c7e9ff0 ("bpf: Add setsockopt helper function to bpf")
    Reported-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: Peter Oskolkov <posk@google.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f63b43f1ad1078ce5fdd69148568641e702eba35
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Tue Dec 25 22:18:23 2018 -0600

    leds: lp5523: fix a missing check of return value of lp55xx_read
    
    [ Upstream commit 248b57015f35c94d4eae2fdd8c6febf5cd703900 ]
    
    When lp55xx_read() fails, "status" is an uninitialized variable and thus
    may contain random value; using it leads to undefined behaviors.
    
    The fix inserts a check for the return value of lp55xx_read: if it
    fails, returns with its error code.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5869471d51401e631b9869f0a6d769100650915f
Author: Cheng-Min Ao <tony_ao@wiwynn.com>
Date:   Mon Jan 7 14:29:32 2019 +0800

    hwmon: (tmp421) Correct the misspelling of the tmp442 compatible attribute in OF device ID table
    
    [ Upstream commit f422449b58548a41e98fc97b259a283718e527db ]
    
    Correct a typo in OF device ID table
    The last one should be 'ti,tmp442'
    
    Signed-off-by: Cheng-Min Ao <tony_ao@wiwynn.com>
    Signed-off-by: Yu-Hsiang Chen <matt_chen@wiwynn.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb756178b2e1a05344cdf30eea16e22a6881b8b1
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Jan 15 18:03:38 2019 +0000

    atm: he: fix sign-extension overflow on large shift
    
    [ Upstream commit cb12d72b27a6f41325ae23a11033cf5fedfa1b97 ]
    
    Shifting the 1 by exp by an int can lead to sign-extension overlow when
    exp is 31 since 1 is an signed int and sign-extending this result to an
    unsigned long long will set the upper 32 bits.  Fix this by shifting an
    unsigned long.
    
    Detected by cppcheck:
    (warning) Shifting signed 32-bit value by 31 bits is undefined behaviour
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de9db36fdbb5439f0012f92445113fbeaaca911f
Author: Stanislav Fomichev <sdf@google.com>
Date:   Wed Jan 16 14:03:17 2019 -0800

    selftests/bpf: retry tests that expect build-id
    
    [ Upstream commit f67ad87ab3120e82845521b18a2b99273a340308 ]
    
    While running test_progs in a loop I found out that I'm sometimes hitting
    "Didn't find expected build ID from the map" error.
    
    Looking at stack_map_get_build_id_offset() it seems that it is racy (by
    design) and can sometimes return BPF_STACK_BUILD_ID_IP (i.e. can't trylock
    current->mm->mmap_sem).
    
    Let's retry this test a single time.
    
    Fixes: 13790d1cc72c ("bpf: add selftest for stackmap with build_id in NMI context")
    Acked-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 537158331aff36514a64c0774d9f2789e58f93cd
Author: Stanislav Fomichev <sdf@google.com>
Date:   Wed Jan 16 14:03:16 2019 -0800

    bpf: zero out build_id for BPF_STACK_BUILD_ID_IP
    
    [ Upstream commit 4af396ae4836c4ecab61e975b8e61270c551894d ]
    
    When returning BPF_STACK_BUILD_ID_IP from stack_map_get_build_id_offset,
    make sure that build_id field is empty. Since we are using percpu
    free list, there is a possibility that we might reuse some previous
    bpf_stack_build_id with non-zero build_id.
    
    Fixes: 615755a77b24 ("bpf: extend stackmap to save binary_build_id+offset instead of address")
    Acked-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dfb08353cbb4e7330ff6c130dfa59ca6e8c1ffc
Author: Stanislav Fomichev <sdf@google.com>
Date:   Wed Jan 16 14:03:15 2019 -0800

    bpf: don't assume build-id length is always 20 bytes
    
    [ Upstream commit 0b698005a9d11c0e91141ec11a2c4918a129f703 ]
    
    Build-id length is not fixed to 20, it can be (`man ld` /--build-id):
      * 128-bit (uuid)
      * 160-bit (sha1)
      * any length specified in ld --build-id=0xhexstring
    
    To fix the issue of missing BPF_STACK_BUILD_ID_VALID for shorter build-ids,
    assume that build-id is somewhere in the range of 1 .. 20.
    Set the remaining bytes to zero.
    
    v2:
    * don't introduce new "len = min(BPF_BUILD_ID_SIZE, nhdr->n_descsz)",
      we already know that nhdr->n_descsz <= BPF_BUILD_ID_SIZE if we enter
      this 'if' condition
    
    Fixes: 615755a77b24 ("bpf: extend stackmap to save binary_build_id+offset instead of address")
    Acked-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 12a072a0b7ee5588966a090efb19b5824432f0a4
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jan 10 15:40:50 2019 +0000

    afs: Fix race in async call refcounting
    
    [ Upstream commit 34fa47612bfe5d7de7fcaf658a6952b6aeec3b13 ]
    
    There's a race between afs_make_call() and afs_wake_up_async_call() in the
    case that an error is returned from rxrpc_kernel_send_data() after it has
    queued the final packet.
    
    afs_make_call() will try and clean up the mess, but the call state may have
    been moved on thereby causing afs_process_async_call() to also try and to
    delete the call.
    
    Fix this by:
    
     (1) Getting an extra ref for an asynchronous call for the call itself to
         hold.  This makes sure the call doesn't evaporate on us accidentally
         and will allow the call to be retained by the caller in a future
         patch.  The ref is released on leaving afs_make_call() or
         afs_wait_for_call_to_complete().
    
     (2) In the event of an error from rxrpc_kernel_send_data():
    
         (a) Don't set the call state to AFS_CALL_COMPLETE until *after* the
             call has been aborted and ended.  This prevents
             afs_deliver_to_call() from doing anything with any notifications
             it gets.
    
         (b) Explicitly end the call immediately to prevent further callbacks.
    
         (c) Cancel any queued async_work and wait for the work if it's
             executing.  This allows us to be sure the race won't recur when we
             change the state.  We put the work queue's ref on the call if we
             managed to cancel it.
    
         (d) Put the call's ref that we got in (1).  This belongs to us as long
             as the call is in state AFS_CALL_CL_REQUESTING.
    
    Fixes: 341f741f04be ("afs: Refcount the afs_call struct")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 913dce0f061ba16e404fda58a00e5d91c310a634
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jan 10 15:14:29 2019 +0000

    afs: Provide a function to get a ref on a call
    
    [ Upstream commit 7a75b0079a1d54e342c502c3c8107ba97e05d3d3 ]
    
    Provide a function to get a reference on an afs_call struct.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d256a8100f73ea84d5adf9e48418e0cc6951acec
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jan 9 17:23:54 2019 +0000

    afs: Fix key refcounting in file locking code
    
    [ Upstream commit 59d49076ae3e6912e6d7df2fd68e2337f3d02036 ]
    
    Fix the refcounting of the authentication keys in the file locking code.
    The vnode->lock_key member points to a key on which it expects to be
    holding a ref, but it isn't always given an extra ref, however.
    
    Fixes: 0fafdc9f888b ("afs: Fix file locking")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a323053b6b684aef8c72ac41c758152ff401d503
Author: Marc Dionne <marc.dionne@auristor.com>
Date:   Wed Jan 9 17:23:54 2019 +0000

    afs: Don't set vnode->cb_s_break in afs_validate()
    
    [ Upstream commit 4882a27cec24319d10f95e978ecc80050e3e3e15 ]
    
    A cb_interest record is not necessarily attached to the vnode on entry to
    afs_validate(), which can cause an oops when we try to bring the vnode's
    cb_s_break up to date in the default case (ie. no current callback promise
    and the vnode has not been deleted).
    
    Fix this by simply removing the line, as vnode->cb_s_break will be set when
    needed by afs_register_server_cb_interest() when we next get a callback
    promise from RPC call.
    
    The oops looks something like:
    
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
        ...
        RIP: 0010:afs_validate+0x66/0x250 [kafs]
        ...
        Call Trace:
         afs_d_revalidate+0x8d/0x340 [kafs]
         ? __d_lookup+0x61/0x150
         lookup_dcache+0x44/0x70
         ? lookup_dcache+0x44/0x70
         __lookup_hash+0x24/0xa0
         do_unlinkat+0x11d/0x2c0
         __x64_sys_unlink+0x23/0x30
         do_syscall_64+0x4d/0xf0
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: ae3b7361dc0e ("afs: Fix validation/callback interaction")
    Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 923ea572c3801ccd575c32b9a504e4b51eed83ac
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Mon Jan 14 18:16:44 2019 +0100

    selftests: tc-testing: fix parsing of ife type
    
    [ Upstream commit 91fa038d9446b5bf5ea80822790af7dd9bcbb5a2 ]
    
    In iproute2 commit 90c5c969f0b9 ("fix print_0xhex on 32 bit"), the format
    specifier for the ife type changed from 0x%X to %#llX, causing systematic
    failures in the following TDC test cases:
    
     7682 - Create valid ife encode action with mark and pass control
     ef47 - Create valid ife encode action with mark and pipe control
     df43 - Create valid ife encode action with mark and continue control
     e4cf - Create valid ife encode action with mark and drop control
     ccba - Create valid ife encode action with mark and reclassify control
     a1cf - Create valid ife encode action with mark and jump control
     cb3d - Create valid ife encode action with mark value at 32-bit maximum
     95ed - Create valid ife encode action with prio and pass control
     aa17 - Create valid ife encode action with prio and pipe control
     74c7 - Create valid ife encode action with prio and continue control
     7a97 - Create valid ife encode action with prio and drop control
     f66b - Create valid ife encode action with prio and reclassify control
     3056 - Create valid ife encode action with prio and jump control
     7dd3 - Create valid ife encode action with prio value at 32-bit maximum
     05bb - Create valid ife encode action with tcindex and pass control
     ce65 - Create valid ife encode action with tcindex and pipe control
     09cd - Create valid ife encode action with tcindex and continue control
     8eb5 - Create valid ife encode action with tcindex and continue control
     451a - Create valid ife encode action with tcindex and drop control
     d76c - Create valid ife encode action with tcindex and reclassify control
     e731 - Create valid ife encode action with tcindex and jump control
     b7b8 - Create valid ife encode action with tcindex value at 16-bit maximum
     2a9c - Create valid ife encode action with mac src parameter
     cf5c - Create valid ife encode action with mac dst parameter
     2353 - Create valid ife encode action with mac src and mac dst parameters
     552c - Create valid ife encode action with mark and type parameters
     0421 - Create valid ife encode action with prio and type parameters
     4017 - Create valid ife encode action with tcindex and type parameters
     fac3 - Create valid ife encode action with index at 32-bit maximnum
     7c25 - Create valid ife decode action with pass control
     dccb - Create valid ife decode action with pipe control
     7bb9 - Create valid ife decode action with continue control
     d9ad - Create valid ife decode action with drop control
     219f - Create valid ife decode action with reclassify control
     8f44 - Create valid ife decode action with jump control
     b330 - Create ife encode action with cookie
    
    Change 'matchPattern' values, allowing '0' and '0x0' if ife type is equal
    to 0, and accepting both '0x' and '0X' otherwise, to let these tests pass
    both with old and new tc binaries.
    While at it, fix a small typo in test case fac3 ('maximnum'->'maximum').
    
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Acked-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3b0121e340ae6651d64d7953d13a6acd3c9f936
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Fri Jan 11 15:08:23 2019 +0100

    selftests: tc-testing: fix tunnel_key failure if dst_port is unspecified
    
    [ Upstream commit 5216bd77798e2ed773ecd45f3f368dcaec63e5dd ]
    
    After commit 1c25324caf82 ("net/sched: act_tunnel_key: Don't dump dst port
    if it wasn't set"), act_tunnel_key doesn't dump anymore the destination
    port, unless it was explicitly configured. This caused systematic failures
    in the following TDC test case:
    
     7a88 - Add tunnel_key action with cookie parameter
    
    Avoid matching zero values of TCA_TUNNEL_KEY_ENC_DST_PORT to let the test
    pass again.
    
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b08308ddfa5189c0b2a572fec5dcfc95f06c04fd
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Fri Jan 11 11:49:58 2019 +0100

    selftests: tc-testing: drop test on missing tunnel key id
    
    [ Upstream commit e413615502a3324daba038f529932ba9a5248af0 ]
    
    After merge of commit 80ef0f22ceda ("net/sched: act_tunnel_key: Allow
    key-less tunnels"), act_tunnel_key does not reject anymore requests to
    install 'set' rules where the key id is missing. Therefore, drop the
    following TDC testcase:
    
     ba4e - Add tunnel_key set action with missing mandatory id parameter
    
    because it's going to become a systematic fail as soon as userspace
    iproute2 will start supporting key-less tunnels.
    
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbae90516d2a5fd3c71d55a28bacc5f67625564d
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Thu Jan 10 20:22:26 2019 +0100

    net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ9031
    
    [ Upstream commit 1d16073a326891c2a964e4cb95bc18fbcafb5f74 ]
    
    So far genphy_soft_reset was used automatically if the PHY driver
    didn't implement the soft_reset callback. This changed with the
    mentioned commit and broke KSZ9031. To fix this configure the
    KSZ9031 PHY driver to use genphy_soft_reset.
    
    Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
    Reported-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Tested-by: Tony Lindgren <tony@atomide.com>
    Tested-by: Sekhar Nori <nsekhar@ti.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 278b3db146bbdcae9fc7621a34796a43a254d370
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jan 9 00:34:37 2019 +0100

    ACPI: EC: Look for ECDT EC after calling acpi_load_tables()
    
    [ Upstream commit b1c0330823fe842dbb34641f1410f0afa51c29d3 ]
    
    Some systems have had functional issues since commit 5a8361f7ecce
    (ACPICA: Integrate package handling with module-level code) that,
    among other things, changed the initial values of the
    acpi_gbl_group_module_level_code and acpi_gbl_parse_table_as_term_list
    global flags in ACPICA which implicitly caused acpi_ec_ecdt_probe() to
    be called before acpi_load_tables() on the vast majority of platforms.
    
    Namely, before commit 5a8361f7ecce, acpi_load_tables() was called from
    acpi_early_init() if acpi_gbl_parse_table_as_term_list was FALSE and
    acpi_gbl_group_module_level_code was TRUE, which almost always was
    the case as FALSE and TRUE were their initial values, respectively.
    The acpi_gbl_parse_table_as_term_list value would be changed to TRUE
    for a couple of platforms in acpi_quirks_dmi_table[], but it remained
    FALSE in the vast majority of cases.
    
    After commit 5a8361f7ecce, the initial values of the two flags have
    been reversed, so in effect acpi_load_tables() has not been called
    from acpi_early_init() any more.  That, in turn, affects
    acpi_ec_ecdt_probe() which is invoked before acpi_load_tables() now
    and it is not possible to evaluate the _REG method for the EC address
    space handler installed by it.  That effectively causes the EC address
    space to be inaccessible to AML on platforms with an ECDT matching the
    EC device definition in the DSDT and functional problems ensue in
    there.
    
    Because the default behavior before commit 5a8361f7ecce was to call
    acpi_ec_ecdt_probe() after acpi_load_tables(), it should be safe to
    do that again.  Moreover, the EC address space handler installed by
    acpi_ec_ecdt_probe() is only needed for AML to be able to access the
    EC address space and the only AML that can run during acpi_load_tables()
    is module-level code which only is allowed to access address spaces
    with default handlers (memory, I/O and PCI config space).
    
    For this reason, move the acpi_ec_ecdt_probe() invocation back to
    acpi_bus_init(), from where it was taken away by commit d737f333b211
    (ACPI: probe ECDT before loading AML tables regardless of module-level
    code flag), and put it after the invocation of acpi_load_tables() to
    restore the original code ordering from before commit 5a8361f7ecce.
    
    Fixes: 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199981
    Reported-by: step-ali <sunmooon15@gmail.com>
    Reported-by: Charles Stanhope <charles.stanhope@gmail.com>
    Tested-by: Charles Stanhope <charles.stanhope@gmail.com>
    Reported-by: Paulo Nascimento <paulo.ulusu@googlemail.com>
    Reported-by: David Purton <dcpurton@marshwiggle.net>
    Reported-by: Adam Harvey <adam@adamharvey.name>
    Reported-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Jean-Marc Lenoir <archlinux@jihemel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b94fcf1f7d33cafb57c83230770b62b3f83cc0f0
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Tue Jan 15 10:31:27 2019 +0800

    pvcalls-front: fix potential null dereference
    
    [ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
    
     static checker warning:
        drivers/xen/pvcalls-front.c:373 alloc_active_ring()
        error: we previously assumed 'map->active.ring' could be null
               (see line 357)
    
    drivers/xen/pvcalls-front.c
        351 static int alloc_active_ring(struct sock_mapping *map)
        352 {
        353     void *bytes;
        354
        355     map->active.ring = (struct pvcalls_data_intf *)
        356         get_zeroed_page(GFP_KERNEL);
        357     if (!map->active.ring)
                        ^^^^^^^^^^^^^^^^^
    Check
    
        358         goto out;
        359
        360     map->active.ring->ring_order = PVCALLS_RING_ORDER;
        361     bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
        362                     PVCALLS_RING_ORDER);
        363     if (!bytes)
        364         goto out;
        365
        366     map->active.data.in = bytes;
        367     map->active.data.out = bytes +
        368         XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
        369
        370     return 0;
        371
        372 out:
    --> 373     free_active_ring(map);
                                     ^^^
    Add null check on map->active.ring before dereferencing it to avoid
    any NULL pointer dereferences.
    
    Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under spinlock")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    CC: Juergen Gross <jgross@suse.com>
    CC: Stefano Stabellini <sstabellini@kernel.org>
    CC: Dan Carpenter <dan.carpenter@oracle.com>
    CC: xen-devel@lists.xenproject.org
    CC: linux-kernel@vger.kernel.org
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f06c5377dd3441df56b0e66af1f4a549ae74f5bc
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Jan 13 09:47:44 2019 +0100

    drm/sun4i: backend: add missing of_node_puts
    
    [ Upstream commit 4bb0e6d7258213d4893c2c876712fbba40e712fe ]
    
    The device node iterators perform an of_node_get on each
    iteration, so a jump out of the loop requires an of_node_put.
    
    Remote and port also have augmented reference counts, so drop them
    on each iteration and at the end of the function, respectively.
    Remote is only used for the address it contains, not for the
    contents of that address, so the reference count can be dropped
    immediately.
    
    The semantic patch that fixes the first part of this problem is
    as follows (http://coccinelle.lip6.fr):
    
    // <smpl>
    @@
    expression root,e;
    local idexpression child;
    iterator name for_each_child_of_node;
    @@
    
     for_each_available_child_of_node(root, child) {
       ... when != of_node_put(child)
           when != e = child
    +  of_node_put(child);
    ?  break;
       ...
    }
    ... when != child
    // </smpl>
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1547369264-24831-5-git-send-email-Julia.Lawall@lip6.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8e6105ed81ce21b213ecd649e50f7baee26c246
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Wed Jan 2 17:53:13 2019 -0500

    SUNRPC: Ensure we respect the RPCSEC_GSS sequence number limit
    
    [ Upstream commit 97b78ae96ba76f4ca2d8f5afee6a2e567ccb8f45 ]
    
    According to RFC2203, the RPCSEC_GSS sequence numbers are bounded to
    an upper limit of MAXSEQ = 0x80000000. Ensure that we handle that
    correctly.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a00fd241200e0d95dc49c2795bf1dee7d0cbba49
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Wed Jan 2 17:53:10 2019 -0500

    SUNRPC: Ensure rq_bytes_sent is reset before request transmission
    
    [ Upstream commit e66721f0436396f779291a29616858b76bfd9415 ]
    
    When we resend a request, ensure that the 'rq_bytes_sent' is reset
    to zero.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 217dd7c4ac598d6775092f21f13597d0db4d414f
Author: Yonghong Song <yhs@fb.com>
Date:   Sat Jan 12 15:04:30 2019 -0800

    samples/bpf: workaround clang asm goto compilation errors
    
    [ Upstream commit 6bf3bbe1f4d4cf405e3c2bf07bbdff56d3223ec8 ]
    
    x86 compilation has required asm goto support since 4.17.
    Since clang does not support asm goto, at 4.17,
    Commit b1ae32dbab50 ("x86/cpufeature: Guard asm_volatile_goto usage
    for BPF compilation") worked around the issue by permitting an
    alternative implementation without asm goto for clang.
    
    At 5.0, more asm goto usages appeared.
      [yhs@148 x86]$ egrep -r asm_volatile_goto
      include/asm/cpufeature.h:     asm_volatile_goto("1: jmp 6f\n"
      include/asm/jump_label.h:     asm_volatile_goto("1:"
      include/asm/jump_label.h:     asm_volatile_goto("1:"
      include/asm/rmwcc.h:  asm_volatile_goto (fullop "; j" #cc " %l[cc_label]"     \
      include/asm/uaccess.h:        asm_volatile_goto("\n"                          \
      include/asm/uaccess.h:        asm_volatile_goto("\n"                          \
      [yhs@148 x86]$
    
    Compiling samples/bpf directories, most bpf programs failed
    compilation with error messages like:
      In file included from /home/yhs/work/bpf-next/samples/bpf/xdp_sample_pkts_kern.c:2:
      In file included from /home/yhs/work/bpf-next/include/linux/ptrace.h:6:
      In file included from /home/yhs/work/bpf-next/include/linux/sched.h:15:
      In file included from /home/yhs/work/bpf-next/include/linux/sem.h:5:
      In file included from /home/yhs/work/bpf-next/include/uapi/linux/sem.h:5:
      In file included from /home/yhs/work/bpf-next/include/linux/ipc.h:9:
      In file included from /home/yhs/work/bpf-next/include/linux/refcount.h:72:
      /home/yhs/work/bpf-next/arch/x86/include/asm/refcount.h:70:9: error: 'asm goto' constructs are not supported yet
            return GEN_BINARY_SUFFIXED_RMWcc(LOCK_PREFIX "subl",
                   ^
      /home/yhs/work/bpf-next/arch/x86/include/asm/rmwcc.h:67:2: note: expanded from macro 'GEN_BINARY_SUFFIXED_RMWcc'
            __GEN_RMWcc(op " %[val], %[var]\n\t" suffix, var, cc,           \
            ^
      /home/yhs/work/bpf-next/arch/x86/include/asm/rmwcc.h:21:2: note: expanded from macro '__GEN_RMWcc'
            asm_volatile_goto (fullop "; j" #cc " %l[cc_label]"             \
            ^
      /home/yhs/work/bpf-next/include/linux/compiler_types.h:188:37: note: expanded from macro 'asm_volatile_goto'
      #define asm_volatile_goto(x...) asm goto(x)
    
    Most implementation does not even provide an alternative
    implementation. And it is also not practical to make changes
    for each call site.
    
    This patch workarounded the asm goto issue by redefining the macro like below:
      #define asm_volatile_goto(x...) asm volatile("invalid use of asm_volatile_goto")
    
    If asm_volatile_goto is not used by bpf programs, which is typically the case, nothing bad
    will happen. If asm_volatile_goto is used by bpf programs, which is incorrect, the compiler
    will issue an error since "invalid use of asm_volatile_goto" is not valid assembly codes.
    
    With this patch, all bpf programs under samples/bpf can pass compilation.
    
    Note that bpf programs under tools/testing/selftests/bpf/ compiled fine as
    they do not access kernel internal headers.
    
    Fixes: e769742d3584 ("Revert "x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs"")
    Fixes: 18fe58229d80 ("x86, asm: change the GEN_*_RMWcc() macros to not quote the condition")
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 492803a5dae6a1ddf417e8007f86ac457020a492
Author: Stanislav Fomichev <sdf@google.com>
Date:   Mon Jan 14 09:41:41 2019 -0800

    selftests/bpf: install with_tunnels.sh for test_flow_dissector.sh
    
    [ Upstream commit 1be72f29bfb98be27a95309f18b4ab5249967b59 ]
    
    test_flow_dissector.sh depends on both with_addr.sh and with_tunnels.sh
    However, we install only with_addr.sh.
    
    Add with_tunnels.sh to TEST_PROGS_EXTENDED to make sure it gets
    installed as well.
    
    Tested with: make TARGETS=bpf install INSTALL_PATH=$PWD/x
    
    Fixes: ef4ab8447aa26 ("selftests: bpf: install script with_addr.sh")
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 299cc6a2df403c54a0c155640221b6c58fb066cb
Author: Krzysztof Kazimierczak <krzysztof.kazimierczak@intel.com>
Date:   Thu Jan 10 20:29:02 2019 +0100

    xsk: Check if a queue exists during umem setup
    
    [ Upstream commit cc5b5d3565048ae57d14e5674a5fb085b2ab0193 ]
    
    In the xdp_umem_assign_dev() path, the xsk code does not
    check if a queue for which umem is to be created exists.
    It leads to a situation where umem is not assigned to any
    Tx/Rx queue of a netdevice, without notifying the stack
    about an error. This affects both XDP_SKB and XDP_DRV
    modes - in case of XDP_DRV_ZC, queue index is checked by
    the driver.
    
    This patch fixes xsk code, so that in both XDP_SKB and
    XDP_DRV mode of AF_XDP, an error is returned when requested
    queue index exceedes an existing maximum.
    
    Fixes: c9b47cc1fabca ("xsk: fix bug when trying to use both copy and zero-copy on one queue id")
    Reported-by: Jakub Spizewski <jakub.spizewski@intel.com>
    Signed-off-by: Krzysztof Kazimierczak <krzysztof.kazimierczak@intel.com>
    Acked-by: Björn Töpel <bjorn.topel@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 643bb331b53c89574df9d8ae85eff61e92a488ee
Author: Bijan Mottahedeh <bijan.mottahedeh@oracle.com>
Date:   Mon Dec 3 16:48:23 2018 -0800

    vhost/scsi: Use copy_to_iter() to send control queue response
    
    [ Upstream commit 8e5dadfe76cf2862ebf3e4f22adef29982df7766 ]
    
    Uses copy_to_iter() instead of __copy_to_user() in order to ensure we
    support arbitrary layouts and an input buffer split across iov entries.
    
    Fixes: 0d02dbd68c47b ("vhost/scsi: Respond to control queue operations")
    Signed-off-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a908828ed3c4cb681bf5d714de7b1fe05cda690
Author: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Date:   Thu Dec 13 17:53:50 2018 +0300

    vhost: return EINVAL if iovecs size does not match the message size
    
    [ Upstream commit 74ad7419489ddade8044e3c9ab064ad656520306 ]
    
    We've failed to copy and process vhost_iotlb_msg so let userspace at
    least know about it. For instance before these patch the code below runs
    without any error:
    
    int main()
    {
      struct vhost_msg msg;
      struct iovec iov;
      int fd;
    
      fd = open("/dev/vhost-net", O_RDWR);
      if (fd == -1) {
        perror("open");
        return 1;
      }
    
      iov.iov_base = &msg;
      iov.iov_len = sizeof(msg)-4;
    
      if (writev(fd, &iov,1) == -1) {
        perror("writev");
        return 1;
      }
    
      return 0;
    }
    
    Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffd480523b25688674b0f3872f3d15e1e4cf16bc
Author: Charlene Liu <charlene.liu@amd.com>
Date:   Wed Dec 12 18:09:16 2018 -0500

    drm/amd/display: fix PME notification not working in RV desktop
    
    [ Upstream commit 20300db4aec5ba5edf6f0ad6f7111a51fbea7e10 ]
    
    [Why]
    PPLIB not receive the PME when unplug.
    
    Signed-off-by: Charlene Liu <charlene.liu@amd.com>
    Reviewed-by: Chris Park <Chris.Park@amd.com>
    Acked-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b09cf73b1c72e1106f2a4ab7d1a2b20a4b52f48
Author: Felix Kuehling <Felix.Kuehling@amd.com>
Date:   Wed Jan 2 17:47:39 2019 -0500

    drm/amdkfd: Don't assign dGPUs to APU topology devices
    
    [ Upstream commit bbdf514fe5648566b0754476cbcb92ac3422dde2 ]
    
    dGPUs need their own topology devices. Don't assign them to APU topology
    devices with CPU cores.
    
    Bug: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/66
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Tested-by: Elias Konstantinidis <ekondis@gmail.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d719d77b5f4145cc3b5c6c452c0034fbff4c7d2
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Jan 13 10:44:51 2019 +0100

    drm/meson: add missing of_node_put
    
    [ Upstream commit f672b93e4a0a4947d2e1103ed8780e01e13eadb6 ]
    
    Add an of_node_put when the result of of_graph_get_remote_port_parent is
    not available.
    
    An of_node_put is also needed when meson_probe_remote completes.  This was
    present at the recursive call, but not in the call from meson_drv_probe.
    
    The semantic match that finds this problem is as follows
    (http://coccinelle.lip6.fr):
    
    // <smpl>
    @r exists@
    local idexpression e;
    expression x;
    @@
    e = of_graph_get_remote_port_parent(...);
    ... when != x = e
        when != true e == NULL
        when != of_node_put(e)
        when != of_fwnode_handle(e)
    (
    return e;
    |
    *return ...;
    )
    // </smpl>
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1547372691-28324-4-git-send-email-Julia.Lawall@lip6.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf000927d9943c975942644ee3b35e3bfcc414ec
Author: Talons Lee <xin.li@citrix.com>
Date:   Mon Dec 10 18:03:00 2018 +0800

    always clear the X2APIC_ENABLE bit for PV guest
    
    [ Upstream commit 5268c8f39e0efef81af2aaed160272d9eb507beb ]
    
    Commit e657fcc clears cpu capability bit instead of using fake cpuid
    value, the EXTD should always be off for PV guest without depending
    on cpuid value. So remove the cpuid check in xen_read_msr_safe() to
    always clear the X2APIC_ENABLE bit.
    
    Signed-off-by: Talons Lee <xin.li@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 506fde2c60d191896b2a7dd49b07918944b4cfd8
Author: Henry Yen <henry.yen@mediatek.com>
Date:   Mon Jan 14 17:59:43 2019 +0800

    netfilter: nft_flow_offload: fix checking method of conntrack helper
    
    [ Upstream commit 2314e879747e82896f51cce4488f6a00f3e1af7b ]
    
    This patch uses nfct_help() to detect whether an established connection
    needs conntrack helper instead of using test_bit(IPS_HELPER_BIT,
    &ct->status).
    
    The reason is that IPS_HELPER_BIT is only set when using explicit CT
    target.
    
    However, in the case that a device enables conntrack helper via command
    "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper", the status of
    IPS_HELPER_BIT will not present any change, and consequently it loses
    the checking ability in the context.
    
    Signed-off-by: Henry Yen <henry.yen@mediatek.com>
    Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
    Tested-by: John Crispin <john@phrozen.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9cc1744b35f6f5522d30216a8280d6612d9fe50
Author: Varun Prakash <varun@chelsio.com>
Date:   Thu Jan 10 23:29:28 2019 +0530

    scsi: cxgb4i: add wait_for_completion()
    
    [ Upstream commit 9e8f1c79831424d30c0e3df068be7f4a244157c9 ]
    
    In case of ->set_param() and ->bind_conn() cxgb4i driver does not wait for
    cmd completion, this can create race conditions, to avoid this add
    wait_for_completion().
    
    Signed-off-by: Varun Prakash <varun@chelsio.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6177c9549dadb896947897c3b0156803c50b6396
Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date:   Wed Jan 9 15:09:02 2019 +0100

    scsi: qla1280: set 64bit coherent mask
    
    [ Upstream commit 4a01ab60f55041b1ccc760e43258a5b3aeeca1bc ]
    
    After Commit 54aed4dd3526 ("MIPS: IP27: use dma_direct_ops") qla1280 driver
    failed on SGI IP27 machines with
    
    qla1280: QLA1040 found on PCI bus 0, dev 0
    qla1280 0000:00:00.0: enabling device (0006 -> 0007)
    qla1280: Failed to get request memory
    qla1280: probe of 0000:00:00.0 failed with error -12
    
    Reason is that SGI IP27 always generates 64bit DMA addresses and has no
    fallback mode for 32bit DMA addresses implemented. QLA1280 supports 64bit
    addressing for all DMA accesses so setting coherent mask to 64bit fixes the
    issue.
    
    Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49068142c23d63ae218cc8b0b9e1decbb6d85d50
Author: Avri Altman <avri.altman@wdc.com>
Date:   Thu Jan 10 13:31:26 2019 +0200

    scsi: ufs: Fix geometry descriptor size
    
    [ Upstream commit 9be9db9f78f52ef03ee90063730cb9d730e7032b ]
    
    Albeit we no longer rely on those hard-coded descriptor sizes, we still use
    them as our defaults, so better get it right. While adding its sysfs
    entries, we forgot to update the geometry descriptor size. It is 0x48
    according to UFS2.1, and wasn't changed in UFS3.0.
    
    [mkp: typo]
    
    Fixes: c720c091222e (scsi: ufs: sysfs: geometry descriptor)
    Signed-off-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d93b0225b9543b0d52408d2bd5edbad100dfb8ff
Author: Manish Rangankar <mrangankar@marvell.com>
Date:   Wed Jan 9 01:39:07 2019 -0800

    scsi: qedi: Add ep_state for login completion on un-reachable targets
    
    [ Upstream commit 34a2ce887668db9dda4b56e6f155c49ac13f3e54 ]
    
    When the driver finds invalid destination MAC for the first un-reachable
    target, and before completes the PATH_REQ operation, set new ep_state to
    OFFLDCONN_NONE so that as part of driver ep_poll mechanism, the upper
    open-iscsi layer is notified to complete the login process on the first
    un-reachable target and thus proceed login to other reachable targets.
    
    Signed-off-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef61da41628d05284a5dd25f3dd3965ef31cd738
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Mon Jan 7 22:19:34 2019 +0800

    scsi: ufs: Fix system suspend status
    
    [ Upstream commit ce9e7bce43526626f7cffe2e657953997870197e ]
    
    hba->is_sys_suspended is set after successful system suspend but
    not clear after successful system resume.
    
    According to current behavior, hba->is_sys_suspended will not be set if
    host is runtime-suspended but not system-suspended. Thus we shall aligh the
    same policy: clear this flag even if host remains runtime-suspended after
    ufshcd_system_resume is successfully returned.
    
    Simply fix this flag to correct host status logs.
    
    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: Sasha Levin <sashal@kernel.org>

commit 8771ff2745b6b489568c9b367d469ac9b36d76ed
Author: Xiubo Li <xiubli@redhat.com>
Date:   Fri Nov 23 09:15:30 2018 +0800

    scsi: tcmu: avoid cmd/qfull timers updated whenever a new cmd comes
    
    [ Upstream commit a94a2572b97744d3a35a1996df0e5cf6b2461a4a ]
    
    Currently there is one cmd timeout timer and one qfull timer for each udev,
    and whenever any new command is coming in we will update the cmd timer or
    qfull timer. For some corner cases the timers are always working only for
    the ringbuffer's and full queue's newest cmd. That's to say the timer won't
    be fired even if one cmd has been stuck for a very long time and the
    deadline is reached.
    
    This fix will keep the cmd/qfull timers to be pended for the oldest cmd in
    ringbuffer and full queue, and will update them with the next cmd's
    deadline only when the old cmd's deadline is reached or removed from the
    ringbuffer and full queue.
    
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Acked-by: Mike Christie <mchristi@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9d768d21762106f6cea94aaca2f61a1a9e77746
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Tue Jan 8 21:04:48 2019 +0800

    isdn: i4l: isdn_tty: Fix some concurrency double-free bugs
    
    [ Upstream commit 2ff33d6637393fe9348357285931811b76e1402f ]
    
    The functions isdn_tty_tiocmset() and isdn_tty_set_termios() may be
    concurrently executed.
    
    isdn_tty_tiocmset
      isdn_tty_modem_hup
        line 719: kfree(info->dtmf_state);
        line 721: kfree(info->silence_state);
        line 723: kfree(info->adpcms);
        line 725: kfree(info->adpcmr);
    
    isdn_tty_set_termios
      isdn_tty_modem_hup
        line 719: kfree(info->dtmf_state);
        line 721: kfree(info->silence_state);
        line 723: kfree(info->adpcms);
        line 725: kfree(info->adpcmr);
    
    Thus, some concurrency double-free bugs may occur.
    
    These possible bugs are found by a static tool written by myself and
    my manual code review.
    
    To fix these possible bugs, the mutex lock "modem_info_mutex" used in
    isdn_tty_tiocmset() is added in isdn_tty_set_termios().
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1a0292e16e4eab4956a602df89205a1ec65d682
Author: Jose Abreu <jose.abreu@synopsys.com>
Date:   Wed Jan 9 10:06:00 2019 +0100

    net: stmmac: Prevent RX starvation in stmmac_napi_poll()
    
    [ Upstream commit fa0be0a43f101888ac677dba31b590963eafeaa1 ]
    
    Currently, TX is given a budget which is consumed by stmmac_tx_clean()
    and stmmac_rx() is given the remaining non-consumed budget.
    
    This is wrong and in case we are sending a large number of packets this
    can starve RX because remaining budget will be low.
    
    Let's give always the same budget for RX and TX clean.
    
    While at it, check if we missed any interrupts while we were in NAPI
    callback by looking at DMA interrupt status.
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9621a111408c9265b5c22e1d8537a85c3360829
Author: Jose Abreu <jose.abreu@synopsys.com>
Date:   Wed Jan 9 10:05:59 2019 +0100

    net: stmmac: Fix the logic of checking if RX Watchdog must be enabled
    
    [ Upstream commit 3b5094665e273c4a2a99f7f5f16977c0f1e19095 ]
    
    RX Watchdog can be disabled by platform definitions but currently we are
    initializing the descriptors before checking if Watchdog must be
    disabled or not.
    
    Fix this by checking earlier if user wants Watchdog disabled or not.
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2727ee9acbfce8aed575842ceabcdcb951b09011
Author: Jose Abreu <jose.abreu@synopsys.com>
Date:   Wed Jan 9 10:05:58 2019 +0100

    net: stmmac: Check if CBS is supported before configuring
    
    [ Upstream commit 0650d4017f4d2eee67230a02285a7ae5204240c2 ]
    
    Check if CBS is currently supported before trying to configure it in HW.
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f125cb30c46559df53f2484dd526ad11a8d9ef90
Author: Jose Abreu <jose.abreu@synopsys.com>
Date:   Wed Jan 9 10:05:57 2019 +0100

    net: stmmac: dwxgmac2: Only clear interrupts that are active
    
    [ Upstream commit fcc509eb10ff4794641e6ad3082118287a750d0a ]
    
    In DMA interrupt handler we were clearing all interrupts status, even
    the ones that were not active. Fix this and only clear the active
    interrupts.
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b68cba89e11679736f959bd177e4bf120756701
Author: Jose Abreu <jose.abreu@synopsys.com>
Date:   Wed Jan 9 10:05:56 2019 +0100

    net: stmmac: Fix PCI module removal leak
    
    [ Upstream commit 6dea7e1881fd86b80da64e476ac398008daed857 ]
    
    Since commit b7d0f08e9129, the enable / disable of PCI device is not
    managed which will result in IO regions not being automatically unmapped.
    As regions continue mapped it is currently not possible to remove and
    then probe again the PCI module of stmmac.
    
    Fix this by manually unmapping regions on remove callback.
    
    Changes from v1:
    - Fix build error
    
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Fixes: b7d0f08e9129 ("net: stmmac: Fix WoL for PCI-based setups")
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26dcec00203f04797c135a5870c8bbc954669d83
Author: Tony Luck <tony.luck@intel.com>
Date:   Fri Jan 11 14:46:37 2019 -0800

    acpi/nfit: Fix race accessing memdev in nfit_get_smbios_id()
    
    [ Upstream commit 0919871ac37fdcf46c7657da0f1742efe096b399 ]
    
    Possible race accessing memdev structures after dropping the
    mutex. Dan Williams says this could race against another thread
    that is doing:
    
     # echo "ACPI0012:00" > /sys/bus/acpi/drivers/nfit/unbind
    
    Reported-by: Jane Chu <jane.chu@oracle.com>
    Fixes: 23222f8f8dce ("acpi, nfit: Add function to look up nvdimm...")
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 485db4ce0094125c99f8361095201cf1ec2bd7f5
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Wed Jan 9 20:30:07 2019 +0000

    powerpc/8xx: fix setting of pagetable for Abatron BDI debug tool.
    
    [ Upstream commit fb0bdec51a4901b7dd088de0a1e365e1b9f5cd21 ]
    
    Commit 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer
    dereference") moved the loading of r6 earlier in the code. As some
    functions are called inbetween, r6 needs to be loaded again with the
    address of swapper_pg_dir in order to set PTE pointers for
    the Abatron BDI.
    
    Fixes: 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer dereference")
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7a43c6539ddfa79ad9a163bfe81a1a6b46da5a6
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Thu Jan 10 08:15:45 2019 +0200

    RDMA/mthca: Clear QP objects during their allocation
    
    [ Upstream commit 9d9f59b4204bc41896c866b3e5856e5b416aa199 ]
    
    As part of audit process to update drivers to use rdma_restrack_add()
    ensure that QP objects is cleared before access. Such change fixes the
    crash observed with uninitialized non zero sgid attr accessed by
    ib_destroy_qp().
    
    CPU: 3 PID: 74 Comm: kworker/u16:1 Not tainted 4.19.10-300.fc29.x86_64
    Workqueue: ipoib_wq ipoib_cm_tx_reap [ib_ipoib]
    RIP: 0010:rdma_put_gid_attr+0x9/0x30 [ib_core]
    RSP: 0018:ffffb7ad819dbde8 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffff8d1bdf5a2e00 RCX: 0000000000002699
    RDX: 206c656e72656af8 RSI: ffff8d1bf7ae6160 RDI: 206c656e72656b20
    RBP: 0000000000000000 R08: 0000000000026160 R09: ffffffffc06b45bf
    R10: ffffe849887da000 R11: 0000000000000002 R12: ffff8d1be30cb400
    R13: ffff8d1bdf681800 R14: ffff8d1be2272400 R15: ffff8d1be30ca000
    FS:  0000000000000000(0000) GS:ffff8d1bf7ac0000(0000)
    knlGS:0000000000000000
    Trace:
     ib_destroy_qp+0xc9/0x240 [ib_core]
     ipoib_cm_tx_reap+0x1f9/0x4e0 [ib_ipoib]
     process_one_work+0x1a1/0x3a0
     worker_thread+0x30/0x380
     ? pwq_unbound_release_workfn+0xd0/0xd0
     kthread+0x112/0x130
     ? kthread_create_worker_on_cpu+0x70/0x70
     ret_from_fork+0x22/0x40
    
    Reported-by: Alexander Murashkin <AlexanderMurashkin@msn.com>
    Tested-by: Alexander Murashkin <AlexanderMurashkin@msn.com>
    Fixes: 1a1f460ff151 ("RDMA: Hold the sgid_attr inside the struct ib_ah/qp")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b08e8a0420b454bebe70f06d89acf3a24a4e249
Author: wenxu <wenxu@ucloud.cn>
Date:   Thu Jan 10 14:51:35 2019 +0800

    netfilter: nft_flow_offload: fix interaction with vrf slave device
    
    [ Upstream commit 10f4e765879e514e1ce7f52ed26603047af196e2 ]
    
    In the forward chain, the iif is changed from slave device to master vrf
    device. Thus, flow offload does not find a match on the lower slave
    device.
    
    This patch uses the cached route, ie. dst->dev, to update the iif and
    oif fields in the flow entry.
    
    After this patch, the following example works fine:
    
     # ip addr add dev eth0 1.1.1.1/24
     # ip addr add dev eth1 10.0.0.1/24
     # ip link add user1 type vrf table 1
     # ip l set user1 up
     # ip l set dev eth0 master user1
     # ip l set dev eth1 master user1
    
     # nft add table firewall
     # nft add flowtable f fb1 { hook ingress priority 0 \; devices = { eth0, eth1 } \; }
     # nft add chain f ftb-all {type filter hook forward priority 0 \; policy accept \; }
     # nft add rule f ftb-all ct zone 1 ip protocol tcp flow offload @fb1
     # nft add rule f ftb-all ct zone 1 ip protocol udp flow offload @fb1
    
    Signed-off-by: wenxu <wenxu@ucloud.cn>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e6241e85916d083eb3242770f3a98ce70baf5de
Author: Marc Dionne <marc.dionne@auristor.com>
Date:   Wed Jan 9 17:23:54 2019 +0000

    afs: Set correct lock type for the yfs CreateFile
    
    [ Upstream commit 5edc22cc1d33d6a88d175d25adc38d2a5cee134d ]
    
    A lock type of 0 is "LockRead", which makes the fileserver record an
    unintentional read lock on the new file.  This will cause problems
    later on if the file is the subject of locking operations.
    
    The correct default value should be -1 ("LockNone").
    
    Fix the operation marshalling code to set the value and provide an enum to
    symbolise the values whilst we're at it.
    
    Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client")
    Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4dc1ce0730408b45e84728982511e9ebc984d57
Author: Song Liu <songliubraving@fb.com>
Date:   Tue Jan 8 14:20:44 2019 -0800

    bpf: fix panic in stack_map_get_build_id() on i386 and arm32
    
    [ Upstream commit beaf3d1901f4ea46fbd5c9d857227d99751de469 ]
    
    As Naresh reported, test_stacktrace_build_id() causes panic on i386 and
    arm32 systems. This is caused by page_address() returns NULL in certain
    cases.
    
    This patch fixes this error by using kmap_atomic/kunmap_atomic instead
    of page_address.
    
    Fixes: 615755a77b24 (" bpf: extend stackmap to save binary_build_id+offset instead of address")
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5938484d91a71b13e64aecd8d94e72cd04408d0c
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Tue Jan 8 10:23:03 2019 +0100

    selftests: bpf: install files tcp_(server|client)*.py
    
    [ Upstream commit f98937c6bb73ae11717a15aec85c187d33ca5d34 ]
    
    When test_tcpbpf_user runs it complains that it can't find files
    tcp_server.py and tcp_client.py.
    
    Rework so that tcp_server.py and tcp_client.py gets installed, added them
    to the variable TEST_PROGS_EXTENDED.
    
    Fixes: d6d4f60c3a09 ("bpf: add selftest for tcpbpf")
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 757116d41b211499d189e9ed36755897ab3428e5
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Wed Dec 5 10:35:50 2018 +0800

    pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under spinlock
    
    [ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
    
    The problem is that we call this with a spin lock held.
    The call tree is:
    pvcalls_front_accept() holds bedata->socket_lock.
        -> create_active()
            -> __get_free_pages() uses GFP_KERNEL
    
    The create_active() function is only called from pvcalls_front_accept()
    with a spin_lock held, The allocation is not allowed to sleep and
    GFP_KERNEL is not sufficient.
    
    This issue was detected by using the Coccinelle software.
    
    v2: Add a function doing the allocations which is called
        outside the lock and passing the allocated data to
        create_active().
    
    v3: Use the matching deallocators i.e., free_page()
        and free_pages(), respectively.
    
    v4: It would be better to pre-populate map (struct sock_mapping),
        rather than introducing one more new struct.
    
    v5: Since allocating the data outside of this call it should also
        be freed outside, when create_active() fails.
        Move kzalloc(sizeof(*map2), GFP_ATOMIC) outside spinlock and
        use GFP_KERNEL instead.
    
    v6: Drop the superfluous calls.
    
    Suggested-by: Juergen Gross <jgross@suse.com>
    Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Suggested-by: Stefano Stabellini <sstabellini@kernel.org>
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>
    CC: Julia Lawall <julia.lawall@lip6.fr>
    CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    CC: Juergen Gross <jgross@suse.com>
    CC: Stefano Stabellini <sstabellini@kernel.org>
    CC: xen-devel@lists.xenproject.org
    CC: linux-kernel@vger.kernel.org
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f245e03909adc974255a0771cb310661ca34d35
Author: Yuchung Cheng <ycheng@google.com>
Date:   Tue Jan 8 18:12:24 2019 -0800

    bpf: correctly set initial window on active Fast Open sender
    
    [ Upstream commit 31aa6503a15ba00182ea6dbbf51afb63bf9e851d ]
    
    The existing BPF TCP initial congestion window (TCP_BPF_IW) does not
    to work on (active) Fast Open sender. This is because it changes the
    (initial) window only if data_segs_out is zero -- but data_segs_out
    is also incremented on SYN-data.  This patch fixes the issue by
    proerly accounting for SYN-data additionally.
    
    Fixes: fc7478103c84 ("bpf: Adds support for setting initial cwnd")
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Reviewed-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Lawrence Brakmo <brakmo@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 980a9e535be0d90e406d9dcfb3992a786ccba89e
Author: wenxu <wenxu@ucloud.cn>
Date:   Wed Jan 9 10:40:11 2019 +0800

    netfilter: nft_flow_offload: Fix reverse route lookup
    
    [ Upstream commit a799aea0988ea0d1b1f263e996fdad2f6133c680 ]
    
    Using the following example:
    
            client 1.1.1.7 ---> 2.2.2.7 which dnat to 10.0.0.7 server
    
    The first reply packet (ie. syn+ack) uses an incorrect destination
    address for the reverse route lookup since it uses:
    
            daddr = ct->tuplehash[!dir].tuple.dst.u3.ip;
    
    which is 2.2.2.7 in the scenario that is described above, while this
    should be:
    
            daddr = ct->tuplehash[dir].tuple.src.u3.ip;
    
    that is 10.0.0.7.
    
    Signed-off-by: wenxu <wenxu@ucloud.cn>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9089bfb00d62f8c8e5b866a27bc2fadfa42eea98
Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date:   Wed Jan 9 18:12:16 2019 +0100

    MIPS: jazz: fix 64bit build
    
    [ Upstream commit 41af167fbc0032f9d7562854f58114eaa9270336 ]
    
    64bit JAZZ builds failed with
    
      linux-next/arch/mips/jazz/jazzdma.c: In function `vdma_init`:
      /linux-next/arch/mips/jazz/jazzdma.c:77:30: error: implicit declaration
        of function `KSEG1ADDR`; did you mean `CKSEG1ADDR`?
        [-Werror=implicit-function-declaration]
        pgtbl = (VDMA_PGTBL_ENTRY *)KSEG1ADDR(pgtbl);
                                    ^~~~~~~~~
                                    CKSEG1ADDR
      /linux-next/arch/mips/jazz/jazzdma.c:77:10: error: cast to pointer from
        integer of different size [-Werror=int-to-pointer-cast]
        pgtbl = (VDMA_PGTBL_ENTRY *)KSEG1ADDR(pgtbl);
                ^
      In file included from /linux-next/arch/mips/include/asm/barrier.h:11:0,
                       from /linux-next/include/linux/compiler.h:248,
                       from /linux-next/include/linux/kernel.h:10,
                       from /linux-next/arch/mips/jazz/jazzdma.c:11:
      /linux-next/arch/mips/include/asm/addrspace.h:41:29: error: cast from
        pointer to integer of different size [-Werror=pointer-to-int-cast]
       #define _ACAST32_  (_ATYPE_)(_ATYPE32_) /* widen if necessary */
                                   ^
      /linux-next/arch/mips/include/asm/addrspace.h:53:25: note: in
        expansion of macro `_ACAST32_`
       #define CPHYSADDR(a)  ((_ACAST32_(a)) & 0x1fffffff)
                               ^~~~~~~~~
      /linux-next/arch/mips/jazz/jazzdma.c:84:44: note: in expansion of
        macro `CPHYSADDR`
        r4030_write_reg32(JAZZ_R4030_TRSTBL_BASE, CPHYSADDR(pgtbl));
    
    Using correct casts and CKSEG1ADDR when dealing with the pgtbl setup
    fixes this.
    
    Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d30821837f84ad1bc7e4e9d2fb99562016e8604a
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Wed Jan 2 15:57:49 2019 -0500

    include/linux/compiler*.h: fix OPTIMIZER_HIDE_VAR
    
    [ Upstream commit 3e2ffd655cc6a694608d997738989ff5572a8266 ]
    
    Since commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
    mutually exclusive") clang no longer reuses the OPTIMIZER_HIDE_VAR macro
    from compiler-gcc - instead it gets the version in
    include/linux/compiler.h.  Unfortunately that version doesn't actually
    prevent compiler from optimizing out the variable.
    
    Fix up by moving the macro out from compiler-gcc.h to compiler.h.
    Compilers without incline asm support will keep working
    since it's protected by an ifdef.
    
    Also fix up comments to match reality since we are no longer overriding
    any macros.
    
    Build-tested with gcc and clang.
    
    Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive")
    Cc: Eli Friedman <efriedma@codeaurora.org>
    Cc: Joe Perches <joe@perches.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31369d8c9b480e8f30b09307cf4efe8bfb21b43a
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Tue Jan 8 13:50:43 2019 -0700

    scsi: isci: initialize shost fully before calling scsi_add_host()
    
    [ Upstream commit cc29a1b0a3f2597ce887d339222fa85b9307706d ]
    
    scsi_mq_setup_tags(), which is called by scsi_add_host(), calculates the
    command size to allocate based on the prot_capabilities. In the isci
    driver, scsi_host_set_prot() is called after scsi_add_host() so the command
    size gets calculated to be smaller than it needs to be.  Eventually,
    scsi_mq_init_request() locates the 'prot_sdb' after the command assuming it
    was sized correctly and a buffer overrun may occur.
    
    However, seeing blk_mq_alloc_rqs() rounds up to the nearest cache line
    size, the mistake can go unnoticed.
    
    The bug was noticed after the struct request size was reduced by commit
    9d037ad707ed ("block: remove req->timeout_list")
    
    Which likely reduced the allocated space for the request by an entire cache
    line, enough that the overflow could be hit and it caused a panic, on boot,
    at:
    
      RIP: 0010:t10_pi_complete+0x77/0x1c0
      Call Trace:
        <IRQ>
        sd_done+0xf5/0x340
        scsi_finish_command+0xc3/0x120
        blk_done_softirq+0x83/0xb0
        __do_softirq+0xa1/0x2e6
        irq_exit+0xbc/0xd0
        call_function_single_interrupt+0xf/0x20
        </IRQ>
    
    sd_done() would call scsi_prot_sg_count() which reads the number of
    entities in 'prot_sdb', but seeing 'prot_sdb' is located after the end of
    the allocated space it reads a garbage number and erroneously calls
    t10_pi_complete().
    
    To prevent this, the calls to scsi_host_set_prot() are moved into
    isci_host_alloc() before the call to scsi_add_host(). Out of caution, also
    move the similar call to scsi_host_set_guard().
    
    Fixes: 3d2d75254915 ("[SCSI] isci: T10 DIF support")
    Link: http://lkml.kernel.org/r/da851333-eadd-163a-8c78-e1f4ec5ec857@deltatee.com
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Cc: Intel SCU Linux support <intel-linux-scu@intel.com>
    Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8518f1c0bce5867339793a3f1a8d684f8b88377
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Dec 20 11:16:07 2018 +0800

    scsi: qla4xxx: check return code of qla4xxx_copy_from_fwddb_param
    
    [ Upstream commit 72b4a0465f995175a2e22cf4a636bf781f1f28a7 ]
    
    The return code should be check while qla4xxx_copy_from_fwddb_param fails.
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a9f0f05a546a83212c5a3d00f99910d2bb7bcfd
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Fri Jan 4 17:56:16 2019 +0900

    netfilter: nf_tables: fix leaking object reference count
    
    [ Upstream commit b91d9036883793122cf6575ca4dfbfbdd201a83d ]
    
    There is no code that decreases the reference count of stateful objects
    in error path of the nft_add_set_elem(). this causes a leak of reference
    count of stateful objects.
    
    Test commands:
       $nft add table ip filter
       $nft add counter ip filter c1
       $nft add map ip filter m1 { type ipv4_addr : counter \;}
       $nft add element ip filter m1 { 1 : c1 }
       $nft add element ip filter m1 { 1 : c1 }
       $nft delete element ip filter m1 { 1 }
       $nft delete counter ip filter c1
    
    Result:
       Error: Could not process rule: Device or resource busy
       delete counter ip filter c1
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    At the second 'nft add element ip filter m1 { 1 : c1 }', the reference
    count of the 'c1' is increased then it tries to insert into the 'm1'. but
    the 'm1' already has same element so it returns -EEXIST.
    But it doesn't decrease the reference count of the 'c1' in the error path.
    Due to a leak of the reference count of the 'c1', the 'c1' can't be
    removed by 'nft delete counter ip filter c1'.
    
    Fixes: 8aeff920dcc9 ("netfilter: nf_tables: add stateful object reference to set elements")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00cbe365e99f82c253e198dd182cb896e7eb2786
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Tue Jan 8 16:48:14 2019 +0000

    selftests: forwarding: Add a test for VLAN deletion
    
    [ Upstream commit 4fabf3bf93a194c7fa5288da3e0af37e4b943cf3 ]
    
    Add a VLAN on a bridge port, delete it and make sure the PVID VLAN is
    not affected.
    
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 015e739ef2e87425f283546dcfd73006f8cd4309
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Tue Jan 8 16:48:06 2019 +0000

    mlxsw: spectrum: Add VXLAN dependency for spectrum
    
    [ Upstream commit 143a8e038ac599ca73c6354c8af6a8fdeee9fa7d ]
    
    When VXLAN is a loadable module, MLXSW_SPECTRUM must not be built-in:
    
    drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:2547: undefined
    reference to `vxlan_fdb_find_uc'
    
    Add Kconfig dependency to enforce usable configurations.
    
    Fixes: 1231e04f5bba ("mlxsw: spectrum_switchdev: Add support for VxLAN encapsulation")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: kbuild test robot <lkp@intel.com>
    Reviewed-by: Petr Machata <petrm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb0a1b448d1892a1c12cb89c5a829c5b6cfebc35
Author: Nir Dotan <nird@mellanox.com>
Date:   Tue Jan 8 16:48:03 2019 +0000

    mlxsw: spectrum_acl: Add cleanup after C-TCAM update error condition
    
    [ Upstream commit ff0db43cd6c530ff944773ccf48ece55d32d0c22 ]
    
    When writing to C-TCAM, mlxsw driver uses cregion->ops->entry_insert().
    In case of C-TCAM HW insertion error, the opposite action should take
    place.
    Add error handling case in which the C-TCAM region entry is removed, by
    calling cregion->ops->entry_remove().
    
    Fixes: a0a777b9409f ("mlxsw: spectrum_acl: Start using A-TCAM")
    Signed-off-by: Nir Dotan <nird@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd7db7c9727895a2fb77f0c44428f1b09432599b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Jan 5 16:06:48 2019 +0300

    xprtrdma: Double free in rpcrdma_sendctxs_create()
    
    [ Upstream commit 6e17f58c486d9554341f70aa5b63b8fbed07b3fa ]
    
    The clean up is handled by the caller, rpcrdma_buffer_create(), so this
    call to rpcrdma_sendctxs_destroy() leads to a double free.
    
    Fixes: ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32601a9ad85a0ee014e6f6b819627c2147976477
Author: Alban Bedel <albeu@free.fr>
Date:   Mon Jan 7 20:45:15 2019 +0100

    MIPS: ath79: Enable OF serial ports in the default config
    
    [ Upstream commit 565dc8a4f55e491935bfb04866068d21784ea9a4 ]
    
    CONFIG_SERIAL_OF_PLATFORM is needed to get a working console on the OF
    boards, enable it in the default config to get a working setup out of
    the box.
    
    Signed-off-by: Alban Bedel <albeu@free.fr>
    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 0320777820527b15491a1802d8f9e713753442cf
Author: Stephen Warren <swarren@nvidia.com>
Date:   Thu Jan 3 10:23:23 2019 -0700

    net/mlx4: Get rid of page operation after dma_alloc_coherent
    
    [ Upstream commit f65e192af35058e5c82da9e90871b472d24912bc ]
    
    This patch solves a crash at the time of mlx4 driver unload or system
    shutdown. The crash occurs because dma_alloc_coherent() returns one
    value in mlx4_alloc_icm_coherent(), but a different value is passed to
    dma_free_coherent() in mlx4_free_icm_coherent(). In turn this is because
    when allocated, that pointer is passed to sg_set_buf() to record it,
    then when freed it is re-calculated by calling
    lowmem_page_address(sg_page()) which returns a different value. Solve
    this by recording the value that dma_alloc_coherent() returns, and
    passing this to dma_free_coherent().
    
    This patch is roughly equivalent to commit 378efe798ecf ("RDMA/hns: Get
    rid of page operation after dma_alloc_coherent").
    
    Based-on-code-from: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16ca5ebd4402cc9b9027d02e5a7436d9d2544673
Author: NeilBrown <neil@brown.name>
Date:   Sun Dec 30 14:21:52 2018 +1100

    watchdog: mt7621_wdt/rt2880_wdt: Fix compilation problem
    
    [ Upstream commit 3aa8b8bbc142eeaac89891de584535ceb7fce405 ]
    
    These files need
       #include <linux/mod_devicetable.h>
    to compile correctly.
    
    Fixes: ac3167257b9f ("headers: separate linux/mod_devicetable.h from linux/platform_device.h")
    Signed-off-by: NeilBrown <neil@brown.name>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1f354ab8f8bce6148deb35ba740afb949c2a10b
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Dec 26 13:56:15 2018 -0800

    hwmon: (nct6775) Enable IO mapping for NCT6797D and NCT6798D
    
    [ Upstream commit 9de15c95a63f527c8f7a968cd95e6ec71fc6891d ]
    
    Similar to other recent chips from Nuvoton, IO mapping may be disabled
    by default. Enable it when instantiating the driver and after resume.
    
    Fixes: 0599682b826f ("hwmon: (nct6775) Add support for NCT6798D")
    Fixes: e41da286a2fd ("hwmon: (nct6775) Add support for NCT6797D")
    Reported-by: Michael Cook <mcook@mackal.net>
    Cc: Michael Cook <mcook@mackal.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2007eb5a0befd773681afc173972a52edef676ce
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Dec 26 07:34:31 2018 -0800

    hwmon: (nct6775) Fix chip ID for NCT6798D
    
    [ Upstream commit 264142bc70ec039e26d8f3b46a717e8037f59ca0 ]
    
    The chip ID is 0xd42[8-f], not 0xd45[8-f].
    
    Fixes: 0599682b826f ("hwmon: (nct6775) Add support for NCT6798D")
    Reported-by: Michael Cook <mcook@mackal.net>
    Cc: Michael Cook <mcook@mackal.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eee19d207866c5125986dd9876e7a2613ca37ed9
Author: Andrey Ignatov <rdna@fb.com>
Date:   Fri Jan 4 01:07:08 2019 -0800

    selftests/bpf: Test [::] -> [::1] rewrite in sys_sendmsg in test_sock_addr
    
    [ Upstream commit 976b4f3a4646fbf0d189caca25f91f82e4be4b5a ]
    
    Test that sys_sendmsg BPF hook doesn't break sys_sendmsg behaviour to
    rewrite destination IPv6 = [::] with [::1] (BSD'ism).
    
    Two test cases are added:
    
    1) User passes dst IPv6 = [::] and BPF_CGROUP_UDP6_SENDMSG program
       doesn't touch it.
    
    2) User passes dst IPv6 != [::], but BPF_CGROUP_UDP6_SENDMSG program
       rewrites it with [::].
    
    In both cases [::1] is used by sys_sendmsg code eventually and datagram
    is sent successfully for unconnected UDP socket.
    
    Example of relevant output:
      Test case: sendmsg6: set dst IP = [::] (BSD'ism) .. [PASS]
      Test case: sendmsg6: preserve dst IP = [::] (BSD'ism) .. [PASS]
    
    Signed-off-by: Andrey Ignatov <rdna@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad899a1be4a7b2f77450f322ee3fed7f7c3a32d4
Author: Andrey Ignatov <rdna@fb.com>
Date:   Fri Jan 4 01:07:07 2019 -0800

    bpf: Fix [::] -> [::1] rewrite in sys_sendmsg
    
    [ Upstream commit e8e36984080b55ac5e57bdb09a5b570f2fc8e963 ]
    
    sys_sendmsg has supported unspecified destination IPv6 (wildcard) for
    unconnected UDP sockets since 876c7f41. When [::] is passed by user as
    destination, sys_sendmsg rewrites it with [::1] to be consistent with
    BSD (see "BSD'ism" comment in the code).
    
    This didn't work when cgroup-bpf was enabled though since the rewrite
    [::] -> [::1] happened before passing control to cgroup-bpf block where
    fl6.daddr was updated with passed by user sockaddr_in6.sin6_addr (that
    might or might not be changed by BPF program). That way if user passed
    [::] as dst IPv6 it was first rewritten with [::1] by original code from
    876c7f41, but then rewritten back with [::] by cgroup-bpf block.
    
    It happened even when BPF_CGROUP_UDP6_SENDMSG program was not present
    (CONFIG_CGROUP_BPF=y was enough).
    
    The fix is to apply BSD'ism after cgroup-bpf block so that [::] is
    replaced with [::1] no matter where it came from: passed by user to
    sys_sendmsg or set by BPF_CGROUP_UDP6_SENDMSG program.
    
    Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg")
    Reported-by: Nitin Rawat <nitin.rawat@intel.com>
    Signed-off-by: Andrey Ignatov <rdna@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a8f94472dd7f596cd41c892b88b306283e15adf
Author: Peter Oskolkov <posk@google.com>
Date:   Fri Jan 4 09:43:08 2019 -0800

    selftests: net: fix/improve ip_defrag selftest
    
    [ Upstream commit 3271a4821882a64214acc1bd7b173900ec70c9bf ]
    
    Commit ade446403bfb ("net: ipv4: do not handle duplicate fragments as
    overlapping") changed IPv4 defragmentation so that duplicate fragments,
    as well as _some_ fragments completely covered by previously delivered
    fragments, do not lead to the whole frag queue being discarded. This
    makes the existing ip_defrag selftest flaky.
    
    This patch
    * makes sure that negative IPv4 defrag tests generate truly overlapping
      fragments that trigger defrag queue drops;
    * tests that duplicate IPv4 fragments do not trigger defrag queue drops;
    * makes a couple of minor tweaks to the test aimed at increasing its code
      coverage and reduce flakiness.
    
    Signed-off-by: Peter Oskolkov <posk@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40107f8b541744c5ff17ddc70f2439837e8af3fc
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Fri Jan 4 20:18:11 2019 +0800

    net: hns: Fix use after free identified by SLUB debug
    
    [ Upstream commit bb989501abcafa0de5f18b0ec0ec459b5b817908 ]
    
    When enable SLUB debug, than remove hns_enet_drv module, SLUB debug will
    identify a use after free bug:
    
    [134.189505] Unable to handle kernel paging request at virtual address
                    006b6b6b6b6b6b6b
    [134.197553] Mem abort info:
    [134.200381]   ESR = 0x96000004
    [134.203487]   Exception class = DABT (current EL), IL = 32 bits
    [134.209497]   SET = 0, FnV = 0
    [134.212596]   EA = 0, S1PTW = 0
    [134.215777] Data abort info:
    [134.218701]   ISV = 0, ISS = 0x00000004
    [134.222596]   CM = 0, WnR = 0
    [134.225606] [006b6b6b6b6b6b6b] address between user and kernel address ranges
    [134.232851] Internal error: Oops: 96000004 [#1] SMP
    [134.237798] CPU: 21 PID: 27834 Comm: rmmod Kdump: loaded Tainted: G
                    OE     4.19.5-1.2.34.aarch64 #1
    [134.247856] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58 10/24/2018
    [134.255181] pstate: 20000005 (nzCv daif -PAN -UAO)
    [134.260044] pc : hns_ae_put_handle+0x38/0x60
    [134.264372] lr : hns_ae_put_handle+0x24/0x60
    [134.268700] sp : ffff00001be93c50
    [134.272054] x29: ffff00001be93c50 x28: ffff802faaec8040
    [134.277442] x27: 0000000000000000 x26: 0000000000000000
    [134.282830] x25: 0000000056000000 x24: 0000000000000015
    [134.288284] x23: ffff0000096fe098 x22: ffff000001050070
    [134.293671] x21: ffff801fb3c044a0 x20: ffff80afb75ec098
    [134.303287] x19: ffff80afb75ec098 x18: 0000000000000000
    [134.312945] x17: 0000000000000000 x16: 0000000000000000
    [134.322517] x15: 0000000000000002 x14: 0000000000000000
    [134.332030] x13: dead000000000100 x12: ffff7e02bea3c988
    [134.341487] x11: ffff80affbee9e68 x10: 0000000000000000
    [134.351033] x9 : 6fffff8000008101 x8 : 0000000000000000
    [134.360569] x7 : dead000000000100 x6 : ffff000009579748
    [134.370059] x5 : 0000000000210d00 x4 : 0000000000000000
    [134.379550] x3 : 0000000000000001 x2 : 0000000000000000
    [134.388813] x1 : 6b6b6b6b6b6b6b6b x0 : 0000000000000000
    [134.397993] Process rmmod (pid: 27834, stack limit = 0x00000000d474b7fd)
    [134.408498] Call trace:
    [134.414611]  hns_ae_put_handle+0x38/0x60
    [134.422208]  hnae_put_handle+0xd4/0x108
    [134.429563]  hns_nic_dev_remove+0x60/0xc0 [hns_enet_drv]
    [134.438342]  platform_drv_remove+0x2c/0x70
    [134.445958]  device_release_driver_internal+0x174/0x208
    [134.454810]  driver_detach+0x70/0xd8
    [134.461913]  bus_remove_driver+0x64/0xe8
    [134.469396]  driver_unregister+0x34/0x60
    [134.476822]  platform_driver_unregister+0x20/0x30
    [134.485130]  hns_nic_dev_driver_exit+0x14/0x6e4 [hns_enet_drv]
    [134.494634]  __arm64_sys_delete_module+0x238/0x290
    
    struct hnae_handle is a member of struct hnae_vf_cb, so when vf_cb is
    freed, than use hnae_handle will cause use after free panic.
    
    This patch frees vf_cb after hnae_handle used.
    
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d43dd09f1ba877228038c3be66dd8e22451fc717
Author: Denis Bolotin <dbolotin@marvell.com>
Date:   Thu Jan 3 12:02:40 2019 +0200

    qed: Fix qed_ll2_post_rx_buffer_notify_fw() by adding a write memory barrier
    
    [ Upstream commit 46721c3d9e273aea880e9ff835b0e1271e1cd2fb ]
    
    Make sure chain element is updated before ringing the doorbell.
    
    Signed-off-by: Denis Bolotin <dbolotin@marvell.com>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92acaa684e073ded15e15aea19b0cbc3eaec5492
Author: Denis Bolotin <dbolotin@marvell.com>
Date:   Thu Jan 3 12:02:39 2019 +0200

    qed: Fix qed_chain_set_prod() for PBL chains with non power of 2 page count
    
    [ Upstream commit 2d533a9287f2011632977e87ce2783f4c689c984 ]
    
    In PBL chains with non power of 2 page count, the producer is not at the
    beginning of the chain when index is 0 after a wrap. Therefore, after the
    producer index wrap around, page index should be calculated more carefully.
    
    Signed-off-by: Denis Bolotin <dbolotin@marvell.com>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0962699ef1b00db360529776c9258ef22749e3bb
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Thu Jan 3 01:09:53 2019 +0800

    soc/fsl/qe: fix err handling of ucc_of_parse_tdm
    
    [ Upstream commit 8d68100ab4ad92560a16a68b72e068613ac4d573 ]
    
    Currently there are some issues with the ucc_of_parse_tdm function:
    1, a possible null pointer dereference in ucc_of_parse_tdm,
    detected by the semantic patch deref_null.cocci,
    with the following warning:
    drivers/soc/fsl/qe/qe_tdm.c:177:21-24: ERROR: pdev is NULL but dereferenced.
    2, dev gets modified, so in any case that devm_iounmap() will fail
    even when the new pdev is valid, because the iomap was done with a
     different pdev.
    3, there is no driver bind with the "fsl,t1040-qe-si" or
    "fsl,t1040-qe-siram" device. So allocating resources using devm_*()
    with these devices won't provide a cleanup path for these resources
    when the caller fails.
    
    This patch fixes them.
    
    Suggested-by: Li Yang <leoyang.li@nxp.com>
    Suggested-by: Christophe LEROY <christophe.leroy@c-s.fr>
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Reviewed-by: Peng Hao <peng.hao2@zte.com.cn>
    CC: Julia Lawall <julia.lawall@lip6.fr>
    CC: Zhao Qiang <qiang.zhao@nxp.com>
    CC: David S. Miller <davem@davemloft.net>
    CC: netdev@vger.kernel.org
    CC: linuxppc-dev@lists.ozlabs.org
    CC: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01cc87321d8638a37e703b84b5f3b6751b39f826
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Jan 4 06:03:40 2019 +0000

    xen/pvcalls: remove set but not used variable 'intf'
    
    [ Upstream commit 1f8ce09b36c41a026a37a24b20efa32000892a64 ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    drivers/xen/pvcalls-back.c: In function 'pvcalls_sk_state_change':
    drivers/xen/pvcalls-back.c:286:28: warning:
     variable 'intf' set but not used [-Wunused-but-set-variable]
    
    It not used since e6587cdbd732 ("pvcalls-back: set -ENOTCONN in
    pvcalls_conn_back_read")
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb4685b4d6affdad8ff0f1b28822ebb16e85a6fa
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Thu Dec 20 15:12:11 2018 -0600

    mfd: mc13xxx: Fix a missing check of a register-read failure
    
    [ Upstream commit 9e28989d41c0eab57ec0bb156617a8757406ff8a ]
    
    When mc13xxx_reg_read() fails, "old_adc0" is uninitialized and will
    contain random value. Further execution uses "old_adc0" even when
    mc13xxx_reg_read() fails.
    The fix checks the return value of mc13xxx_reg_read(), and exits
    the execution when it fails.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2588ebb662faeb611c4c5f16a61db126e200ac2f
Author: Keerthy <j-keerthy@ti.com>
Date:   Sun Dec 9 19:29:31 2018 +0530

    mfd: tps65218: Use devm_regmap_add_irq_chip and clean up error path in probe()
    
    [ Upstream commit 75d4c5e03c2ae9902ab521024b10291f6fc9515b ]
    
    Use devm_regmap_add_irq_chip and clean up error path in probe
    and also the remove function.
    
    Reported-by: Christian Hohnstaedt <Christian.Hohnstaedt@wago.com>
    Signed-off-by: Keerthy <j-keerthy@ti.com>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6779fb10758c4b1028ffe7bb167c1c92cc608089
Author: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Date:   Mon Dec 10 19:00:02 2018 +0100

    mfd: cros_ec_dev: Add missing mfd_remove_devices() call in remove
    
    [ Upstream commit 18e294ddafaeb80a1e2e10c9bd750a6cb8388d5b ]
    
    The driver adds different MFD child devices via mfd_add_devices() and
    hence it is required to call mfd_remove_devices() to remove MFD child
    devices.
    
    Fixes: 5e0115581bbc ("cros_ec: Move cros_ec_dev module to drivers/mfd")
    Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19bd1d5fe19cf4f78eadf38aa332aefa405787a5
Author: Oskari Lemmela <oskari@lemmela.net>
Date:   Sat Dec 8 19:58:47 2018 +0200

    mfd: axp20x: Add supported cells for AXP803
    
    [ Upstream commit ea90e7b47f0a8bd2fe14e9a88f523de7c67db90a ]
    
    Parts of the AXP803 are compatible with their counterparts on the AXP813.
    These include the GPIO, ADC, AC and battery power supplies.
    
    Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ae0ea548d2ad7a5362b6bf1e01f4f60ed995537
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Sat Dec 8 19:58:46 2018 +0200

    mfd: axp20x: Re-align MFD cell entries
    
    [ Upstream commit 753a8d083e085c6f552c7982749de4cc7c40e2ac ]
    
    In the axp20x driver, the various mfd_cell lists had varying amounts
    of indentation, sometimes even within the same list. For the axp288,
    there's no alignment at all.
    
    Re-align the right hand side of the assignments with the least amount
    of tabs possible. Also collapse the closing bracket and the opening
    bracket of the next entry onto the same line for the axp288, to be
    consistent with all the other mfd_cell lists.
    
    This patch is whitespace change only. No functionality is modified.
    
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06d439f33f73ba916f34a44426ee3af8e70ce6c6
Author: Oskari Lemmela <oskari@lemmela.net>
Date:   Tue Nov 20 19:52:10 2018 +0200

    mfd: axp20x: Add AC power supply cell for AXP813
    
    [ Upstream commit 4a19f9a65375ca9781b3ca9e810ece92edfc3e78 ]
    
    As axp20x-ac-power-supply now supports AXP813, add a cell for it.
    
    Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
    Reviewed-by: Quentin Schulz <quentin.schulz@bootlin.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71daae1123e7e90c54803fdc3bc521c7127c5880
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Wed Nov 28 10:04:22 2018 +0000

    mfd: wm5110: Add missing ASRC rate register
    
    [ Upstream commit 04c801c18ded421845324255e660147a6f58dcd6 ]
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e55c91f723a2e5454f58dca4f9e9e1dd1c70dee
Author: Jonathan Marek <jonathan@marek.ca>
Date:   Mon Nov 19 14:53:17 2018 -0500

    mfd: qcom_rpm: write fw_version to CTRL_REG
    
    [ Upstream commit 504e4175829c44328773b96ad9c538e4783a8d22 ]
    
    This is required as part of the initialization sequence on certain SoCs.
    
    If these registers are not initialized, the hardware can be unresponsive.
    This fixes the driver on apq8060 (HP TouchPad device).
    
    Signed-off-by: Jonathan Marek <jonathan@marek.ca>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a483e3b613dab6c83a49930b0cea2e41d965ee1
Author: Jean Delvare <jdelvare@suse.de>
Date:   Mon Nov 12 10:49:42 2018 +0100

    mfd: at91-usart: Add platform dependency
    
    [ Upstream commit 628f3dfe4c7b35bbe63ec194ca6da857b00b0083 ]
    
    It doesn't make sense to present option MFD_AT91_USART by default if
    not building an AT91 kernel, as the drivers which depend on it are
    not available.
    
    Fixes: 7d3aa342cef7 ("mfd: at91-usart: Add MFD driver for USART")
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad50bff2d73d73634eb80b2e8b7e6be86ec84d40
Author: Dien Pham <dien.pham.ry@renesas.com>
Date:   Wed Oct 3 15:58:41 2018 +0200

    mfd: bd9571mwv: Add volatile register to make DVFS work
    
    [ Upstream commit b0aff01e7aa6ad2d6998ef1323843212d1db8b04 ]
    
    Because BD9571MWV_DVFS_MONIVDAC is not defined in the volatile table,
    the physical register value is not updated by regmap and DVFS doesn't
    work as expected. Fix it!
    
    Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
    Signed-off-by: Dien Pham <dien.pham.ry@renesas.com>
    [wsa: rebase, add 'Fixes', reword commit message]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47fa7bbcdff832b6ba7874579f929f214ea98997
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Oct 25 15:43:44 2018 +0300

    mfd: ab8500-core: Return zero in get_register_interruptible()
    
    [ Upstream commit 10628e3ecf544fa2e4e24f8e112d95c37884dc98 ]
    
    This function is supposed to return zero on success or negative error
    codes on error.  Unfortunately, there is a bug so it sometimes returns
    non-zero, positive numbers on success.
    
    I noticed this bug during review and I can't test it.  It does appear
    that the return is sometimes propogated back to _regmap_read() where all
    non-zero returns are treated as failure so this may affect run time.
    
    Fixes: 47c1697508f2 ("mfd: Align ab8500 with the abx500 interface")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 940eea61b31f4f8cb942615e6aada08e2313d651
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Mon Oct 22 10:55:06 2018 +0800

    mfd: mt6397: Do not call irq_domain_remove if PMIC unsupported
    
    [ Upstream commit a177276aa098aa47a100d51a13eaaef029604b6d ]
    
    If the PMIC ID is unknown, the current code would call
    irq_domain_remove and panic, as pmic->irq_domain is only
    initialized by mt6397_irq_init.
    
    Return immediately with an error, if the chip ID is unsupported.
    
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ac1b9f1566416f17e8ab53e5cdca73a3c612125
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Wed Oct 17 17:56:28 2018 -0700

    mfd: db8500-prcmu: Fix some section annotations
    
    [ Upstream commit a3888f62fe66429fad3be7f2ba962e1e08c26fd6 ]
    
    When building the kernel with Clang, the following section mismatch
    warnings appear:
    
    WARNING: vmlinux.o(.text+0x7239cc): Section mismatch in reference from
    the function db8500_prcmu_probe() to the function
    .init.text:init_prcm_registers()
    The function db8500_prcmu_probe() references
    the function __init init_prcm_registers().
    This is often because db8500_prcmu_probe lacks a __init
    annotation or the annotation of init_prcm_registers is wrong.
    
    WARNING: vmlinux.o(.text+0x723e28): Section mismatch in reference from
    the function db8500_prcmu_probe() to the function
    .init.text:fw_project_name()
    The function db8500_prcmu_probe() references
    the function __init fw_project_name().
    This is often because db8500_prcmu_probe lacks a __init
    annotation or the annotation of fw_project_name is wrong.
    
    db8500_prcmu_probe should not be marked as __init so remove the __init
    annotation from fw_project_name and init_prcm_registers.
    
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8616c7675acfc5919d74890084ff401683f39656
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Wed Oct 17 10:13:23 2018 -0700

    mfd: twl-core: Fix section annotations on {,un}protect_pm_master
    
    [ Upstream commit 8838555089f0345b87f4277fe5a8dd647dc65589 ]
    
    When building the kernel with Clang, the following section mismatch
    warning appears:
    
    WARNING: vmlinux.o(.text+0x3d84a3b): Section mismatch in reference from
    the function twl_probe() to the function
    .init.text:unprotect_pm_master()
    The function twl_probe() references
    the function __init unprotect_pm_master().
    This is often because twl_probe lacks a __init
    annotation or the annotation of unprotect_pm_master is wrong.
    
    Remove the __init annotation on the *protect_pm_master functions so
    there is no more mismatch.
    
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f3cb66a39a8b1ad79992ba5451c563c04a29862
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Fri Dec 21 15:06:33 2018 -0800

    pvcalls-back: set -ENOTCONN in pvcalls_conn_back_read
    
    [ Upstream commit e6587cdbd732eacb4c7ce592ed46f7bbcefb655f ]
    
    When a connection is closing we receive on pvcalls_sk_state_change
    notification. Instead of setting the connection as closed immediately
    (-ENOTCONN), let's read one more time from it: pvcalls_conn_back_read
    will set the connection as closed when necessary.
    
    That way, we avoid races between pvcalls_sk_state_change and
    pvcalls_back_ioworker.
    
    Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39e3882c0c3643ff54de3d6e05e6bd29e3b3c067
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Fri Dec 21 15:06:31 2018 -0800

    pvcalls-front: properly allocate sk
    
    [ Upstream commit beee1fbe8f7d57d6ebaa5188f9f4db89c2077196 ]
    
    Don't use kzalloc: it ends up leaving sk->sk_prot not properly
    initialized. Use sk_alloc instead and define our own trivial struct
    proto.
    
    Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e809f42203383a4a3e2e28dc70c369e6ceaf11a5
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Fri Dec 21 15:06:30 2018 -0800

    pvcalls-front: don't try to free unallocated rings
    
    [ Upstream commit 96283f9a084e23d7cda2d3c5d1ffa6df6cf1ecec ]
    
    inflight_req_id is 0 when initialized. If inflight_req_id is 0, there is
    no accept_map to free. Fix the check in pvcalls_front_release.
    
    Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 303e67b40a1a32b1ef88b1e8f487ee1686ef7383
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Fri Dec 21 15:06:29 2018 -0800

    pvcalls-front: read all data before closing the connection
    
    [ Upstream commit b79470b64fa9266948d1ce8d825ced94c4f63293 ]
    
    When a connection is closing in_error is set to ENOTCONN. There could
    still be outstanding data on the ring left by the backend. Before
    closing the connection on the frontend side, drain the ring.
    
    Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9d871fe1000a041c11b484e10b58557d304d173
Author: Vignesh R <vigneshr@ti.com>
Date:   Mon Dec 3 13:31:17 2018 +0530

    mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cells
    
    [ Upstream commit b40ee006fe6a8a25093434e5d394128c356a48f3 ]
    
    Use PLATFORM_DEVID_AUTO to number mfd cells while registering, so that
    different instances are uniquely identified. This is required in order
    to support registering of multiple instances of same ti_am335x_tscadc IP.
    
    Signed-off-by: Vignesh R <vigneshr@ti.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38a462acd94bc6f615b7c73a282f857d8529fae4
Author: Heiko Stuebner <heiko.stuebner@bq.com>
Date:   Mon Nov 12 10:02:57 2018 +0100

    backlight: pwm_bl: Fix devicetree parsing with auto-generated brightness tables
    
    [ Upstream commit 61170ee9386888f1e6f7e9cc58e8d9a8c2a3c1dd ]
    
    Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly
    to human eye") made the parse-dt function return early when using an auto-
    generated brightness-table, but didn't take into account that some more
    settings were handled below the brightness handling, like power-on-delays
    and also setting the pdata enable-gpio to -EINVAL.
    
    This surfaces for example in the case of a backlight without any
    enable-gpio which then tries to use gpio-0 in error.
    
    Fix this by simply moving the trailing settings above the brightness
    handling.
    
    Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to human eye")
    Signed-off-by: Heiko Stuebner <heiko.stuebner@bq.com>
    Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5cd90dee69fca4dba6adfd4bd3d332a4b4f9960
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Feb 14 16:20:01 2019 +0000

    KEYS: allow reaching the keys quotas exactly
    
    commit a08bf91ce28ed3ae7b6fef35d843fef8dc8c2cd9 upstream.
    
    If the sysctl 'kernel.keys.maxkeys' is set to some number n, then
    actually users can only add up to 'n - 1' keys.  Likewise for
    'kernel.keys.maxbytes' and the root_* versions of these sysctls.  But
    these sysctls are apparently supposed to be *maximums*, as per their
    names and all documentation I could find -- the keyrings(7) man page,
    Documentation/security/keys/core.rst, and all the mentions of EDQUOT
    meaning that the key quota was *exceeded* (as opposed to reached).
    
    Thus, fix the code to allow reaching the quotas exactly.
    
    Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: James Morris <james.morris@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55dfa36e0cfabfa24e3c19f2d3942b1c11d68310
Author: Hui Wang <hui.wang@canonical.com>
Date:   Thu Feb 14 11:41:33 2019 +0800

    ALSA: hda/realtek: Disable PC beep in passthrough on alc285
    
    commit c8c6ee611926685a7d753409e0a6e48b9e1b8748 upstream.
    
    It is reported that there's a constant background "hum/whitenoise"
    in the headset on the Lenovo X1 machines with the codec alc285, and it
    is confirmed that if we run the command below, the noise will stop.
     sudo hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0x0
    
    Then I consulted this issue with Kailang, he told me the pin 0x1d on
    this codec is used for PC beep in, the noise probably comes from this
    pin and we can also disable the PC beep in passthrough, then the PC
    beep in will not affect other sound playback.
    
    Fixes: c4cfcf6f4297 ("ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops")
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1660581
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f07c9e67c6ef9ffb1139e03ef2e844d4780358
Author: Jeremy Soller <jeremy@system76.com>
Date:   Wed Feb 13 10:56:19 2019 -0700

    ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5
    
    commit 7f665b1c3283aae5b61843136d0a8ee808ba3199 upstream.
    
    On the System76 Oryx Pro (oryp5), there is a headset microphone input
    attached to 0x19 that does not have a jack detect. In order to get it
    working, the pin configuration needs to be set correctly, and the
    ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied. This is
    similar to the MIC_NO_PRESENCE fixups for some Dell laptops, except we
    have a separate microphone jack that is already configured correctly.
    
    Since the ALC1220 does not have a fixup similar to
    ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC, I have exposed the fixup from the
    ALC269 in a way that it can be accessed from the
    alc1220_fixup_system76_oryp5 function. In addition, the
    alc1220_fixup_clevo_p950 needs to be applied to gain speaker output.
    
    Signed-off-by: Jeremy Soller <jeremy@system76.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76137ea154eff8a12d91dc9cf2c2786b66aa820b
Author: Michal Hocko <mhocko@suse.com>
Date:   Wed Feb 20 22:19:42 2019 -0800

    proc, oom: do not report alien mms when setting oom_score_adj
    
    commit b2b469939e93458753cfbf8282ad52636495965e upstream.
    
    Tetsuo has reported that creating a thousands of processes sharing MM
    without SIGHAND (aka alien threads) and setting
    /proc/<pid>/oom_score_adj will swamp the kernel log and takes ages [1]
    to finish.  This is especially worrisome that all that printing is done
    under RCU lock and this can potentially trigger RCU stall or softlockup
    detector.
    
    The primary reason for the printk was to catch potential users who might
    depend on the behavior prior to 44a70adec910 ("mm, oom_adj: make sure
    processes sharing mm have same view of oom_score_adj") but after more
    than 2 years without a single report I guess it is safe to simply remove
    the printk altogether.
    
    The next step should be moving oom_score_adj over to the mm struct and
    remove all the tasks crawling as suggested by [2]
    
    [1] http://lkml.kernel.org/r/97fce864-6f75-bca5-14bc-12c9f890e740@i-love.sakura.ne.jp
    [2] http://lkml.kernel.org/r/20190117155159.GA4087@dhcp22.suse.cz
    
    Link: http://lkml.kernel.org/r/20190212102129.26288-1-mhocko@kernel.org
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Yong-Taek Lee <ytk.lee@samsung.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 a9432d1b208225db3e83ac3a09da8eca6d289bd8
Author: Ralph Campbell <rcampbell@nvidia.com>
Date:   Wed Feb 20 22:18:58 2019 -0800

    numa: change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES
    
    commit 050c17f239fd53adb55aa768d4f41bc76c0fe045 upstream.
    
    The system call, get_mempolicy() [1], passes an unsigned long *nodemask
    pointer and an unsigned long maxnode argument which specifies the length
    of the user's nodemask array in bits (which is rounded up).  The manual
    page says that if the maxnode value is too small, get_mempolicy will
    return EINVAL but there is no system call to return this minimum value.
    To determine this value, some programs search /proc/<pid>/status for a
    line starting with "Mems_allowed:" and use the number of digits in the
    mask to determine the minimum value.  A recent change to the way this line
    is formatted [2] causes these programs to compute a value less than
    MAX_NUMNODES so get_mempolicy() returns EINVAL.
    
    Change get_mempolicy(), the older compat version of get_mempolicy(), and
    the copy_nodes_to_user() function to use nr_node_ids instead of
    MAX_NUMNODES, thus preserving the defacto method of computing the minimum
    size for the nodemask array and the maxnode argument.
    
    [1] http://man7.org/linux/man-pages/man2/get_mempolicy.2.html
    [2] https://lore.kernel.org/lkml/1545405631-6808-1-git-send-email-longman@redhat.com
    
    Link: http://lkml.kernel.org/r/20190211180245.22295-1-rcampbell@nvidia.com
    Fixes: 4fb8e5b89bcbbbb ("include/linux/nodemask.h: use nr_node_ids (not MAX_NUMNODES) in __nodemask_pr_numnodes()")
    Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
    Suggested-by: Alexander Duyck <alexander.duyck@gmail.com>
    Cc: Waiman Long <longman@redhat.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 dee3c19384ed8d0c93055adad76d77eecc0dfe3e
Author: Yan, Zheng <zyan@redhat.com>
Date:   Mon Feb 11 15:18:52 2019 +0800

    ceph: avoid repeatedly adding inode to mdsc->snap_flush_list
    
    commit 04242ff3ac0abbaa4362f97781dac268e6c3541a upstream.
    
    Otherwise, mdsc->snap_flush_list may get corrupted.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9172020a30da7dd22a0f090b77bc9c2055efcd0
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Tue Feb 5 20:30:27 2019 +0100

    libceph: handle an empty authorize reply
    
    commit 0fd3fd0a9bb0b02b6435bb7070e9f7b82a23f068 upstream.
    
    The authorize reply can be empty, for example when the ticket used to
    build the authorizer is too old and TAG_BADAUTHORIZER is returned from
    the service.  Calling ->verify_authorizer_reply() results in an attempt
    to decrypt and validate (somewhat) random data in au->buf (most likely
    the signature block from calc_signature()), which fails and ends up in
    con_fault_finish() with !con->auth_retry.  The ticket isn't invalidated
    and the connection is retried again and again until a new ticket is
    obtained from the monitor:
    
      libceph: osd2 192.168.122.1:6809 bad authorize reply
      libceph: osd2 192.168.122.1:6809 bad authorize reply
      libceph: osd2 192.168.122.1:6809 bad authorize reply
      libceph: osd2 192.168.122.1:6809 bad authorize reply
    
    Let TAG_BADAUTHORIZER handler kick in and increment con->auth_retry.
    
    Cc: stable@vger.kernel.org
    Fixes: 5c056fdc5b47 ("libceph: verify authorize reply on connect")
    Link: https://tracker.ceph.com/issues/20164
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8f5e78157deaafec95dea16189bd97d094fddbb
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Thu Jan 31 09:29:53 2019 -0800

    pinctrl: qcom: qcs404: Correct SDC tile
    
    commit a5a08c35d382a5a8da397260c3febb8dff4bdeef upstream.
    
    The SDC controls live in the south tile, not the north one. Correct this
    so that we program the right registers.
    
    Cc: stable@vger.kernel.org
    Fixes: 22eb8301dbc1 ("pinctrl: qcom: Add qcs404 pinctrl driver")
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1102ace16c26ab1fccc3ba348f7685d659ddc8f7
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Feb 14 22:03:25 2019 +0800

    mac80211: Free mpath object when rhashtable insertion fails
    
    commit 4ff3a9d14c6c06eaa4e5976c61599ea2bd9e81b2 upstream.
    
    When rhashtable insertion fails the mesh table code doesn't free
    the now-orphan mesh path object.  This patch fixes that.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e327e1307531bb3a6a39571782cd397fe81b6873
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Feb 14 22:03:24 2019 +0800

    mac80211: Use linked list instead of rhashtable walk for mesh tables
    
    commit b4c3fbe6360178dc2181b7b43b7ae793a192b282 upstream.
    
    The mesh table code walks over hash tables for two purposes.  First of
    all it's used as part of a netlink dump process, but it is also used
    for looking up entries to delete using criteria other than the hash
    key.
    
    The second purpose is directly contrary to the design specification
    of rhashtable walks.  It is only meant for use by netlink dumps.
    
    This is because rhashtable is resizable and you cannot obtain a
    stable walk over it during a resize process.
    
    In fact mesh's use of rhashtable for dumping is bogus too.  Rather
    than using rhashtable walk's iterator to keep track of the current
    position, it always converts the current position to an integer
    which defeats the purpose of the iterator.
    
    Therefore this patch converts all uses of rhashtable walk into a
    simple linked list.
    
    This patch also adds a new spin lock to protect the hash table
    insertion/removal as well as the walk list modifications.  In fact
    the previous code was buggy as the removals can race with each
    other, potentially resulting in a double-free.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a446c0f8302f67ff610437dbcc7f42e6e6282fe
Author: Rakesh Pillai <pillair@codeaurora.org>
Date:   Fri Feb 15 14:16:02 2019 +0530

    mac80211: Restore vif beacon interval if start ap fails
    
    commit 83e37e0bdd1470bbe6612250b745ad39b1a7b130 upstream.
    
    The starting of AP interface can fail due to invalid
    beacon interval, which does not match the minimum gcd
    requirement set by the wifi driver. In such case, the
    beacon interval of that interface gets updated with
    that invalid beacon interval.
    
    The next time that interface is brought up in AP mode,
    an interface combination check is performed and the
    beacon interval is taken from the previously set value.
    
    In a case where an invalid beacon interval, i.e. a beacon
    interval value which does not satisfy the minimum gcd criteria
    set by the driver, is set, all the subsequent trials to
    bring that interface in AP mode will fail, even if the
    subsequent trials have a valid beacon interval.
    
    To avoid this, in case of a failure in bringing up an
    interface in AP mode due to interface combination error,
    the interface beacon interval which is stored in bss
    conf, needs to be restored with the last working value
    of beacon interval.
    
    Tested on ath10k using WCN3990.
    
    Cc: stable@vger.kernel.org
    Fixes: 0c317a02ca98 ("cfg80211: support virtual interfaces with different beacon intervals")
    Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d4294b30a8e11f226529936482d0c6d92eae84e
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Thu Feb 14 00:06:18 2019 +0100

    gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2
    
    commit af14b2c98adb85e9517390bb88309338b9075350 upstream.
    
    Similarly to PXA3xx, pinctrl-single can't set pin direction on MMP2 either.
    See also: commit 9dabfdd84bdfa ("gpio: pxa: disable pinctrl calls for
    PXA3xx")
    
    Cc: stable@vger.kernel.org
    Fixes: a770d946371e ("gpio: pxa: add pin control gpio direction and request")
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1a7f8aef13b2ad21bec2e7247ccd0b15be0edfd
Author: René van Dorst <opensource@vdorst.com>
Date:   Wed Jan 30 17:10:49 2019 +0100

    gpio: MT7621: use a per instance irq_chip structure
    
    commit fa84667b98fd1a191b2465d66b440bda6714b3bf upstream.
    
    This fixes the kernel complains:
    gpio gpiochip1: (1e000600.gpio-bank1): detected irqchip that is shared
                with multiple gpiochips: please fix the driver.
    gpio gpiochip2: (1e000600.gpio-bank2): detected irqchip that is shared
                with multiple gpiochips: please fix the driver.
    
    Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
    Cc: stable@vger.kernel.org
    Signed-off-by: René van Dorst <opensource@vdorst.com>
    Cc: linux-gpio@vger.kernel.org
    Cc: linux-mediatek@lists.infradead.org
    Tested-by: Greg Ungerer <gerg@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 379c6d591775cead56a2966bf4578fafef0ae107
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Feb 6 15:34:16 2019 +0100

    mt76x0u: fix suspend/resume
    
    commit d04ca383860bef90a0dab4eb397907f7f05e839e upstream.
    
    We need to reset MCU and do other initializations on resume otherwise
    MT7610U device will fail to initialize, what cause system hung due to
    USB requests timeouts.
    
    Patch fixes 4.19 -> 4.20 regression.
    
    Cc: stable@vger.kernel.org # 4.20+
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87f55ab17330a58608eb545b3fdacda709b25b47
Author: Paul Burton <paul.burton@mips.com>
Date:   Fri Feb 15 20:14:15 2019 +0000

    MIPS: eBPF: Always return sign extended 32b values
    
    commit 13443154f6cac61d148471ede6d7f1f6b5ea946a upstream.
    
    The function prototype used to call JITed eBPF code (ie. the type of the
    struct bpf_prog bpf_func field) returns an unsigned int. The MIPS n64
    ABI that MIPS64 kernels target defines that 32 bit integers should
    always be sign extended when passed in registers as either arguments or
    return values.
    
    This means that when returning any value which may not already be sign
    extended (ie. of type REG_64BIT or REG_32BIT_ZERO_EX) we need to perform
    that sign extension in order to comply with the n64 ABI. Without this we
    see strange looking test failures from test_bpf.ko, such as:
    
      test_bpf: #65 ALU64_MOV_X:
        dst = 4294967295 jited:1 ret -1 != -1 FAIL (1 times)
    
    Although the return value printed matches the expected value, this is
    only because printf is only examining the least significant 32 bits of
    the 64 bit register value we returned. The register holding the expected
    value is sign extended whilst the v0 register was set to a zero extended
    value by our JITed code, so when compared by a conditional branch
    instruction the values are not equal.
    
    We already handle this when the return value register is of type
    REG_32BIT_ZERO_EX, so simply extend this to also cover REG_64BIT.
    
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.")
    Cc: stable@vger.kernel.org # v4.13+
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5654dcabea5dcc563d5eebb1e8ed273d4359cba
Author: Quentin Perret <quentin.perret@arm.com>
Date:   Thu Feb 14 15:29:50 2019 +0000

    tracing: Fix number of entries in trace header
    
    commit 9e7382153f80ba45a0bbcd540fb77d4b15f6e966 upstream.
    
    The following commit
    
      441dae8f2f29 ("tracing: Add support for display of tgid in trace output")
    
    removed the call to print_event_info() from print_func_help_header_irq()
    which results in the ftrace header not reporting the number of entries
    written in the buffer. As this wasn't the original intent of the patch,
    re-introduce the call to print_event_info() to restore the orginal
    behaviour.
    
    Link: http://lkml.kernel.org/r/20190214152950.4179-1-quentin.perret@arm.com
    
    Acked-by: Joel Fernandes <joelaf@google.com>
    Cc: stable@vger.kernel.org
    Fixes: 441dae8f2f29 ("tracing: Add support for display of tgid in trace output")
    Signed-off-by: Quentin Perret <quentin.perret@arm.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5163e049743e3813b1d7a93aed7366bf223158cc
Author: Changbin Du <changbin.du@gmail.com>
Date:   Fri Jan 25 23:10:50 2019 +0800

    kprobe: Do not use uaccess functions to access kernel memory that can fault
    
    commit 2c4f1fcbef0bc324830bc2fb1a264c08ec93dec5 upstream.
    
    The userspace can ask kprobe to intercept strings at any memory address,
    including invalid kernel address. In this case, fetch_store_strlen()
    would crash since it uses general usercopy function, and user access
    functions are no longer allowed to access kernel memory.
    
    For example, we can crash the kernel by doing something as below:
    
    $ sudo kprobe 'p:do_sys_open +0(+0(%si)):string'
    
    [  103.620391] BUG: GPF in non-whitelisted uaccess (non-canonical address?)
    [  103.622104] general protection fault: 0000 [#1] SMP PTI
    [  103.623424] CPU: 10 PID: 1046 Comm: cat Not tainted 5.0.0-rc3-00130-gd73aba1-dirty #96
    [  103.625321] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-2-g628b2e6-dirty-20190104_103505-linux 04/01/2014
    [  103.628284] RIP: 0010:process_fetch_insn+0x1ab/0x4b0
    [  103.629518] Code: 10 83 80 28 2e 00 00 01 31 d2 31 ff 48 8b 74 24 28 eb 0c 81 fa ff 0f 00 00 7f 1c 85 c0 75 18 66 66 90 0f ae e8 48 63
     ca 89 f8 <8a> 0c 31 66 66 90 83 c2 01 84 c9 75 dc 89 54 24 34 89 44 24 28 48
    [  103.634032] RSP: 0018:ffff88845eb37ce0 EFLAGS: 00010246
    [  103.635312] RAX: 0000000000000000 RBX: ffff888456c4e5a8 RCX: 0000000000000000
    [  103.637057] RDX: 0000000000000000 RSI: 2e646c2f6374652f RDI: 0000000000000000
    [  103.638795] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    [  103.640556] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
    [  103.642297] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    [  103.644040] FS:  0000000000000000(0000) GS:ffff88846f000000(0000) knlGS:0000000000000000
    [  103.646019] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  103.647436] CR2: 00007ffc79758038 CR3: 0000000463360006 CR4: 0000000000020ee0
    [  103.649147] Call Trace:
    [  103.649781]  ? sched_clock_cpu+0xc/0xa0
    [  103.650747]  ? do_sys_open+0x5/0x220
    [  103.651635]  kprobe_trace_func+0x303/0x380
    [  103.652645]  ? do_sys_open+0x5/0x220
    [  103.653528]  kprobe_dispatcher+0x45/0x50
    [  103.654682]  ? do_sys_open+0x1/0x220
    [  103.655875]  kprobe_ftrace_handler+0x90/0xf0
    [  103.657282]  ftrace_ops_assist_func+0x54/0xf0
    [  103.658564]  ? __call_rcu+0x1dc/0x280
    [  103.659482]  0xffffffffc00000bf
    [  103.660384]  ? __ia32_sys_open+0x20/0x20
    [  103.661682]  ? do_sys_open+0x1/0x220
    [  103.662863]  do_sys_open+0x5/0x220
    [  103.663988]  do_syscall_64+0x60/0x210
    [  103.665201]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [  103.666862] RIP: 0033:0x7fc22fadccdd
    [  103.668034] Code: 48 89 54 24 e0 41 83 e2 40 75 32 89 f0 25 00 00 41 00 3d 00 00 41 00 74 24 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff
     ff 0f 05 <48> 3d 00 f0 ff ff 77 33 f3 c3 66 0f 1f 84 00 00 00 00 00 48 8d 44
    [  103.674029] RSP: 002b:00007ffc7972c3a8 EFLAGS: 00000287 ORIG_RAX: 0000000000000101
    [  103.676512] RAX: ffffffffffffffda RBX: 0000562f86147a21 RCX: 00007fc22fadccdd
    [  103.678853] RDX: 0000000000080000 RSI: 00007fc22fae1428 RDI: 00000000ffffff9c
    [  103.681151] RBP: ffffffffffffffff R08: 0000000000000000 R09: 0000000000000000
    [  103.683489] R10: 0000000000000000 R11: 0000000000000287 R12: 00007fc22fce90a8
    [  103.685774] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    [  103.688056] Modules linked in:
    [  103.689131] ---[ end trace 43792035c28984a1 ]---
    
    This can be fixed by using probe_mem_read() instead, as it can handle faulting
    kernel memory addresses, which kprobes can legitimately do.
    
    Link: http://lkml.kernel.org/r/20190125151051.7381-1-changbin.du@gmail.com
    
    Cc: stable@vger.kernel.org
    Fixes: 9da3f2b7405 ("x86/fault: BUG() when uaccess helpers fault on kernel addresses")
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a4b9a48ded8efce8c874389e5e01832e4489d1a
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Tue Feb 5 16:37:40 2019 +0100

    ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction
    
    commit 0ac569bf6a7983c0c5747d6df8db9dc05bc92b6c upstream.
    
    commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
    FORTIFY_SOURCE") introduced a regression in optimized kprobes. It
    triggers "invalid instruction" oopses when using kprobes instrumentation
    through lttng and perf. This commit was introduced in kernel v4.20, and
    has been backported to stable kernels 4.19 and 4.14.
    
    This crash was also reported by Hongzhi Song on the redhat bugzilla
    where the patch was originally introduced.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1639397
    Link: https://bugs.lttng.org/issues/1174
    Link: https://lore.kernel.org/lkml/342740659.2887.1549307721609.JavaMail.zimbra@efficios.com
    
    Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE")
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Reported-by: Robert Berger <Robert.Berger@ReliableEmbeddedSystems.com>
    Tested-by: Robert Berger <Robert.Berger@ReliableEmbeddedSystems.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Robert Berger <Robert.Berger@ReliableEmbeddedSystems.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: William Cohen <wcohen@redhat.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: <stable@vger.kernel.org> # v4.14+
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: patches@armlinux.org.uk
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>