commit d59f5a01fa438635ae098b2e170a18644df73c06
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 16 19:40:30 2019 +0200

    Linux 5.0.17

commit ba686f90778b73e9e7e144914a7f88f8f88cbc3d
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Sat Mar 16 09:13:06 2019 +0900

    f2fs: Fix use of number of devices
    
    commit 0916878da355650d7e77104a7ac0fa1784eca852 upstream.
    
    For a single device mount using a zoned block device, the zone
    information for the device is stored in the sbi->devs single entry
    array and sbi->s_ndevs is set to 1. This differs from a single device
    mount using a regular block device which does not allocate sbi->devs
    and sets sbi->s_ndevs to 0.
    
    However, sbi->s_devs == 0 condition is used throughout the code to
    differentiate a single device mount from a multi-device mount where
    sbi->s_ndevs is always larger than 1. This results in problems with
    single zoned block device volumes as these are treated as multi-device
    mounts but do not have the start_blk and end_blk information set. One
    of the problem observed is skipping of zone discard issuing resulting in
    write commands being issued to full zones or unaligned to a zone write
    pointer.
    
    Fix this problem by simply treating the cases sbi->s_ndevs == 0 (single
    regular block device mount) and sbi->s_ndevs == 1 (single zoned block
    device mount) in the same manner. This is done by introducing the
    helper function f2fs_is_multi_device() and using this helper in place
    of direct tests of sbi->s_ndevs value, improving code readability.
    
    Fixes: 7bb3a371d199 ("f2fs: Fix zoned block device support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78b8c59eee72b4e854b8f1e58eae308f750f843c
Author: Dexuan Cui <decui@microsoft.com>
Date:   Mon Mar 4 21:34:49 2019 +0000

    PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary
    
    commit 340d455699400f2c2c0f9b3f703ade3085cdb501 upstream.
    
    When we hot-remove a device, usually the host sends us a PCI_EJECT message,
    and a PCI_BUS_RELATIONS message with bus_rel->device_count == 0.
    
    When we execute the quick hot-add/hot-remove test, the host may not send
    us the PCI_EJECT message if the guest has not fully finished the
    initialization by sending the PCI_RESOURCES_ASSIGNED* message to the
    host, so it's potentially unsafe to only depend on the
    pci_destroy_slot() in hv_eject_device_work() because the code path
    
    create_root_hv_pci_bus()
     -> hv_pci_assign_slots()
    
    is not called in this case. Note: in this case, the host still sends the
    guest a PCI_BUS_RELATIONS message with bus_rel->device_count == 0.
    
    In the quick hot-add/hot-remove test, we can have such a race before
    the code path
    
    pci_devices_present_work()
     -> new_pcichild_device()
    
    adds the new device into the hbus->children list, we may have already
    received the PCI_EJECT message, and since the tasklet handler
    
    hv_pci_onchannelcallback()
    
    may fail to find the "hpdev" by calling
    
    get_pcichild_wslot(hbus, dev_message->wslot.slot)
    
    hv_pci_eject_device() is not called; Later, by continuing execution
    
    create_root_hv_pci_bus()
     -> hv_pci_assign_slots()
    
    creates the slot and the PCI_BUS_RELATIONS message with
    bus_rel->device_count == 0 removes the device from hbus->children, and
    we end up being unable to remove the slot in
    
    hv_pci_remove()
     -> hv_pci_remove_slots()
    
    Remove the slot in pci_devices_present_work() when the device
    is removed to address this race.
    
    pci_devices_present_work() and hv_eject_device_work() run in the
    singled-threaded hbus->wq, so there is not a double-remove issue for the
    slot.
    
    We cannot offload hv_pci_eject_device() from hv_pci_onchannelcallback()
    to the workqueue, because we need the hv_pci_onchannelcallback()
    synchronously call hv_pci_eject_device() to poll the channel
    ringbuffer to work around the "hangs in hv_compose_msi_msg()" issue
    fixed in commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in
    hv_compose_msi_msg()")
    
    Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    [lorenzo.pieralisi@arm.com: rewritten commit log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
    Reviewed-by:  Michael Kelley <mikelley@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f20f463b32bc09c2ef793765326798e5b0df2361
Author: Dexuan Cui <decui@microsoft.com>
Date:   Mon Mar 4 21:34:48 2019 +0000

    PCI: hv: Add hv_pci_remove_slots() when we unload the driver
    
    commit 15becc2b56c6eda3d9bf5ae993bafd5661c1fad1 upstream.
    
    When we unload the pci-hyperv host controller driver, the host does not
    send us a PCI_EJECT message.
    
    In this case we also need to make sure the sysfs PCI slot directory is
    removed, otherwise a command on a slot file eg:
    
    "cat /sys/bus/pci/slots/2/address"
    
    will trigger a
    
    "BUG: unable to handle kernel paging request"
    
    and, if we unload/reload the driver several times we would end up with
    stale slot entries in PCI slot directories in /sys/bus/pci/slots/
    
    root@localhost:~# ls -rtl  /sys/bus/pci/slots/
    total 0
    drwxr-xr-x 2 root root 0 Feb  7 10:49 2
    drwxr-xr-x 2 root root 0 Feb  7 10:49 2-1
    drwxr-xr-x 2 root root 0 Feb  7 10:51 2-2
    
    Add the missing code to remove the PCI slot and fix the current
    behaviour.
    
    Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    [lorenzo.pieralisi@arm.com: reformatted the log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3a9cd23b172d1a873c05fb9d904538e58090f8b
Author: Dexuan Cui <decui@microsoft.com>
Date:   Mon Mar 4 21:34:48 2019 +0000

    PCI: hv: Fix a memory leak in hv_eject_device_work()
    
    commit 05f151a73ec2b23ffbff706e5203e729a995cdc2 upstream.
    
    When a device is created in new_pcichild_device(), hpdev->refs is set
    to 2 (i.e. the initial value of 1 plus the get_pcichild()).
    
    When we hot remove the device from the host, in a Linux VM we first call
    hv_pci_eject_device(), which increases hpdev->refs by get_pcichild() and
    then schedules a work of hv_eject_device_work(), so hpdev->refs becomes
    3 (let's ignore the paired get/put_pcichild() in other places). But in
    hv_eject_device_work(), currently we only call put_pcichild() twice,
    meaning the 'hpdev' struct can't be freed in put_pcichild().
    
    Add one put_pcichild() to fix the memory leak.
    
    The device can also be removed when we run "rmmod pci-hyperv". On this
    path (hv_pci_remove() -> hv_pci_bus_exit() -> hv_pci_devices_present()),
    hpdev->refs is 2, and we do correctly call put_pcichild() twice in
    pci_devices_present_work().
    
    Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    [lorenzo.pieralisi@arm.com: commit log rework]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
    Reviewed-by:  Michael Kelley <mikelley@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f9572e798ea8c7a6a7b846c8fb577905e3d4a6c
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Mar 12 15:06:53 2019 +0800

    virtio_ring: Fix potential mem leak in virtqueue_add_indirect_packed
    
    commit df0bfe7501e9319546ea380d39674a4179e059c3 upstream.
    
    'desc' should be freed before leaving from err handing path.
    
    Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba81b50090a42542d48ba3395e5429ce689d6a59
Author: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Date:   Mon Apr 15 14:52:11 2019 +0300

    powerpc/booke64: set RI in default MSR
    
    commit 5266e58d6cd90ac85c187d673093ad9cb649e16d upstream.
    
    Set RI in the default kernel's MSR so that the architected way of
    detecting unrecoverable machine check interrupts has a chance to work.
    This is inline with the MSR setup of the rest of booke powerpc
    architectures configured here.
    
    Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0da52ad69b37346335848e0811467a3ffe6f0c68
Author: Russell Currey <ruscur@russell.cc>
Date:   Thu Apr 18 16:51:16 2019 +1000

    powerpc/powernv/idle: Restore IAMR after idle
    
    commit a3f3072db6cad40895c585dce65e36aab997f042 upstream.
    
    Without restoring the IAMR after idle, execution prevention on POWER9
    with Radix MMU is overwritten and the kernel can freely execute
    userspace without faulting.
    
    This is necessary when returning from any stop state that modifies
    user state, as well as hypervisor state.
    
    To test how this fails without this patch, load the lkdtm driver and
    do the following:
    
      $ echo EXEC_USERSPACE > /sys/kernel/debug/provoke-crash/DIRECT
    
    which won't fault, then boot the kernel with powersave=off, where it
    will fault. Applying this patch will fix this.
    
    Fixes: 3b10d0095a1e ("powerpc/mm/radix: Prevent kernel execution of user space")
    Cc: stable@vger.kernel.org # v4.10+
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    Reviewed-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d314437d17adcbc696e61816972a9c35df084193
Author: Rick Lindsley <ricklind@linux.vnet.ibm.com>
Date:   Sun May 5 17:20:43 2019 -0700

    powerpc/book3s/64: check for NULL pointer in pgd_alloc()
    
    commit f39356261c265a0689d7ee568132d516e8b6cecc upstream.
    
    When the memset code was added to pgd_alloc(), it failed to consider
    that kmem_cache_alloc() can return NULL. It's uncommon, but not
    impossible under heavy memory contention. Example oops:
    
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xc0000000000a4000
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE SMP NR_CPUS=2048 NUMA pSeries
      CPU: 70 PID: 48471 Comm: entrypoint.sh Kdump: loaded Not tainted 4.14.0-115.6.1.el7a.ppc64le #1
      task: c000000334a00000 task.stack: c000000331c00000
      NIP:  c0000000000a4000 LR: c00000000012f43c CTR: 0000000000000020
      REGS: c000000331c039c0 TRAP: 0300   Not tainted  (4.14.0-115.6.1.el7a.ppc64le)
      MSR:  800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 44022840  XER: 20040000
      CFAR: c000000000008874 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1
      ...
      NIP [c0000000000a4000] memset+0x68/0x104
      LR [c00000000012f43c] mm_init+0x27c/0x2f0
      Call Trace:
        mm_init+0x260/0x2f0 (unreliable)
        copy_mm+0x11c/0x638
        copy_process.isra.28.part.29+0x6fc/0x1080
        _do_fork+0xdc/0x4c0
        ppc_clone+0x8/0xc
      Instruction dump:
      409e000c b0860000 38c60002 409d000c 90860000 38c60004 78a0d183 78a506a0
      7c0903a6 41820034 60000000 60420000 <f8860000> f8860008 f8860010 f8860018
    
    Fixes: fc5c2f4a55a2 ("powerpc/mm/hash64: Zero PGD pages on allocation")
    Cc: stable@vger.kernel.org # v4.16+
    Signed-off-by: Rick Lindsley <ricklind@vnet.linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79e981a8503f662770ad038c7454f88421cfc882
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 14 15:47:03 2019 -0700

    drivers/virt/fsl_hypervisor.c: prevent integer overflow in ioctl
    
    commit 6a024330650e24556b8a18cc654ad00cfecf6c6c upstream.
    
    The "param.count" value is a u64 thatcomes from the user.  The code
    later in the function assumes that param.count is at least one and if
    it's not then it leads to an Oops when we dereference the ZERO_SIZE_PTR.
    
    Also the addition can have an integer overflow which would lead us to
    allocate a smaller "pages" array than required.  I can't immediately
    tell what the possible run times implications are, but it's safest to
    prevent the overflow.
    
    Link: http://lkml.kernel.org/r/20181218082129.GE32567@kadam
    Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Timur Tabi <timur@freescale.com>
    Cc: Mihai Caraman <mihai.caraman@freescale.com>
    Cc: Kumar Gala <galak@kernel.crashing.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a84219f73b2d9827a1a0612960c3d5c2c37d136
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 14 15:47:00 2019 -0700

    drivers/virt/fsl_hypervisor.c: dereferencing error pointers in ioctl
    
    commit c8ea3663f7a8e6996d44500ee818c9330ac4fd88 upstream.
    
    strndup_user() returns error pointers on error, and then in the error
    handling we pass the error pointers to kfree().  It will cause an Oops.
    
    Link: http://lkml.kernel.org/r/20181218082003.GD32567@kadam
    Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Timur Tabi <timur@freescale.com>
    Cc: Mihai Caraman <mihai.caraman@freescale.com>
    Cc: Kumar Gala <galak@kernel.crashing.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b8fc62b6c6740b25ed77a268c0bbd077e28ead6
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Wed May 1 23:19:03 2019 +0200

    isdn: bas_gigaset: use usb_fill_int_urb() properly
    
    [ Upstream commit 4014dfae3ccaaf3ec19c9ae0691a3f14e7132eae ]
    
    The switch to make bas_gigaset use usb_fill_int_urb() - instead of
    filling that urb "by hand" - missed the subtle ordering of the previous
    code.
    
    See, before the switch urb->dev was set to a member somewhere deep in a
    complicated structure and then supplied to usb_rcvisocpipe() and
    usb_sndisocpipe(). After that switch urb->dev wasn't set to anything
    specific before being supplied to those two macros. This triggers a
    nasty oops:
    
        BUG: unable to handle kernel NULL pointer dereference at 00000000
        #PF error: [normal kernel read fault]
        *pde = 00000000
        Oops: 0000 [#1] SMP
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-0.rc4.1.local0.fc28.i686 #1
        Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006
        EIP: gigaset_init_bchannel+0x89/0x320 [bas_gigaset]
        Code: 75 07 83 8b 84 00 00 00 40 8d 47 74 c7 07 01 00 00 00 89 45 f0 8b 44 b7 68 85 c0 0f 84 6a 02 00 00 8b 48 28 8b 93 88 00 00 00 <8b> 09 8d 54 12 03 c1 e2 0f c1 e1 08 09 ca 8b 8b 8c 00 00 00 80 ca
        EAX: f05ec200 EBX: ed404200 ECX: 00000000 EDX: 00000000
        ESI: 00000000 EDI: f065a000 EBP: f30c9f40 ESP: f30c9f20
        DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010086
        CR0: 80050033 CR2: 00000000 CR3: 0ddc7000 CR4: 000006d0
        Call Trace:
         <SOFTIRQ>
         ? gigaset_isdn_connD+0xf6/0x140 [gigaset]
         gigaset_handle_event+0x173e/0x1b90 [gigaset]
         tasklet_action_common.isra.16+0x4e/0xf0
         tasklet_action+0x1e/0x20
         __do_softirq+0xb2/0x293
         ? __irqentry_text_end+0x3/0x3
         call_on_stack+0x45/0x50
         </SOFTIRQ>
         ? irq_exit+0xb5/0xc0
         ? do_IRQ+0x78/0xd0
         ? acpi_idle_enter_s2idle+0x50/0x50
         ? common_interrupt+0xd4/0xdc
         ? acpi_idle_enter_s2idle+0x50/0x50
         ? sched_cpu_activate+0x1b/0xf0
         ? acpi_fan_resume.cold.7+0x9/0x18
         ? cpuidle_enter_state+0x152/0x4c0
         ? cpuidle_enter+0x14/0x20
         ? call_cpuidle+0x21/0x40
         ? do_idle+0x1c8/0x200
         ? cpu_startup_entry+0x25/0x30
         ? rest_init+0x88/0x8a
         ? arch_call_rest_init+0xd/0x19
         ? start_kernel+0x42f/0x448
         ? i386_start_kernel+0xac/0xb0
         ? startup_32_smp+0x164/0x168
        Modules linked in: ppp_generic slhc capi bas_gigaset gigaset kernelcapi nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc ipw2200 iTCO_wdt gpio_ich snd_intel8x0 libipw iTCO_vendor_support snd_ac97_codec lib80211 ppdev ac97_bus snd_seq cfg80211 snd_seq_device pcspkr thinkpad_acpi lpc_ich snd_pcm i2c_i801 snd_timer ledtrig_audio snd soundcore rfkill parport_pc parport pcc_cpufreq acpi_cpufreq i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sdhci_pci sysimgblt cqhci fb_sys_fops drm sdhci mmc_core tg3 ata_generic serio_raw yenta_socket pata_acpi video
        CR2: 0000000000000000
        ---[ end trace 1fe07487b9200c73 ]---
        EIP: gigaset_init_bchannel+0x89/0x320 [bas_gigaset]
        Code: 75 07 83 8b 84 00 00 00 40 8d 47 74 c7 07 01 00 00 00 89 45 f0 8b 44 b7 68 85 c0 0f 84 6a 02 00 00 8b 48 28 8b 93 88 00 00 00 <8b> 09 8d 54 12 03 c1 e2 0f c1 e1 08 09 ca 8b 8b 8c 00 00 00 80 ca
        EAX: f05ec200 EBX: ed404200 ECX: 00000000 EDX: 00000000
        ESI: 00000000 EDI: f065a000 EBP: f30c9f40 ESP: cddcb3bc
        DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010086
        CR0: 80050033 CR2: 00000000 CR3: 0ddc7000 CR4: 000006d0
        Kernel panic - not syncing: Fatal exception in interrupt
        Kernel Offset: 0xcc00000 from 0xc0400000 (relocation range: 0xc0000000-0xf6ffdfff)
        ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
    
    No-one noticed because this Oops is apparently only triggered by setting
    up an ISDN data connection on a live ISDN line on a gigaset base (ie,
    the PBX that the gigaset driver support). Very few people do that
    running present day kernels.
    
    Anyhow, a little code reorganization makes this problem go away, while
    avoiding the subtle ordering that was used in the past. So let's do
    that.
    
    Fixes: 78c696c19578 ("isdn: gigaset: use usb_fill_int_urb()")
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12786188dcf310db3666474408887504a387bda4
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 13 09:38:55 2019 -0700

    flow_dissector: disable preemption around BPF calls
    
    [ Upstream commit b1c17a9a353878602fd5bfe9103e4afe5e9a3f96 ]
    
    Various things in eBPF really require us to disable preemption
    before running an eBPF program.
    
    syzbot reported :
    
    BUG: assuming atomic context at net/core/flow_dissector.c:737
    in_atomic(): 0, irqs_disabled(): 0, pid: 24710, name: syz-executor.3
    2 locks held by syz-executor.3/24710:
     #0: 00000000e81a4bf1 (&tfile->napi_mutex){+.+.}, at: tun_get_user+0x168e/0x3ff0 drivers/net/tun.c:1850
     #1: 00000000254afebd (rcu_read_lock){....}, at: __skb_flow_dissect+0x1e1/0x4bb0 net/core/flow_dissector.c:822
    CPU: 1 PID: 24710 Comm: syz-executor.3 Not tainted 5.1.0+ #6
    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+0x172/0x1f0 lib/dump_stack.c:113
     __cant_sleep kernel/sched/core.c:6165 [inline]
     __cant_sleep.cold+0xa3/0xbb kernel/sched/core.c:6142
     bpf_flow_dissect+0xfe/0x390 net/core/flow_dissector.c:737
     __skb_flow_dissect+0x362/0x4bb0 net/core/flow_dissector.c:853
     skb_flow_dissect_flow_keys_basic include/linux/skbuff.h:1322 [inline]
     skb_probe_transport_header include/linux/skbuff.h:2500 [inline]
     skb_probe_transport_header include/linux/skbuff.h:2493 [inline]
     tun_get_user+0x2cfe/0x3ff0 drivers/net/tun.c:1940
     tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
     call_write_iter include/linux/fs.h:1872 [inline]
     do_iter_readv_writev+0x5fd/0x900 fs/read_write.c:693
     do_iter_write fs/read_write.c:970 [inline]
     do_iter_write+0x184/0x610 fs/read_write.c:951
     vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
     do_writev+0x15b/0x330 fs/read_write.c:1058
     __do_sys_writev fs/read_write.c:1131 [inline]
     __se_sys_writev fs/read_write.c:1128 [inline]
     __x64_sys_writev+0x75/0xb0 fs/read_write.c:1128
     do_syscall_64+0x103/0x670 arch/x86/entry/common.c:298
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Petar Penkov <ppenkov@google.com>
    Cc: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39f7b3941969e2303373963ffe1e588804a1f33c
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed May 1 21:54:28 2019 +0200

    net: phy: fix phy_validate_pause
    
    [ Upstream commit b4010af981ac8cdf1f7f58eb6b131c482e5dee02 ]
    
    We have valid scenarios where ETHTOOL_LINK_MODE_Pause_BIT doesn't
    need to be supported. Therefore extend the first check to check
    for rx_pause being set.
    
    See also phy_set_asym_pause:
    rx=0 and tx=1: advertise asym pause only
    rx=0 and tx=0: stop advertising both pause modes
    
    The fixed commit isn't wrong, it's just the one that introduced the
    linkmode bitmaps.
    
    Fixes: 3c1bcc8614db ("net: ethernet: Convert phydev advertize and supported from u32 to link mode")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a91e5e4c58f395e390472174448132fe7a87bf1
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed May 8 23:20:18 2019 -0400

    tuntap: synchronize through tfiles array instead of tun->numqueues
    
    [ Upstream commit 9871a9e47a2646fe30ae7fd2e67668a8d30912f6 ]
    
    When a queue(tfile) is detached through __tun_detach(), we move the
    last enabled tfile to the position where detached one sit but don't
    NULL out last position. We expect to synchronize the datapath through
    tun->numqueues. Unfortunately, this won't work since we're lacking
    sufficient mechanism to order or synchronize the access to
    tun->numqueues.
    
    To fix this, NULL out the last position during detaching and check
    RCU protected tfile against NULL instead of checking tun->numqueues in
    datapath.
    
    Cc: YueHaibing <yuehaibing@huawei.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: weiyongjun (A) <weiyongjun1@huawei.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Fixes: c8d68e6be1c3b ("tuntap: multiqueue support")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0630246658aad0d220e2e73ade47d5639e9c350
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed May 8 23:20:17 2019 -0400

    tuntap: fix dividing by zero in ebpf queue selection
    
    [ Upstream commit a35d310f03a692bf4798eb309a1950a06a150620 ]
    
    We need check if tun->numqueues is zero (e.g for the persist device)
    before trying to use it for modular arithmetic.
    
    Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
    Fixes: 96f84061620c6("tun: add eBPF based queue selection method")
    Signed-off-by: Jason Wang <jasowang@redhat.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 92edcf205388b6bb211f0e56e91582f0cfa7c3f8
Author: Stephen Suryaputra <ssuryaextr@gmail.com>
Date:   Mon May 6 15:00:01 2019 -0400

    vrf: sit mtu should not be updated when vrf netdev is the link
    
    [ Upstream commit ff6ab32bd4e073976e4d8797b4d514a172cfe6cb ]
    
    VRF netdev mtu isn't typically set and have an mtu of 65536. When the
    link of a tunnel is set, the tunnel mtu is changed from 1480 to the link
    mtu minus tunnel header. In the case of VRF netdev is the link, then the
    tunnel mtu becomes 65516. So, fix it by not setting the tunnel mtu in
    this case.
    
    Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13d54150e74663a168c23ef7626cb4ef994c9f6d
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu May 9 14:55:07 2019 +0800

    vlan: disable SIOCSHWTSTAMP in container
    
    [ Upstream commit 873017af778439f2f8e3d87f28ddb1fcaf244a76 ]
    
    With NET_ADMIN enabled in container, a normal user could be mapped to
    root and is able to change the real device's rx filter via ioctl on
    vlan, which would affect the other ptp process on host. Fix it by
    disabling SIOCSHWTSTAMP in container.
    
    Fixes: a6111d3c93d0 ("vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83c25477e944b9f87ce0d32646ab131fd2139540
Author: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@gmail.com>
Date:   Thu May 9 07:13:42 2019 +0200

    tipc: fix hanging clients using poll with EPOLLOUT flag
    
    [ Upstream commit ff946833b70e0c7f93de9a3f5b329b5ae2287b38 ]
    
    commit 517d7c79bdb398 ("tipc: fix hanging poll() for stream sockets")
    introduced a regression for clients using non-blocking sockets.
    After the commit, we send EPOLLOUT event to the client even in
    TIPC_CONNECTING state. This causes the subsequent send() to fail
    with ENOTCONN, as the socket is still not in TIPC_ESTABLISHED state.
    
    In this commit, we:
    - improve the fix for hanging poll() by replacing sk_data_ready()
      with sk_state_change() to wake up all clients.
    - revert the faulty updates introduced by commit 517d7c79bdb398
      ("tipc: fix hanging poll() for stream sockets").
    
    Fixes: 517d7c79bdb398 ("tipc: fix hanging poll() for stream sockets")
    Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@gmail.com>
    Acked-by: Jon Maloy <jon.maloy@ericsson.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be6a9818866dce876f65e7fba6030eabfca9721c
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed May 8 15:32:51 2019 +0200

    selinux: do not report error on connect(AF_UNSPEC)
    
    [ Upstream commit c7e0d6cca86581092cbbf2cd868b3601495554cf ]
    
    calling connect(AF_UNSPEC) on an already connected TCP socket is an
    established way to disconnect() such socket. After commit 68741a8adab9
    ("selinux: Fix ltp test connect-syscall failure") it no longer works
    and, in the above scenario connect() fails with EAFNOSUPPORT.
    
    Fix the above falling back to the generic/old code when the address family
    is not AF_INET{4,6}, but leave the SCTP code path untouched, as it has
    specific constraints.
    
    Fixes: 68741a8adab9 ("selinux: Fix ltp test connect-syscall failure")
    Reported-by: Tom Deseyn <tdeseyn@redhat.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-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 c3954f8f5a7e0de2c6be51f6f65736cc2d193b86
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu May 9 22:52:20 2019 +0800

    packet: Fix error path in packet_init
    
    [ Upstream commit 36096f2f4fa05f7678bc87397665491700bae757 ]
    
    kernel BUG at lib/list_debug.c:47!
    invalid opcode: 0000 [#1
    CPU: 0 PID: 12914 Comm: rmmod Tainted: G        W         5.1.0+ #47
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    RIP: 0010:__list_del_entry_valid+0x53/0x90
    Code: 48 8b 32 48 39 fe 75 35 48 8b 50 08 48 39 f2 75 40 b8 01 00 00 00 5d c3 48
    89 fe 48 89 c2 48 c7 c7 18 75 fe 82 e8 cb 34 78 ff <0f> 0b 48 89 fe 48 c7 c7 50 75 fe 82 e8 ba 34 78 ff 0f 0b 48 89 f2
    RSP: 0018:ffffc90001c2fe40 EFLAGS: 00010286
    RAX: 000000000000004e RBX: ffffffffa0184000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff888237a17788 RDI: 00000000ffffffff
    RBP: ffffc90001c2fe40 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffc90001c2fe10 R11: 0000000000000000 R12: 0000000000000000
    R13: ffffc90001c2fe50 R14: ffffffffa0184000 R15: 0000000000000000
    FS:  00007f3d83634540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000555c350ea818 CR3: 0000000231677000 CR4: 00000000000006f0
    Call Trace:
     unregister_pernet_operations+0x34/0x120
     unregister_pernet_subsys+0x1c/0x30
     packet_exit+0x1c/0x369 [af_packet
     __x64_sys_delete_module+0x156/0x260
     ? lockdep_hardirqs_on+0x133/0x1b0
     ? do_syscall_64+0x12/0x1f0
     do_syscall_64+0x6e/0x1f0
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    When modprobe af_packet, register_pernet_subsys
    fails and does a cleanup, ops->list is set to LIST_POISON1,
    but the module init is considered to success, then while rmmod it,
    BUG() is triggered in __list_del_entry_valid which is called from
    unregister_pernet_subsys. This patch fix error handing path in
    packet_init to avoid possilbe issue if some error occur.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bc936f4f226d744cc45a5b9ac45e3263ea9f80d
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Fri May 3 13:33:23 2019 +0000

    net: ucc_geth - fix Oops when changing number of buffers in the ring
    
    [ Upstream commit ee0df19305d9fabd9479b785918966f6e25b733b ]
    
    When changing the number of buffers in the RX ring while the interface
    is running, the following Oops is encountered due to the new number
    of buffers being taken into account immediately while their allocation
    is done when opening the device only.
    
    [   69.882706] Unable to handle kernel paging request for data at address 0xf0000100
    [   69.890172] Faulting instruction address: 0xc033e164
    [   69.895122] Oops: Kernel access of bad area, sig: 11 [#1]
    [   69.900494] BE PREEMPT CMPCPRO
    [   69.907120] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.115-00006-g179ade8ce3-dirty #269
    [   69.915956] task: c0684310 task.stack: c06da000
    [   69.920470] NIP:  c033e164 LR: c02e44d0 CTR: c02e41fc
    [   69.925504] REGS: dfff1e20 TRAP: 0300   Not tainted  (4.14.115-00006-g179ade8ce3-dirty)
    [   69.934161] MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 22004428  XER: 20000000
    [   69.940869] DAR: f0000100 DSISR: 20000000
    [   69.940869] GPR00: c0352d70 dfff1ed0 c0684310 f00000a4 00000040 dfff1f68 00000000 0000001f
    [   69.940869] GPR08: df53f410 1cc00040 00000021 c0781640 42004424 100c82b6 f00000a4 df53f5b0
    [   69.940869] GPR16: df53f6c0 c05daf84 00000040 00000000 00000040 c0782be4 00000000 00000001
    [   69.940869] GPR24: 00000000 df53f400 000001b0 df53f410 df53f000 0000003f df708220 1cc00044
    [   69.978348] NIP [c033e164] skb_put+0x0/0x5c
    [   69.982528] LR [c02e44d0] ucc_geth_poll+0x2d4/0x3f8
    [   69.987384] Call Trace:
    [   69.989830] [dfff1ed0] [c02e4554] ucc_geth_poll+0x358/0x3f8 (unreliable)
    [   69.996522] [dfff1f20] [c0352d70] net_rx_action+0x248/0x30c
    [   70.002099] [dfff1f80] [c04e93e4] __do_softirq+0xfc/0x310
    [   70.007492] [dfff1fe0] [c0021124] irq_exit+0xd0/0xd4
    [   70.012458] [dfff1ff0] [c000e7e0] call_do_irq+0x24/0x3c
    [   70.017683] [c06dbe80] [c0006bac] do_IRQ+0x64/0xc4
    [   70.022474] [c06dbea0] [c001097c] ret_from_except+0x0/0x14
    [   70.027964] --- interrupt: 501 at rcu_idle_exit+0x84/0x90
    [   70.027964]     LR = rcu_idle_exit+0x74/0x90
    [   70.037585] [c06dbf60] [20000000] 0x20000000 (unreliable)
    [   70.042984] [c06dbf80] [c004bb0c] do_idle+0xb4/0x11c
    [   70.047945] [c06dbfa0] [c004bd14] cpu_startup_entry+0x18/0x1c
    [   70.053682] [c06dbfb0] [c05fb034] start_kernel+0x370/0x384
    [   70.059153] [c06dbff0] [00003438] 0x3438
    [   70.063062] Instruction dump:
    [   70.066023] 38a00000 38800000 90010014 4bfff015 80010014 7c0803a6 3123ffff 7c691910
    [   70.073767] 38210010 4e800020 38600000 4e800020 <80e3005c> 80c30098 3107ffff 7d083910
    [   70.081690] ---[ end trace be7ccd9c1e1a9f12 ]---
    
    This patch forbids the modification of the number of buffers in the
    ring while the interface is running.
    
    Fixes: ac421852b3a0 ("ucc_geth: add ethtool support")
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57ee33b4819059a64c4ed7bf24b79c9649a50cf3
Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date:   Mon May 13 13:15:17 2019 +0200

    net: seeq: fix crash caused by not set dev.parent
    
    [ Upstream commit 5afcd14cfc7fed1bcc8abcee2cef82732772bfc2 ]
    
    The old MIPS implementation of dma_cache_sync() didn't use the dev argument,
    but commit c9eb6172c328 ("dma-mapping: turn dma_cache_sync into a
    dma_map_ops method") changed that, so we now need to set dev.parent.
    
    Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 224b04c9e0284988a14d253e5663a77ffb5a5262
Author: Harini Katakam <harini.katakam@xilinx.com>
Date:   Tue May 7 19:59:10 2019 +0530

    net: macb: Change interrupt and napi enable order in open
    
    [ Upstream commit 0504453139ef5a593c9587e1e851febee859c7d8 ]
    
    Current order in open:
    -> Enable interrupts (macb_init_hw)
    -> Enable NAPI
    -> Start PHY
    
    Sequence of RX handling:
    -> RX interrupt occurs
    -> Interrupt is cleared and interrupt bits disabled in handler
    -> NAPI is scheduled
    -> In NAPI, RX budget is processed and RX interrupts are re-enabled
    
    With the above, on QEMU or fixed link setups (where PHY state doesn't
    matter), there's a chance macb RX interrupt occurs before NAPI is
    enabled. This will result in NAPI being scheduled before it is enabled.
    Fix this macb open by changing the order.
    
    Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues")
    Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3bf31d7ffb276e6c6fbd0f51ca8a80dcb5d1b2e
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Mon May 13 13:06:39 2019 +0000

    net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering
    
    [ Upstream commit d4c26eb6e721683a0f93e346ce55bc8dc3cbb175 ]
    
    When adding more MAC addresses to a dwmac-sun8i interface, the device goes
    directly in promiscuous mode.
    This is due to IFF_UNICAST_FLT missing flag.
    
    So since the hardware support unicast filtering, let's add IFF_UNICAST_FLT.
    
    Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 261a8958a57e3f9e0bd9c0cf7d7b637b2cb8def9
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon May 6 23:25:29 2019 +0800

    net: dsa: Fix error cleanup path in dsa_init_module
    
    [ Upstream commit 68be930249d051fd54d3d99156b3dcadcb2a1f9b ]
    
    BUG: unable to handle kernel paging request at ffffffffa01c5430
    PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bc5067 PTE 0
    Oops: 0000 [#1
    CPU: 0 PID: 6159 Comm: modprobe Not tainted 5.1.0+ #33
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    RIP: 0010:raw_notifier_chain_register+0x16/0x40
    Code: 63 f8 66 90 e9 5d ff ff ff 90 90 90 90 90 90 90 90 90 90 90 55 48 8b 07 48 89 e5 48 85 c0 74 1c 8b 56 10 3b 50 10 7e 07 eb 12 <39> 50 10 7c 0d 48 8d 78 08 48 8b 40 08 48 85 c0 75 ee 48 89 46 08
    RSP: 0018:ffffc90001c33c08 EFLAGS: 00010282
    RAX: ffffffffa01c5420 RBX: ffffffffa01db420 RCX: 4fcef45928070a8b
    RDX: 0000000000000000 RSI: ffffffffa01db420 RDI: ffffffffa01b0068
    RBP: ffffc90001c33c08 R08: 000000003e0a33d0 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000094443661 R12: ffff88822c320700
    R13: ffff88823109be80 R14: 0000000000000000 R15: ffffc90001c33e78
    FS:  00007fab8bd08540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffa01c5430 CR3: 00000002297ea000 CR4: 00000000000006f0
    Call Trace:
     register_netdevice_notifier+0x43/0x250
     ? 0xffffffffa01e0000
     dsa_slave_register_notifier+0x13/0x70 [dsa_core
     ? 0xffffffffa01e0000
     dsa_init_module+0x2e/0x1000 [dsa_core
     do_one_initcall+0x6c/0x3cc
     ? do_init_module+0x22/0x1f1
     ? rcu_read_lock_sched_held+0x97/0xb0
     ? kmem_cache_alloc_trace+0x325/0x3b0
     do_init_module+0x5b/0x1f1
     load_module+0x1db1/0x2690
     ? m_show+0x1d0/0x1d0
     __do_sys_finit_module+0xc5/0xd0
     __x64_sys_finit_module+0x15/0x20
     do_syscall_64+0x6b/0x1d0
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Cleanup allocated resourses if there are errors,
    otherwise it will trgger memleak.
    
    Fixes: c9eb3e0f8701 ("net: dsa: Add support for learning FDB through notification")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f679c41821f0b52d769062bd6182fd829d0d046
Author: David Ahern <dsahern@gmail.com>
Date:   Tue May 7 20:44:59 2019 -0700

    ipv4: Fix raw socket lookup for local traffic
    
    [ Upstream commit 19e4e768064a87b073a4b4c138b55db70e0cfb9f ]
    
    inet_iif should be used for the raw socket lookup. inet_iif considers
    rt_iif which handles the case of local traffic.
    
    As it stands, ping to a local address with the '-I <dev>' option fails
    ever since ping was changed to use SO_BINDTODEVICE instead of
    cmsg + IP_PKTINFO.
    
    IPv6 works fine.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8351176aed60c92a1335cc8c50960c2aa4f5f92
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Tue May 7 17:11:18 2019 +0800

    fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied
    
    [ Upstream commit e9919a24d3022f72bcadc407e73a6ef17093a849 ]
    
    With commit 153380ec4b9 ("fib_rules: Added NLM_F_EXCL support to
    fib_nl_newrule") we now able to check if a rule already exists. But this
    only works with iproute2. For other tools like libnl, NetworkManager,
    it still could add duplicate rules with only NLM_F_CREATE flag, like
    
    [localhost ~ ]# ip rule
    0:      from all lookup local
    32766:  from all lookup main
    32767:  from all lookup default
    100000: from 192.168.7.5 lookup 5
    100000: from 192.168.7.5 lookup 5
    
    As it doesn't make sense to create two duplicate rules, let's just return
    0 if the rule exists.
    
    Fixes: 153380ec4b9 ("fib_rules: Added NLM_F_EXCL support to fib_nl_newrule")
    Reported-by: Thomas Haller <thaller@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4607de103badfd2b03e334f321342dcad9df414
Author: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Date:   Fri May 3 16:03:11 2019 +0300

    dpaa_eth: fix SG frame cleanup
    
    [ Upstream commit 17170e6570c082717c142733d9a638bcd20551f8 ]
    
    Fix issue with the entry indexing in the sg frame cleanup code being
    off-by-1. This problem showed up when doing some basic iperf tests and
    manifested in traffic coming to a halt.
    
    Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
    Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 430a64f6fa2c7ce59e5b51fd610349d4e71d1e21
Author: Tobin C. Harding <tobin@kernel.org>
Date:   Fri May 10 12:52:12 2019 +1000

    bridge: Fix error path for kobject_init_and_add()
    
    [ Upstream commit bdfad5aec1392b93495b77b864d58d7f101dc1c1 ]
    
    Currently error return from kobject_init_and_add() is not followed by a
    call to kobject_put().  This means there is a memory leak.  We currently
    set p to NULL so that kfree() may be called on it as a noop, the code is
    arguably clearer if we move the kfree() up closer to where it is
    called (instead of after goto jump).
    
    Remove a goto label 'err1' and jump to call to kobject_put() in error
    return from kobject_init_and_add() fixing the memory leak.  Re-name goto
    label 'put_back' to 'err1' now that we don't use err1, following current
    nomenclature (err1, err2 ...).  Move call to kfree out of the error
    code at bottom of function up to closer to where memory was allocated.
    Add comment to clarify call to kfree().
    
    Signed-off-by: Tobin C. Harding <tobin@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69798384ba38bbf5560b1e0554dd35c524850b0a
Author: Jarod Wilson <jarod@redhat.com>
Date:   Fri May 10 17:57:09 2019 -0400

    bonding: fix arp_validate toggling in active-backup mode
    
    [ Upstream commit a9b8a2b39ce65df45687cf9ef648885c2a99fe75 ]
    
    There's currently a problem with toggling arp_validate on and off with an
    active-backup bond. At the moment, you can start up a bond, like so:
    
    modprobe bonding mode=1 arp_interval=100 arp_validate=0 arp_ip_targets=192.168.1.1
    ip link set bond0 down
    echo "ens4f0" > /sys/class/net/bond0/bonding/slaves
    echo "ens4f1" > /sys/class/net/bond0/bonding/slaves
    ip link set bond0 up
    ip addr add 192.168.1.2/24 dev bond0
    
    Pings to 192.168.1.1 work just fine. Now turn on arp_validate:
    
    echo 1 > /sys/class/net/bond0/bonding/arp_validate
    
    Pings to 192.168.1.1 continue to work just fine. Now when you go to turn
    arp_validate off again, the link falls flat on it's face:
    
    echo 0 > /sys/class/net/bond0/bonding/arp_validate
    dmesg
    ...
    [133191.911987] bond0: Setting arp_validate to none (0)
    [133194.257793] bond0: bond_should_notify_peers: slave ens4f0
    [133194.258031] bond0: link status definitely down for interface ens4f0, disabling it
    [133194.259000] bond0: making interface ens4f1 the new active one
    [133197.330130] bond0: link status definitely down for interface ens4f1, disabling it
    [133197.331191] bond0: now running without any active interface!
    
    The problem lies in bond_options.c, where passing in arp_validate=0
    results in bond->recv_probe getting set to NULL. This flies directly in
    the face of commit 3fe68df97c7f, which says we need to set recv_probe =
    bond_arp_recv, even if we're not using arp_validate. Said commit fixed
    this in bond_option_arp_interval_set, but missed that we can get to that
    same state in bond_option_arp_validate_set as well.
    
    One solution would be to universally set recv_probe = bond_arp_recv here
    as well, but I don't think bond_option_arp_validate_set has any business
    touching recv_probe at all, and that should be left to the arp_interval
    code, so we can just make things much tidier here.
    
    Fixes: 3fe68df97c7f ("bonding: always set recv_probe to bond_arp_rcv in arp monitor")
    CC: Jay Vosburgh <j.vosburgh@gmail.com>
    CC: Veaceslav Falico <vfalico@gmail.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: netdev@vger.kernel.org
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3ff0184ebd26e9ab985173a778415947ff9f225
Author: Nigel Croxon <ncroxon@redhat.com>
Date:   Fri Mar 29 10:46:15 2019 -0700

    Don't jump to compute_result state from check_result state
    
    commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef upstream.
    
    Changing state from check_state_check_result to
    check_state_compute_result not only is unsafe but also doesn't
    appear to serve a valid purpose.  A raid6 check should only be
    pushing out extra writes if doing repair and a mis-match occurs.
    The stripe dev management will already try and do repair writes
    for failing sectors.
    
    This patch makes the raid6 check_state_check_result handling
    work more like raid5's.  If somehow too many failures for a
    check, just quit the check operation for the stripe.  When any
    checks pass, don't try and use check_state_compute_result for
    a purpose it isn't needed for and is unsafe for.  Just mark the
    stripe as in sync for passing its parity checks and let the
    stripe dev read/write code and the bad blocks list do their
    job handling I/O errors.
    
    Repro steps from Xiao:
    
    These are the steps to reproduce this problem:
    1. redefined OPT_MEDIUM_ERR_ADDR to 12000 in scsi_debug.c
    2. insmod scsi_debug.ko dev_size_mb=11000  max_luns=1 num_tgts=1
    3. mdadm --create /dev/md127 --level=6 --raid-devices=5 /dev/sde1 /dev/sde2 /dev/sde3 /dev/sde5 /dev/sde6
    sde is the disk created by scsi_debug
    4. echo "2" >/sys/module/scsi_debug/parameters/opts
    5. raid-check
    
    It panic:
    [ 4854.730899] md: data-check of RAID array md127
    [ 4854.857455] sd 5:0:0:0: [sdr] tag#80 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    [ 4854.859246] sd 5:0:0:0: [sdr] tag#80 Sense Key : Medium Error [current]
    [ 4854.860694] sd 5:0:0:0: [sdr] tag#80 Add. Sense: Unrecovered read error
    [ 4854.862207] sd 5:0:0:0: [sdr] tag#80 CDB: Read(10) 28 00 00 00 2d 88 00 04 00 00
    [ 4854.864196] print_req_error: critical medium error, dev sdr, sector 11656 flags 0
    [ 4854.867409] sd 5:0:0:0: [sdr] tag#100 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    [ 4854.869469] sd 5:0:0:0: [sdr] tag#100 Sense Key : Medium Error [current]
    [ 4854.871206] sd 5:0:0:0: [sdr] tag#100 Add. Sense: Unrecovered read error
    [ 4854.872858] sd 5:0:0:0: [sdr] tag#100 CDB: Read(10) 28 00 00 00 2e e0 00 00 08 00
    [ 4854.874587] print_req_error: critical medium error, dev sdr, sector 12000 flags 4000
    [ 4854.876456] sd 5:0:0:0: [sdr] tag#101 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    [ 4854.878552] sd 5:0:0:0: [sdr] tag#101 Sense Key : Medium Error [current]
    [ 4854.880278] sd 5:0:0:0: [sdr] tag#101 Add. Sense: Unrecovered read error
    [ 4854.881846] sd 5:0:0:0: [sdr] tag#101 CDB: Read(10) 28 00 00 00 2e e8 00 00 08 00
    [ 4854.883691] print_req_error: critical medium error, dev sdr, sector 12008 flags 4000
    [ 4854.893927] sd 5:0:0:0: [sdr] tag#166 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    [ 4854.896002] sd 5:0:0:0: [sdr] tag#166 Sense Key : Medium Error [current]
    [ 4854.897561] sd 5:0:0:0: [sdr] tag#166 Add. Sense: Unrecovered read error
    [ 4854.899110] sd 5:0:0:0: [sdr] tag#166 CDB: Read(10) 28 00 00 00 2e e0 00 00 10 00
    [ 4854.900989] print_req_error: critical medium error, dev sdr, sector 12000 flags 0
    [ 4854.902757] md/raid:md127: read error NOT corrected!! (sector 9952 on sdr1).
    [ 4854.904375] md/raid:md127: read error NOT corrected!! (sector 9960 on sdr1).
    [ 4854.906201] ------------[ cut here ]------------
    [ 4854.907341] kernel BUG at drivers/md/raid5.c:4190!
    
    raid5.c:4190 above is this BUG_ON:
    
        handle_parity_checks6()
            ...
            BUG_ON(s->uptodate < disks - 1); /* We don't need Q to recover */
    
    Cc: <stable@vger.kernel.org> # v3.16+
    OriginalAuthor: David Jeffery <djeffery@redhat.com>
    Cc: Xiao Ni <xni@redhat.com>
    Tested-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: David Jeffy <djeffery@redhat.com>
    Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 843135c1ce1e566aeff8b2ecf053ee904a0b1cf0
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Apr 16 10:17:22 2019 -0500

    rtlwifi: rtl8723ae: Fix missing break in switch statement
    
    commit 84242b82d81c54e009a2aaa74d3d9eff70babf56 upstream.
    
    Add missing break statement in order to prevent the code from falling
    through to case 0x1025, and erroneously setting rtlhal->oem_id to
    RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
    none of the cases in switch (rtlefuse->eeprom_smid) match.
    
    This bug was found thanks to the ongoing efforts to enable
    -Wimplicit-fallthrough.
    
    Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14654a1f2e2bb9057aed4f6e668a65c81197a4ef
Author: Petr Štetiar <ynezz@true.cz>
Date:   Thu Apr 11 20:13:30 2019 +0200

    mwl8k: Fix rate_idx underflow
    
    commit 6b583201fa219b7b1b6aebd8966c8fd9357ef9f4 upstream.
    
    It was reported on OpenWrt bug tracking system[1], that several users
    are affected by the endless reboot of their routers if they configure
    5GHz interface with channel 44 or 48.
    
    The reboot loop is caused by the following excessive number of WARN_ON
    messages:
    
     WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516
                                 ieee80211_rx_napi+0x1fc/0xa54 [mac80211]
    
    as the messages are being correctly emitted by the following guard:
    
     case RX_ENC_LEGACY:
          if (WARN_ON(status->rate_idx >= sband->n_bitrates))
    
    as the rate_idx is in this case erroneously set to 251 (0xfb). This fix
    simply converts previously used magic number to proper constant and
    guards against substraction which is leading to the currently observed
    underflow.
    
    1. https://bugs.openwrt.org/index.php?do=details&task_id=2218
    
    Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive")
    Cc: <stable@vger.kernel.org>
    Tested-by: Eubert Bao <bunnier@gmail.com>
    Reported-by: Eubert Bao <bunnier@gmail.com>
    Signed-off-by: Petr Štetiar <ynezz@true.cz>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 202436fe081084781b2ef2bcbae907cc2ddb0634
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Sat Dec 22 10:34:54 2018 +0000

    cw1200: fix missing unlock on error in cw1200_hw_scan()
    
    commit 51c8d24101c79ffce3e79137e2cee5dfeb956dd7 upstream.
    
    Add the missing unlock before return from function cw1200_hw_scan()
    in the error handling case.
    
    Fixes: 4f68ef64cd7f ("cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92a9787bb38c3545e838d76b14e7e620d0450dc5
Author: Damian Kos <dkos@cadence.com>
Date:   Mon Nov 19 15:14:14 2018 +0000

    drm/rockchip: fix for mailbox read validation.
    
    [ Upstream commit e4056bbb6719fe713bfc4030ac78e8e97ddf7574 ]
    
    This is basically the same fix as in
    commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
    but for cdn_dp_mailbox_validate_receive function.
    
    See patchwork.kernel.org/patch/10671981/ for details.
    
    Signed-off-by: Damian Kos <dkos@cadence.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/1542640463-18332-1-git-send-email-dkos@cadence.com
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>

commit 5b4ef3c5faf9c4a08fb544addc1ae7dc483b83c5
Author: Antoine Tenart <antoine.tenart@bootlin.com>
Date:   Fri Mar 1 11:52:08 2019 +0100

    net: mvpp2: fix validate for PPv2.1
    
    [ Upstream commit 8b318f30ab4ef9bbc1241e6f8c1db366dbd347f2 ]
    
    The Phylink validate function is the Marvell PPv2 driver makes a check
    on the GoP id. This is valid an has to be done when using PPv2.2 engines
    but makes no sense when using PPv2.1. The check done when using an RGMII
    interface makes sure the GoP id is not 0, but this breaks PPv2.1. Fixes
    it.
    
    Fixes: 0fb628f0f250 ("net: mvpp2: fix phylink handling of invalid PHY modes")
    Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>

commit 45e1075e04cb394d7d526bfaac87c14e9d6fd547
Author: John Hurley <john.hurley@netronome.com>
Date:   Fri Mar 22 12:37:35 2019 +0000

    net: sched: fix cleanup NULL pointer exception in act_mirr
    
    [ Upstream commit 064c5d6881e897077639e04973de26440ee205e6 ]
    
    A new mirred action is created by the tcf_mirred_init function. This
    contains a list head struct which is inserted into a global list on
    successful creation of a new action. However, after a creation, it is
    still possible to error out and call the tcf_idr_release function. This,
    in turn, calls the act_mirr cleanup function via __tcf_idr_release and
    __tcf_action_put. This cleanup function tries to delete the list entry
    which is as yet uninitialised, leading to a NULL pointer exception.
    
    Fix this by initialising the list entry on creation of a new action.
    
    Bug report:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    PGD 8000000840c73067 P4D 8000000840c73067 PUD 858dcc067 PMD 0
    Oops: 0002 [#1] SMP PTI
    CPU: 32 PID: 5636 Comm: handler194 Tainted: G           OE     5.0.0+ #186
    Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.3.6 06/03/2015
    RIP: 0010:tcf_mirred_release+0x42/0xa7 [act_mirred]
    Code: f0 90 39 c0 e8 52 04 57 c8 48 c7 c7 b8 80 39 c0 e8 94 fa d4 c7 48 8b 93 d0 00 00 00 48 8b 83 d8 00 00 00 48 c7 c7 f0 90 39 c0 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 d0 00
    RSP: 0018:ffffac4aa059f688 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff9dcd1b214d00 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff9dcd1fa165f8 RDI: ffffffffc03990f0
    RBP: ffff9dccf9c7af80 R08: 0000000000000a3b R09: 0000000000000000
    R10: ffff9dccfa11f420 R11: 0000000000000000 R12: 0000000000000001
    R13: ffff9dcd16b433c0 R14: ffff9dcd1b214d80 R15: 0000000000000000
    FS:  00007f441bfff700(0000) GS:ffff9dcd1fa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 0000000839e64004 CR4: 00000000001606e0
    Call Trace:
    tcf_action_cleanup+0x59/0xca
    __tcf_action_put+0x54/0x6b
    __tcf_idr_release.cold.33+0x9/0x12
    tcf_mirred_init.cold.20+0x22e/0x3b0 [act_mirred]
    tcf_action_init_1+0x3d0/0x4c0
    tcf_action_init+0x9c/0x130
    tcf_exts_validate+0xab/0xc0
    fl_change+0x1ca/0x982 [cls_flower]
    tc_new_tfilter+0x647/0x8d0
    ? load_balance+0x14b/0x9e0
    rtnetlink_rcv_msg+0xe3/0x370
    ? __switch_to_asm+0x40/0x70
    ? __switch_to_asm+0x34/0x70
    ? _cond_resched+0x15/0x30
    ? __kmalloc_node_track_caller+0x1d4/0x2b0
    ? rtnl_calcit.isra.31+0xf0/0xf0
    netlink_rcv_skb+0x49/0x110
    netlink_unicast+0x16f/0x210
    netlink_sendmsg+0x1df/0x390
    sock_sendmsg+0x36/0x40
    ___sys_sendmsg+0x27b/0x2c0
    ? futex_wake+0x80/0x140
    ? do_futex+0x2b9/0xac0
    ? ep_scan_ready_list.constprop.22+0x1f2/0x210
    ? ep_poll+0x7a/0x430
    __sys_sendmsg+0x47/0x80
    do_syscall_64+0x55/0x100
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 4e232818bd32 ("net: sched: act_mirred: remove dependency on rtnl lock")
    Signed-off-by: John Hurley <john.hurley@netronome.com>
    Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>

commit 4b84cde61ce9135b9c98641307b8a22f44609914
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Mar 6 14:35:15 2019 -0500

    bpf: only test gso type on gso packets
    
    [ Upstream commit 4c3024debf62de4c6ac6d3cb4c0063be21d4f652 ]
    
    BPF can adjust gso only for tcp bytestreams. Fail on other gso types.
    
    But only on gso packets. It does not touch this field if !gso_size.
    
    Fixes: b90efd225874 ("bpf: only adjust gso_size on bytestream protocols")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>

commit 073d8f286f34b50058ad8c3929a4421f4b0e449f
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Thu Apr 25 22:23:58 2019 -0700

    mm/page_alloc.c: avoid potential NULL pointer dereference
    
    [ Upstream commit 8139ad043d632c0e9e12d760068a7a8e91659aa1 ]
    
    ac.preferred_zoneref->zone passed to alloc_flags_nofragment() can be NULL.
    'zone' pointer unconditionally derefernced in alloc_flags_nofragment().
    Bail out on NULL zone to avoid potential crash.  Currently we don't see
    any crashes only because alloc_flags_nofragment() has another bug which
    allows compiler to optimize away all accesses to 'zone'.
    
    Link: http://lkml.kernel.org/r/20190423120806.3503-1-aryabinin@virtuozzo.com
    Fixes: 6bb154504f8b ("mm, page_alloc: spread allocations across zones before introducing fragmentation")
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61fadd8a5000780622ed647a39ab26cae480b365
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Apr 25 22:23:37 2019 -0700

    mm/memory_hotplug.c: drop memory device reference after find_memory_block()
    
    [ Upstream commit 89c02e69fc5245f8a2f34b58b42d43a737af1a5e ]
    
    Right now we are using find_memory_block() to get the node id for the
    pfn range to online.  We are missing to drop a reference to the memory
    block device.  While the device still gets unregistered via
    device_unregister(), resulting in no user visible problem, the device is
    never released via device_release(), resulting in a memory leak.  Fix
    that by properly using a put_device().
    
    Link: http://lkml.kernel.org/r/20190411110955.1430-1-david@redhat.com
    Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Pankaj Gupta <pagupta@redhat.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Arun KS <arunks@codeaurora.org>
    Cc: Mathieu Malaterre <malat@debian.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59c58e43e80fff1b4f3b0845b58dc7dbcab0d902
Author: Lijun Ou <oulijun@huawei.com>
Date:   Tue Apr 23 17:30:26 2019 +0800

    RDMA/hns: Bugfix for mapping user db
    
    [ Upstream commit 2557fabd6e29f349bfa0ac13f38ac98aa5eafc74 ]
    
    When the maximum send wr delivered by the user is zero, the qp does not
    have a sq.
    
    When allocating the sq db buffer to store the user sq pi pointer and map
    it to the kernel mode, max_send_wr is used as the trigger condition, while
    the kernel does not consider the max_send_wr trigger condition when
    mapmping db. It will cause sq record doorbell map fail and create qp fail.
    
    The failed print information as follows:
    
     hns3 0000:7d:00.1: Send cmd: tail - 418, opcode - 0x8504, flag - 0x0011, retval - 0x0000
     hns3 0000:7d:00.1: Send cmd: 0xe59dc000 0x00000000 0x00000000 0x00000000 0x00000116 0x0000ffff
     hns3 0000:7d:00.1: sq record doorbell map failed!
     hns3 0000:7d:00.1: Create RC QP failed
    
    Fixes: 0425e3e6e0c7 ("RDMA/hns: Support flush cqe for hip08 in kernel space")
    Signed-off-by: Lijun Ou <oulijun@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26f70c4e0aef85b2bf3bfedb5061bab7d9a5d8a2
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Apr 24 15:59:33 2019 +0200

    gpio: Fix gpiochip_add_data_with_key() error path
    
    [ Upstream commit 357798909164bf423eac6a78ff7da7e98d2d7f7f ]
    
    The err_remove_chip block is too coarse, and may perform cleanup that
    must not be done.  E.g. if of_gpiochip_add() fails, of_gpiochip_remove()
    is still called, causing:
    
        OF: ERROR: Bad of_node_put() on /soc/gpio@e6050000
        CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.1.0-rc2-koelsch+ #407
        Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
        Workqueue: events deferred_probe_work_func
        [<c020ec74>] (unwind_backtrace) from [<c020ae58>] (show_stack+0x10/0x14)
        [<c020ae58>] (show_stack) from [<c07c1224>] (dump_stack+0x7c/0x9c)
        [<c07c1224>] (dump_stack) from [<c07c5a80>] (kobject_put+0x94/0xbc)
        [<c07c5a80>] (kobject_put) from [<c0470420>] (gpiochip_add_data_with_key+0x8d8/0xa3c)
        [<c0470420>] (gpiochip_add_data_with_key) from [<c0473738>] (gpio_rcar_probe+0x1d4/0x314)
        [<c0473738>] (gpio_rcar_probe) from [<c052fca8>] (platform_drv_probe+0x48/0x94)
    
    and later, if a GPIO consumer tries to use a GPIO from a failed
    controller:
    
        WARNING: CPU: 0 PID: 1 at lib/refcount.c:156 kobject_get+0x38/0x4c
        refcount_t: increment on 0; use-after-free.
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc2-koelsch+ #407
        Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
        [<c020ec74>] (unwind_backtrace) from [<c020ae58>] (show_stack+0x10/0x14)
        [<c020ae58>] (show_stack) from [<c07c1224>] (dump_stack+0x7c/0x9c)
        [<c07c1224>] (dump_stack) from [<c0221580>] (__warn+0xd0/0xec)
        [<c0221580>] (__warn) from [<c02215e0>] (warn_slowpath_fmt+0x44/0x6c)
        [<c02215e0>] (warn_slowpath_fmt) from [<c07c58fc>] (kobject_get+0x38/0x4c)
        [<c07c58fc>] (kobject_get) from [<c068b3ec>] (of_node_get+0x14/0x1c)
        [<c068b3ec>] (of_node_get) from [<c0686f24>] (of_find_node_by_phandle+0xc0/0xf0)
        [<c0686f24>] (of_find_node_by_phandle) from [<c0686fbc>] (of_phandle_iterator_next+0x68/0x154)
        [<c0686fbc>] (of_phandle_iterator_next) from [<c0687fe4>] (__of_parse_phandle_with_args+0x40/0xd0)
        [<c0687fe4>] (__of_parse_phandle_with_args) from [<c0688204>] (of_parse_phandle_with_args_map+0x100/0x3ac)
        [<c0688204>] (of_parse_phandle_with_args_map) from [<c0471240>] (of_get_named_gpiod_flags+0x38/0x380)
        [<c0471240>] (of_get_named_gpiod_flags) from [<c046f864>] (gpiod_get_from_of_node+0x24/0xd8)
        [<c046f864>] (gpiod_get_from_of_node) from [<c0470aa4>] (devm_fwnode_get_index_gpiod_from_child+0xa0/0x144)
        [<c0470aa4>] (devm_fwnode_get_index_gpiod_from_child) from [<c05f425c>] (gpio_keys_probe+0x418/0x7bc)
        [<c05f425c>] (gpio_keys_probe) from [<c052fca8>] (platform_drv_probe+0x48/0x94)
    
    Fix this by splitting the cleanup block, and adding a missing call to
    gpiochip_irqchip_remove().
    
    Fixes: 28355f81969962cf ("gpio: defer probe if pinctrl cannot be found")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb53ebc9eb9a889b0db66d00932d31e3c7ad49b4
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Sat Apr 20 12:09:39 2019 +0800

    net: vrf: Fix operation not supported when set vrf mac
    
    [ Upstream commit 6819e3f6d83a24777813b0d031ebe0861694db5a ]
    
    Vrf device is not able to change mac address now because lack of
    ndo_set_mac_address. Complete this in case some apps need to do
    this.
    
    Reported-by: Hui Wang <wanghui104@huawei.com>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec69b3c91b3bc83e5bdc70c846358e4fbb30c321
Author: Pan Bian <bianpan2016@163.com>
Date:   Fri Apr 19 07:39:00 2019 +0000

    Input: synaptics-rmi4 - fix possible double free
    
    [ Upstream commit bce1a78423961fce676ac65540a31b6ffd179e6d ]
    
    The RMI4 function structure has been released in rmi_register_function
    if error occurs. However, it will be released again in the function
    rmi_create_function, which may result in a double-free bug.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a2abf951ed3970db129bf060863662121d4784f
Author: Jacky Bai <ping.bai@nxp.com>
Date:   Fri Apr 5 10:31:09 2019 -0700

    Input: snvs_pwrkey - make it depend on ARCH_MXC
    
    [ Upstream commit f06eba72274788db6a43012a05a99915c0283aef ]
    
    The SNVS power key is not only used on i.MX6SX and i.MX7D, it is also
    used by i.MX6UL and NXP's latest ARMv8 based i.MX8M series SOC. So
    update the config dependency to use ARCH_MXC, and add the COMPILE_TEST
    too.
    
    Signed-off-by: Jacky Bai <ping.bai@nxp.com>
    Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21a3f7c2c76c71d49452437735a852e3fa923c3a
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Wed Apr 24 11:04:13 2019 +0200

    drm/sun4i: Unbind components before releasing DRM and memory
    
    [ Upstream commit e02bc29b2cfa7806830d6da8b2322cddd67e8dfe ]
    
    Our components may still be using the DRM device driver (if only to
    access our driver's private data), so make sure to unbind them before
    the final drm_dev_put.
    
    Also release our reserved memory after component unbind instead of
    before to match reverse creation order.
    
    Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component master deletion")
    Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190424090413.6918-1-paul.kocialkowski@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f79084e5372b449c09d0d3771b06a3f010b924b6
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Apr 24 10:52:20 2019 +1000

    Revert "drm/virtio: drop prime import/export callbacks"
    
    [ Upstream commit a0cecc23cfcbf2626497a8c8770856dd56b67917 ]
    
    This patch does more harm than good, as it breaks both Xwayland and
    gnome-shell with X11.
    
    Xwayland requires DRI3 & DRI3 requires PRIME.
    
    X11 crash for obscure double-free reason which are hard to debug
    (starting X11 by hand doesn't trigger the crash).
    
    I don't see an apparent problem implementing those stub prime
    functions, they may return an error at run-time, and it seems to be
    handled fine by GNOME at least.
    
    This reverts commit b318e3ff7ca065d6b107e424c85a63d7a6798a69.
    [airlied:
    This broke userspace for virtio-gpus, and regressed things from DRI3 to DRI2.
    
    This brings back the original problem, but it's better than regressions.]
    
    Fixes: b318e3ff7ca065d6b107e424c85a63d7a6798a ("drm/virtio: drop prime import/export callbacks")
    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2455f6cbd19b99642f8022696fbe2094e32a813e
Author: Jeff Layton <jlayton@kernel.org>
Date:   Mon Apr 15 12:00:42 2019 -0400

    ceph: handle the case where a dentry has been renamed on outstanding req
    
    [ Upstream commit 4b8222870032715f9d995f3eb7c7acd8379a275d ]
    
    It's possible for us to issue a lookup to revalidate a dentry
    concurrently with a rename. If done in the right order, then we could
    end up processing dentry info in the reply that no longer reflects the
    state of the dentry.
    
    If req->r_dentry->d_name differs from the one in the trace, then just
    ignore the trace in the reply. We only need to do this however if the
    parent's i_rwsem is not held.
    
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3a9275364d9c4257a76fdc2290cc19586b5acf6
Author: Daniel Gomez <dagmcr@gmail.com>
Date:   Mon Apr 22 21:08:04 2019 +0200

    spi: ST ST95HF NFC: declare missing of table
    
    [ Upstream commit d04830531d0c4a99c897a44038e5da3d23331d2f ]
    
    Add missing <of_device_id> table for SPI driver relying on SPI
    device match since compatible is in a DT binding or in a DTS.
    
    Before this patch:
    modinfo drivers/nfc/st95hf/st95hf.ko | grep alias
    alias:          spi:st95hf
    
    After this patch:
    modinfo drivers/nfc/st95hf/st95hf.ko | grep alias
    alias:          spi:st95hf
    alias:          of:N*T*Cst,st95hfC*
    alias:          of:N*T*Cst,st95hf
    
    Reported-by: Javier Martinez Canillas <javier@dowhile0.org>
    Signed-off-by: Daniel Gomez <dagmcr@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 943609acd62856e3277f6cdbc6e5945fe07759f0
Author: Daniel Gomez <dagmcr@gmail.com>
Date:   Mon Apr 22 21:08:03 2019 +0200

    spi: Micrel eth switch: declare missing of table
    
    [ Upstream commit 2f23a2a768bee7ad2ff1e9527c3f7e279e794a46 ]
    
    Add missing <of_device_id> table for SPI driver relying on SPI
    device match since compatible is in a DT binding or in a DTS.
    
    Before this patch:
    modinfo drivers/net/phy/spi_ks8995.ko | grep alias
    alias:          spi:ksz8795
    alias:          spi:ksz8864
    alias:          spi:ks8995
    
    After this patch:
    modinfo drivers/net/phy/spi_ks8995.ko | grep alias
    alias:          spi:ksz8795
    alias:          spi:ksz8864
    alias:          spi:ks8995
    alias:          of:N*T*Cmicrel,ksz8795C*
    alias:          of:N*T*Cmicrel,ksz8795
    alias:          of:N*T*Cmicrel,ksz8864C*
    alias:          of:N*T*Cmicrel,ksz8864
    alias:          of:N*T*Cmicrel,ks8995C*
    alias:          of:N*T*Cmicrel,ks8995
    
    Reported-by: Javier Martinez Canillas <javier@dowhile0.org>
    Signed-off-by: Daniel Gomez <dagmcr@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c6df58231f8dde91bcd9fe712c4314d6eec06e1
Author: Tigran Tadevosyan <tigran.tadevosyan@arm.com>
Date:   Fri Apr 5 14:16:13 2019 +0100

    ARM: 8856/1: NOMMU: Fix CCR register faulty initialization when MPU is disabled
    
    [ Upstream commit c3143967807adb1357c36b68a7563fc0c4e1f615 ]
    
    When CONFIG_ARM_MPU is not defined, the base address of v7M SCB register
    is not initialized with correct value. This prevents enabling I/D caches
    when the L1 cache poilcy is applied in kernel.
    
    Fixes: 3c24121039c9da14692eb48f6e39565b28c0f3cf ("ARM: 8756/1: NOMMU: Postpone MPU activation till __after_proc_init")
    Signed-off-by: Tigran Tadevosyan <tigran.tadevosyan@arm.com>
    Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc41fe5d6fb56a13732fda728651b19045911dd7
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Apr 23 17:09:38 2019 +0100

    ARM: fix function graph tracer and unwinder dependencies
    
    [ Upstream commit 503621628b32782a07b2318e4112bd4372aa3401 ]
    
    Naresh Kamboju recently reported that the function-graph tracer crashes
    on ARM. The function-graph tracer assumes that the kernel is built with
    frame pointers.
    
    We explicitly disabled the function-graph tracer when building Thumb2,
    since the Thumb2 ABI doesn't have frame pointers.
    
    We recently changed the way the unwinder method was selected, which
    seems to have made it more likely that we can end up with the function-
    graph tracer enabled but without the kernel built with frame pointers.
    
    Fix up the function graph tracer dependencies so the option is not
    available when we have no possibility of having frame pointers, and
    adjust the dependencies on the unwinder option to hide the non-frame
    pointer unwinder options if the function-graph tracer is enabled.
    
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cb06e339cee49f6a1f865cbba2a19306cb9200c
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Apr 12 17:59:41 2019 +0200

    drm/imx: don't skip DP channel disable for background plane
    
    [ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ]
    
    In order to make sure that the plane color space gets reset correctly.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7680e881fdaa9513f1c3321ffb4ec9ac8f9208b3
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Apr 12 17:59:40 2019 +0200

    gpu: ipu-v3: dp: fix CSC handling
    
    [ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
    
    Initialize the flow input colorspaces to unknown and reset to that value
    when the channel gets disabled. This avoids the state getting mixed up
    with a previous mode.
    
    Also keep the CSC settings for the background flow intact when disabling
    the foreground flow.
    
    Root-caused-by: Jonathan Marek <jonathan@marek.ca>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28e4593bb1489f2dbb6406b4130337246e63d1a0
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri Apr 12 23:59:25 2019 -0700

    arm64/module: ftrace: deal with place relative nature of PLTs
    
    [ Upstream commit 4e69ecf4da1ee0b2ac735e1f1bb13935acd5a38d ]
    
    Another bodge for the ftrace PLT code: plt_entries_equal() now takes
    the place relative nature of the ADRP/ADD based PLT entries into
    account, which means that a struct trampoline instance on the stack
    is no longer equal to the same set of opcodes in the module struct,
    given that they don't point to the same place in memory anymore.
    
    Work around this by using memcmp() in the ftrace PLT handling code.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Tested-by: dann frazier <dann.frazier@canonical.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0f8faa2f540fcc68745ae3da1318d8f9a5ca5a5
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Mon Apr 1 20:38:19 2019 +0200

    dmaengine: bcm2835: Avoid GFP_KERNEL in device_prep_slave_sg
    
    [ Upstream commit f147384774a7b24dda4783a3dcd61af272757ea8 ]
    
    The commit af19b7ce76ba ("mmc: bcm2835: Avoid possible races on
    data requests") introduces a possible circular locking dependency,
    which is triggered by swapping to the sdhost interface.
    
    So instead of reintroduce the race condition again, we could also
    avoid this situation by using GFP_NOWAIT for the allocation of the
    DMA buffer descriptors.
    
    Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Fixes: af19b7ce76ba ("mmc: bcm2835: Avoid possible races on data requests")
    Link: http://lists.infradead.org/pipermail/linux-rpi-kernel/2019-March/008615.html
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4dc7d99b111b2a14c3054175998f5d7664455c9
Author: Andrei Vagin <avagin@gmail.com>
Date:   Wed Apr 17 09:49:44 2019 -0700

    netfilter: fix nf_l4proto_log_invalid to log invalid packets
    
    [ Upstream commit d48668052b2603b6262459625c86108c493588dd ]
    
    It doesn't log a packet if sysctl_log_invalid isn't equal to protonum
    OR sysctl_log_invalid isn't equal to IPPROTO_RAW. This sentence is
    always true. I believe we need to replace OR to AND.
    
    Cc: Florian Westphal <fw@strlen.de>
    Fixes: c4f3db1595827 ("netfilter: conntrack: add and use nf_l4proto_log_invalid")
    Signed-off-by: Andrei Vagin <avagin@gmail.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddb632889faeb7fb462b3e3e814f0a51186a8ad4
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Apr 17 02:17:23 2019 +0200

    netfilter: never get/set skb->tstamp
    
    [ Upstream commit 916f6efae62305796e012e7c3a7884a267cbacbf ]
    
    setting net.netfilter.nf_conntrack_timestamp=1 breaks xmit with fq
    scheduler.  skb->tstamp might be "refreshed" using ktime_get_real(),
    but fq expects CLOCK_MONOTONIC.
    
    This patch removes all places in netfilter that check/set skb->tstamp:
    
    1. To fix the bogus "start" time seen with conntrack timestamping for
       outgoing packets, never use skb->tstamp and always use current time.
    2. In nfqueue and nflog, only use skb->tstamp for incoming packets,
       as determined by current hook (prerouting, input, forward).
    3. xt_time has to use system clock as well rather than skb->tstamp.
       We could still use skb->tstamp for prerouting/input/foward, but
       I see no advantage to make this conditional.
    
    Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC")
    Cc: Eric Dumazet <edumazet@google.com>
    Reported-by: Michal Soltys <soltys@ziu.info>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 226ef4f27a451262bd6199fd0022aa22c4065393
Author: Po-Hsu Lin <po-hsu.lin@canonical.com>
Date:   Fri Apr 19 19:01:13 2019 +0800

    selftests/net: correct the return value for run_afpackettests
    
    [ Upstream commit 8c03557c3f25271e62e39154af66ebdd1b59c9ca ]
    
    The run_afpackettests will be marked as passed regardless the return
    value of those sub-tests in the script:
        --------------------
        running psock_tpacket test
        --------------------
        [FAIL]
        selftests: run_afpackettests [PASS]
    
    Fix this by changing the return value for each tests.
    
    Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a20185157b5b4204922cd7be240d83d451ef6a2
Author: Po-Hsu Lin <po-hsu.lin@canonical.com>
Date:   Thu Apr 18 19:57:25 2019 +0800

    selftests/net: correct the return value for run_netsocktests
    
    [ Upstream commit 30c04d796b693e22405c38e9b78e9a364e4c77e6 ]
    
    The run_netsocktests will be marked as passed regardless the actual test
    result from the ./socket:
    
        selftests: net: run_netsocktests
        ========================================
        --------------------
        running socket test
        --------------------
        [FAIL]
        ok 1..6 selftests: net: run_netsocktests [PASS]
    
    This is because the test script itself has been successfully executed.
    Fix this by exit 1 when the test failed.
    
    Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d83e90c2375db836438d14c7d9ecf1e845c7400
Author: Petr Štetiar <ynezz@true.cz>
Date:   Wed Apr 17 22:09:12 2019 +0200

    of_net: Fix residues after of_get_nvmem_mac_address removal
    
    [ Upstream commit 36ad7022536e0c65f8baeeaa5efde11dec44808a ]
    
    I've discovered following discrepancy in the bindings/net/ethernet.txt
    documentation, where it states following:
    
     - nvmem-cells: phandle, reference to an nvmem node for the MAC address;
     - nvmem-cell-names: string, should be "mac-address" if nvmem is to be..
    
    which is actually misleading and confusing. There are only two ethernet
    drivers in the tree, cadence/macb and davinci which supports this
    properties.
    
    This nvmem-cell* properties were introduced in commit 9217e566bdee
    ("of_net: Implement of_get_nvmem_mac_address helper"), but
    commit afa64a72b862 ("of: net: kill of_get_nvmem_mac_address()")
    forget to properly clean up this parts.
    
    So this patch fixes the documentation by moving the nvmem-cell*
    properties at the appropriate places.  While at it, I've removed unused
    include as well.
    
    Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Fixes: afa64a72b862 ("of: net: kill of_get_nvmem_mac_address()")
    Signed-off-by: Petr Štetiar <ynezz@true.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ba51c0e84b385eefb145afe584180c227dbce99
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Thu Apr 18 15:27:27 2019 +0200

    drm/sun4i: Fix component unbinding and component master deletion
    
    [ Upstream commit f5a9ed867c83875546c9aadd4ed8e785e9adcc3c ]
    
    For our component-backed driver to be properly removed, we need to
    delete the component master in sun4i_drv_remove and make sure to call
    component_unbind_all in the master's unbind so that all components are
    unbound when the master is.
    
    Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
    Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-4-paul.kocialkowski@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3000bdec55c83f85d457d669a9f633f0594c21ea
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Thu Apr 18 15:27:26 2019 +0200

    drm/sun4i: Set device driver data at bind time for use in unbind
    
    [ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
    
    Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
    However, that driver data is never set in sun4i_drv_bind.
    
    Set it there to avoid getting a NULL pointer at unbind time.
    
    Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
    Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-3-paul.kocialkowski@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1330679d64f83741b1512eeb87d2ea305ea5c7f1
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 17 18:29:13 2019 +0200

    s390: ctcm: fix ctcm_new_device error return code
    
    [ Upstream commit 27b141fc234a3670d21bd742c35d7205d03cbb3a ]
    
    clang points out that the return code from this function is
    undefined for one of the error paths:
    
    ../drivers/s390/net/ctcm_main.c:1595:7: warning: variable 'result' is used uninitialized whenever 'if' condition is true
          [-Wsometimes-uninitialized]
                    if (priv->channel[direction] == NULL) {
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../drivers/s390/net/ctcm_main.c:1638:9: note: uninitialized use occurs here
            return result;
                   ^~~~~~
    ../drivers/s390/net/ctcm_main.c:1595:3: note: remove the 'if' if its condition is always false
                    if (priv->channel[direction] == NULL) {
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../drivers/s390/net/ctcm_main.c:1539:12: note: initialize the variable 'result' to silence this warning
            int result;
                      ^
    
    Make it return -ENODEV here, as in the related failure cases.
    gcc has a known bug in underreporting some of these warnings
    when it has already eliminated the assignment of the return code
    based on some earlier optimization step.
    
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 143c8279955e7a8c614d5912d001e2478b1af271
Author: Guy Levi <guyle@mellanox.com>
Date:   Wed Apr 10 10:59:45 2019 +0300

    IB/mlx5: Fix scatter to CQE in DCT QP creation
    
    [ Upstream commit 7249c8ea227a582c14f63e9e8853eb7369122f10 ]
    
    When scatter to CQE is enabled on a DCT QP it corrupts the mailbox command
    since it tried to treat it as as QP create mailbox command instead of a
    DCT create command.
    
    The corrupted mailbox command causes userspace to malfunction as the
    device doesn't create the QP as expected.
    
    A new mlx5 capability is exposed to user-space which ensures that it will
    not enable the feature on DCT without this fix in the kernel.
    
    Fixes: 5d6ff1babe78 ("IB/mlx5: Support scatter to CQE for DC transport type")
    Signed-off-by: Guy Levi <guyle@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 b3a64096c5ee90e76bb27c72f2af9d2d28e04f22
Author: Petr Štetiar <ynezz@true.cz>
Date:   Fri Apr 12 23:08:32 2019 +0200

    MIPS: perf: ath79: Fix perfcount IRQ assignment
    
    [ Upstream commit a1e8783db8e0d58891681bc1e6d9ada66eae8e20 ]
    
    Currently it's not possible to use perf on ath79 due to genirq flags
    mismatch happening on static virtual IRQ 13 which is used for
    performance counters hardware IRQ 5.
    
    On TP-Link Archer C7v5:
    
               CPU0
      2:          0      MIPS   2  ath9k
      4:        318      MIPS   4  19000000.eth
      7:      55034      MIPS   7  timer
      8:       1236      MISC   3  ttyS0
     12:          0      INTC   1  ehci_hcd:usb1
     13:          0  gpio-ath79   2  keys
     14:          0  gpio-ath79   5  keys
     15:         31  AR724X PCI    1  ath10k_pci
    
     $ perf top
     genirq: Flags mismatch irq 13. 00014c83 (mips_perf_pmu) vs. 00002003 (keys)
    
    On TP-Link Archer C7v4:
    
             CPU0
      4:          0      MIPS   4  19000000.eth
      5:       7135      MIPS   5  1a000000.eth
      7:      98379      MIPS   7  timer
      8:         30      MISC   3  ttyS0
     12:      90028      INTC   0  ath9k
     13:       5520      INTC   1  ehci_hcd:usb1
     14:       4623      INTC   2  ehci_hcd:usb2
     15:      32844  AR724X PCI    1  ath10k_pci
     16:          0  gpio-ath79  16  keys
     23:          0  gpio-ath79  23  keys
    
     $ perf top
     genirq: Flags mismatch irq 13. 00014c80 (mips_perf_pmu) vs. 00000080 (ehci_hcd:usb1)
    
    This problem is happening, because currently statically assigned virtual
    IRQ 13 for performance counters is not claimed during the initialization
    of MIPS PMU during the bootup, so the IRQ subsystem doesn't know, that
    this interrupt isn't available for further use.
    
    So this patch fixes the issue by simply booking hardware IRQ 5 for MIPS PMU.
    
    Tested-by: Kevin 'ldir' Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
    Signed-off-by: Petr Štetiar <ynezz@true.cz>
    Acked-by: John Crispin <john@phrozen.org>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: linux-mips@vger.kernel.org
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecef50c35a07b396fa8977c2312b1f83702fb01e
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Apr 9 14:45:20 2019 +0200

    netfilter: nat: fix icmp id randomization
    
    [ Upstream commit 5bdac418f33f60b07a34e01e722889140ee8fac9 ]
    
    Sven Auhagen reported that a 2nd ping request will fail if 'fully-random'
    mode is used.
    
    Reason is that if no proto information is given, min/max are both 0,
    so we set the icmp id to 0 instead of chosing a random value between
    0 and 65535.
    
    Update test case as well to catch this, without fix this yields:
    [..]
    ERROR: cannot ping ns1 from ns2 with ip masquerade fully-random (attempt 2)
    ERROR: cannot ping ns1 from ns2 with ipv6 masquerade fully-random (attempt 2)
    
    ... becaus 2nd ping clashes with existing 'id 0' icmp conntrack and gets
    dropped.
    
    Fixes: 203f2e78200c27e ("netfilter: nat: remove l4proto->unique_tuple")
    Reported-by: Sven Auhagen <sven.auhagen@voleatech.de>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2987d193f8b1c0f3d59362684798e37049079a3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Apr 6 08:26:52 2019 +0300

    netfilter: nf_tables: prevent shift wrap in nft_chain_parse_hook()
    
    [ Upstream commit 33d1c018179d0a30c39cc5f1682b77867282694b ]
    
    I believe that "hook->num" can be up to UINT_MAX.  Shifting more than
    31 bits would is undefined in C but in practice it would lead to shift
    wrapping.  That would lead to an array overflow in nf_tables_addchain():
    
            ops->hook       = hook.type->hooks[ops->hooknum];
    
    Fixes: fe19c04ca137 ("netfilter: nf_tables: remove nhooks field from struct nft_af_info")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0a90cae081d7ee14eaa46524fb70f4e23ae8905
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Apr 1 13:08:54 2019 +0200

    netfilter: ctnetlink: don't use conntrack/expect object addresses as id
    
    [ Upstream commit 3c79107631db1f7fd32cf3f7368e4672004a3010 ]
    
    else, we leak the addresses to userspace via ctnetlink events
    and dumps.
    
    Compute an ID on demand based on the immutable parts of nf_conn struct.
    
    Another advantage compared to using an address is that there is no
    immediate re-use of the same ID in case the conntrack entry is freed and
    reallocated again immediately.
    
    Fixes: 3583240249ef ("[NETFILTER]: nf_conntrack_expect: kill unique ID")
    Fixes: 7f85f914721f ("[NETFILTER]: nf_conntrack: kill unique ID")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3a5ad78488b6c8ef1cb8d3def72df64a05fbf98
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sun Mar 31 13:24:52 2019 +0300

    ipvs: do not schedule icmp errors from tunnels
    
    [ Upstream commit 0261ea1bd1eb0da5c0792a9119b8655cf33c80a3 ]
    
    We can receive ICMP errors from client or from
    tunneling real server. While the former can be
    scheduled to real server, the latter should
    not be scheduled, they are decapsulated only when
    existing connection is found.
    
    Fixes: 6044eeffafbe ("ipvs: attempt to schedule icmp packets")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44fbb3db2bdea2734c31c52b1390c8daf8be6f05
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Mar 25 23:11:53 2019 +0100

    selftests: netfilter: check icmp pkttoobig errors are set as related
    
    [ Upstream commit becf2319f320cae43e20cf179cc51a355a0deb5f ]
    
    When an icmp error such as pkttoobig is received, conntrack checks
    if the "inner" header (header of packet that did not fit link mtu)
    is matches an existing connection, and, if so, sets that packet as
    being related to the conntrack entry it found.
    
    It was recently reported that this "related" setting also works
    if the inner header is from another, different connection (i.e.,
    artificial/forged icmp error).
    
    Add a test, followup patch will add additional "inner dst matches
    outer dst in reverse direction" check before setting related state.
    
    Link: https://www.synacktiv.com/posts/systems/icmp-reachable.html
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16b01614d36984ff86a1f5eb8c3f2a61fcd50114
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Feb 20 07:52:31 2019 +0000

    drm: bridge: dw-hdmi: Fix overflow workaround for Rockchip SoCs
    
    [ Upstream commit d15d9fd02575ecfada92d42f655940c4f10af842 ]
    
    The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
    also been identified as needing this workaround with a single iteration.
    
    Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on device version")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Tested-by: Heiko Stueber <heiko@sntech.de>
    Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/AM3PR03MB0966818FAAAE6192FF4ED11AAC7D0@AM3PR03MB0966.eurprd03.prod.outlook.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bc0352515ef810f7513adfcae84ca4fd00c67aa
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Apr 18 17:50:44 2019 -0700

    init: initialize jump labels before command line option parsing
    
    [ Upstream commit 6041186a32585fc7a1d0f6cfe2f138b05fdc3c82 ]
    
    When a module option, or core kernel argument, toggles a static-key it
    requires jump labels to be initialized early.  While x86, PowerPC, and
    ARM64 arrange for jump_label_init() to be called before parse_args(),
    ARM does not.
    
      Kernel command line: rdinit=/sbin/init page_alloc.shuffle=1 panic=-1 console=ttyAMA0,115200 page_alloc.shuffle=1
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:303
      page_alloc_shuffle+0x12c/0x1ac
      static_key_enable(): static key 'page_alloc_shuffle_key+0x0/0x4' used
      before call to jump_label_init()
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted
      5.1.0-rc4-next-20190410-00003-g3367c36ce744 #1
      Hardware name: ARM Integrator/CP (Device Tree)
      [<c0011c68>] (unwind_backtrace) from [<c000ec48>] (show_stack+0x10/0x18)
      [<c000ec48>] (show_stack) from [<c07e9710>] (dump_stack+0x18/0x24)
      [<c07e9710>] (dump_stack) from [<c001bb1c>] (__warn+0xe0/0x108)
      [<c001bb1c>] (__warn) from [<c001bb88>] (warn_slowpath_fmt+0x44/0x6c)
      [<c001bb88>] (warn_slowpath_fmt) from [<c0b0c4a8>]
      (page_alloc_shuffle+0x12c/0x1ac)
      [<c0b0c4a8>] (page_alloc_shuffle) from [<c0b0c550>] (shuffle_store+0x28/0x48)
      [<c0b0c550>] (shuffle_store) from [<c003e6a0>] (parse_args+0x1f4/0x350)
      [<c003e6a0>] (parse_args) from [<c0ac3c00>] (start_kernel+0x1c0/0x488)
    
    Move the fallback call to jump_label_init() to occur before
    parse_args().
    
    The redundant calls to jump_label_init() in other archs are left intact
    in case they have static key toggling use cases that are even earlier
    than option parsing.
    
    Link: http://lkml.kernel.org/r/155544804466.1032396.13418949511615676665.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Guenter Roeck <groeck@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Russell King <rmk@armlinux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57c2301fc9c93484cecb928f467ca6128fa0b1a3
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Apr 18 17:50:34 2019 -0700

    mm: fix inactive list balancing between NUMA nodes and cgroups
    
    [ Upstream commit 3b991208b897f52507168374033771a984b947b1 ]
    
    During !CONFIG_CGROUP reclaim, we expand the inactive list size if it's
    thrashing on the node that is about to be reclaimed.  But when cgroups
    are enabled, we suddenly ignore the node scope and use the cgroup scope
    only.  The result is that pressure bleeds between NUMA nodes depending
    on whether cgroups are merely compiled into Linux.  This behavioral
    difference is unexpected and undesirable.
    
    When the refault adaptivity of the inactive list was first introduced,
    there were no statistics at the lruvec level - the intersection of node
    and memcg - so it was better than nothing.
    
    But now that we have that infrastructure, use lruvec_page_state() to
    make the list balancing decision always NUMA aware.
    
    [hannes@cmpxchg.org: fix bisection hole]
      Link: http://lkml.kernel.org/r/20190417155241.GB23013@cmpxchg.org
    Link: http://lkml.kernel.org/r/20190412144438.2645-1-hannes@cmpxchg.org
    Fixes: 2a2e48854d70 ("mm: vmscan: fix IO/refault regression in cache workingset transition")
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47d1b202e3254536af7bf53cddbdc57fad8e776e
Author: Qian Cai <cai@lca.pw>
Date:   Thu Apr 18 17:50:30 2019 -0700

    mm/hotplug: treat CMA pages as unmovable
    
    [ Upstream commit 1a9f219157b22d0ffb340a9c5f431afd02cd2cf3 ]
    
    has_unmovable_pages() is used by allocating CMA and gigantic pages as
    well as the memory hotplug.  The later doesn't know how to offline CMA
    pool properly now, but if an unused (free) CMA page is encountered, then
    has_unmovable_pages() happily considers it as a free memory and
    propagates this up the call chain.  Memory offlining code then frees the
    page without a proper CMA tear down which leads to an accounting issues.
    Moreover if the same memory range is onlined again then the memory never
    gets back to the CMA pool.
    
    State after memory offline:
    
     # grep cma /proc/vmstat
     nr_free_cma 205824
    
     # cat /sys/kernel/debug/cma/cma-kvm_cma/count
     209920
    
    Also, kmemleak still think those memory address are reserved below but
    have already been used by the buddy allocator after onlining.  This
    patch fixes the situation by treating CMA pageblocks as unmovable except
    when has_unmovable_pages() is called as part of CMA allocation.
    
      Offlined Pages 4096
      kmemleak: Cannot insert 0xc000201f7d040008 into the object search tree (overlaps existing)
      Call Trace:
        dump_stack+0xb0/0xf4 (unreliable)
        create_object+0x344/0x380
        __kmalloc_node+0x3ec/0x860
        kvmalloc_node+0x58/0x110
        seq_read+0x41c/0x620
        __vfs_read+0x3c/0x70
        vfs_read+0xbc/0x1a0
        ksys_read+0x7c/0x140
        system_call+0x5c/0x70
      kmemleak: Kernel memory leak detector disabled
      kmemleak: Object 0xc000201cc8000000 (size 13757317120):
      kmemleak:   comm "swapper/0", pid 0, jiffies 4294937297
      kmemleak:   min_count = -1
      kmemleak:   count = 0
      kmemleak:   flags = 0x5
      kmemleak:   checksum = 0
      kmemleak:   backtrace:
           cma_declare_contiguous+0x2a4/0x3b0
           kvm_cma_reserve+0x11c/0x134
           setup_arch+0x300/0x3f8
           start_kernel+0x9c/0x6e8
           start_here_common+0x1c/0x4b0
      kmemleak: Automatic memory scanning thread ended
    
    [cai@lca.pw: use is_migrate_cma_page() and update commit log]
      Link: http://lkml.kernel.org/r/20190416170510.20048-1-cai@lca.pw
    Link: http://lkml.kernel.org/r/20190413002623.8967-1-cai@lca.pw
    Signed-off-by: Qian Cai <cai@lca.pw>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 247e9fe2f4ad55d591264358368aa307bf81481b
Author: Qian Cai <cai@lca.pw>
Date:   Thu Apr 18 17:49:55 2019 -0700

    slab: store tagged freelist for off-slab slabmgmt
    
    [ Upstream commit 1a62b18d51e5c5ecc0345c85bb9fef870ab721ed ]
    
    Commit 51dedad06b5f ("kasan, slab: make freelist stored without tags")
    calls kasan_reset_tag() for off-slab slab management object leading to
    freelist being stored non-tagged.
    
    However, cache_grow_begin() calls alloc_slabmgmt() which calls
    kmem_cache_alloc_node() assigns a tag for the address and stores it in
    the shadow address.  As the result, it causes endless errors below
    during boot due to drain_freelist() -> slab_destroy() ->
    kasan_slab_free() which compares already untagged freelist against the
    stored tag in the shadow address.
    
    Since off-slab slab management object freelist is such a special case,
    just store it tagged.  Non-off-slab management object freelist is still
    stored untagged which has not been assigned a tag and should not cause
    any other troubles with this inconsistency.
    
      BUG: KASAN: double-free or invalid-free in slab_destroy+0x84/0x88
      Pointer tag: [ff], memory tag: [99]
    
      CPU: 0 PID: 1376 Comm: kworker/0:4 Tainted: G        W 5.1.0-rc3+ #8
      Hardware name: HPE Apollo 70             /C01_APACHE_MB         , BIOS L50_5.13_1.0.6 07/10/2018
      Workqueue: cgroup_destroy css_killed_work_fn
      Call trace:
       print_address_description+0x74/0x2a4
       kasan_report_invalid_free+0x80/0xc0
       __kasan_slab_free+0x204/0x208
       kasan_slab_free+0xc/0x18
       kmem_cache_free+0xe4/0x254
       slab_destroy+0x84/0x88
       drain_freelist+0xd0/0x104
       __kmem_cache_shrink+0x1ac/0x224
       __kmemcg_cache_deactivate+0x1c/0x28
       memcg_deactivate_kmem_caches+0xa0/0xe8
       memcg_offline_kmem+0x8c/0x3d4
       mem_cgroup_css_offline+0x24c/0x290
       css_killed_work_fn+0x154/0x618
       process_one_work+0x9cc/0x183c
       worker_thread+0x9b0/0xe38
       kthread+0x374/0x390
       ret_from_fork+0x10/0x18
    
      Allocated by task 1625:
       __kasan_kmalloc+0x168/0x240
       kasan_slab_alloc+0x18/0x20
       kmem_cache_alloc_node+0x1f8/0x3a0
       cache_grow_begin+0x4fc/0xa24
       cache_alloc_refill+0x2f8/0x3e8
       kmem_cache_alloc+0x1bc/0x3bc
       sock_alloc_inode+0x58/0x334
       alloc_inode+0xb8/0x164
       new_inode_pseudo+0x20/0xec
       sock_alloc+0x74/0x284
       __sock_create+0xb0/0x58c
       sock_create+0x98/0xb8
       __sys_socket+0x60/0x138
       __arm64_sys_socket+0xa4/0x110
       el0_svc_handler+0x2c0/0x47c
       el0_svc+0x8/0xc
    
      Freed by task 1625:
       __kasan_slab_free+0x114/0x208
       kasan_slab_free+0xc/0x18
       kfree+0x1a8/0x1e0
       single_release+0x7c/0x9c
       close_pdeo+0x13c/0x43c
       proc_reg_release+0xec/0x108
       __fput+0x2f8/0x784
       ____fput+0x1c/0x28
       task_work_run+0xc0/0x1b0
       do_notify_resume+0xb44/0x1278
       work_pending+0x8/0x10
    
      The buggy address belongs to the object at ffff809681b89e00
       which belongs to the cache kmalloc-128 of size 128
      The buggy address is located 0 bytes inside of
       128-byte region [ffff809681b89e00, ffff809681b89e80)
      The buggy address belongs to the page:
      page:ffff7fe025a06e00 count:1 mapcount:0 mapping:01ff80082000fb00
      index:0xffff809681b8fe04
      flags: 0x17ffffffc000200(slab)
      raw: 017ffffffc000200 ffff7fe025a06d08 ffff7fe022ef7b88 01ff80082000fb00
      raw: ffff809681b8fe04 ffff809681b80000 00000001000000e0 0000000000000000
      page dumped because: kasan: bad access detected
      page allocated via order 0, migratetype Unmovable, gfp_mask
      0x2420c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_COMP|__GFP_THISNODE)
       prep_new_page+0x4e0/0x5e0
       get_page_from_freelist+0x4ce8/0x50d4
       __alloc_pages_nodemask+0x738/0x38b8
       cache_grow_begin+0xd8/0xa24
       ____cache_alloc_node+0x14c/0x268
       __kmalloc+0x1c8/0x3fc
       ftrace_free_mem+0x408/0x1284
       ftrace_free_init_mem+0x20/0x28
       kernel_init+0x24/0x548
       ret_from_fork+0x10/0x18
    
      Memory state around the buggy address:
       ffff809681b89c00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
       ffff809681b89d00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
      >ffff809681b89e00: 99 99 99 99 99 99 99 99 fe fe fe fe fe fe fe fe
                         ^
       ffff809681b89f00: 43 43 43 43 43 fe fe fe fe fe fe fe fe fe fe fe
       ffff809681b8a000: 6d fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
    
    Link: http://lkml.kernel.org/r/20190403022858.97584-1-cai@lca.pw
    Fixes: 51dedad06b5f ("kasan, slab: make freelist stored without tags")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4176e671a44e6bc7be6ac4c77abe6113437a79f2
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Apr 18 18:13:58 2019 +0200

    scsi: aic7xxx: fix EISA support
    
    [ Upstream commit 144ec97493af34efdb77c5aba146e9c7de8d0a06 ]
    
    Instead of relying on the now removed NULL argument to
    pci_alloc_consistent, switch to the generic DMA API, and store the struct
    device so that we can pass it.
    
    Fixes: 4167b2ad5182 ("PCI: Remove NULL device handling from PCI DMA API")
    Reported-by: Matthew Whitehead <tedheadster@gmail.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Tested-by: Matthew Whitehead <tedheadster@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9697ba264c288144aced5f9cc05d1d9f51d026d
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Apr 16 18:01:24 2019 +0200

    perf tools: Fix map reference counting
    
    [ Upstream commit b9abbdfa88024d52c8084d8f46ea4f161606c692 ]
    
    By calling maps__insert() we assume to get 2 references on the map,
    which we relese within maps__remove call.
    
    However if there's already same map name, we currently don't bump the
    reference and can crash, like:
    
      Program received signal SIGABRT, Aborted.
      0x00007ffff75e60f5 in raise () from /lib64/libc.so.6
    
      (gdb) bt
      #0  0x00007ffff75e60f5 in raise () from /lib64/libc.so.6
      #1  0x00007ffff75d0895 in abort () from /lib64/libc.so.6
      #2  0x00007ffff75d0769 in __assert_fail_base.cold () from /lib64/libc.so.6
      #3  0x00007ffff75de596 in __assert_fail () from /lib64/libc.so.6
      #4  0x00000000004fc006 in refcount_sub_and_test (i=1, r=0x1224e88) at tools/include/linux/refcount.h:131
      #5  refcount_dec_and_test (r=0x1224e88) at tools/include/linux/refcount.h:148
      #6  map__put (map=0x1224df0) at util/map.c:299
      #7  0x00000000004fdb95 in __maps__remove (map=0x1224df0, maps=0xb17d80) at util/map.c:953
      #8  maps__remove (maps=0xb17d80, map=0x1224df0) at util/map.c:959
      #9  0x00000000004f7d8a in map_groups__remove (map=<optimized out>, mg=<optimized out>) at util/map_groups.h:65
      #10 machine__process_ksymbol_unregister (sample=<optimized out>, event=0x7ffff7279670, machine=<optimized out>) at util/machine.c:728
      #11 machine__process_ksymbol (machine=<optimized out>, event=0x7ffff7279670, sample=<optimized out>) at util/machine.c:741
      #12 0x00000000004fffbb in perf_session__deliver_event (session=0xb11390, event=0x7ffff7279670, tool=0x7fffffffc7b0, file_offset=13936) at util/session.c:1362
      #13 0x00000000005039bb in do_flush (show_progress=false, oe=0xb17e80) at util/ordered-events.c:243
      #14 __ordered_events__flush (oe=0xb17e80, how=OE_FLUSH__ROUND, timestamp=<optimized out>) at util/ordered-events.c:322
      #15 0x00000000005005e4 in perf_session__process_user_event (session=session@entry=0xb11390, event=event@entry=0x7ffff72a4af8,
      ...
    
    Add the map to the list and getting the reference event if we find the
    map with same name.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <songliubraving@fb.com>
    Fixes: 1e6285699b30 ("perf symbols: Fix slowness due to -ffunction-section")
    Link: http://lkml.kernel.org/r/20190416160127.30203-10-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d39036685e2253143901355a6d942150337d1a89
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Tue Apr 16 17:51:58 2019 +0300

    ocelot: Don't sleep in atomic context (irqs_disabled())
    
    [ Upstream commit a8fd48b50deaa20808bbf0f6685f6f1acba6a64c ]
    
    Preemption disabled at:
     [<ffff000008cabd54>] dev_set_rx_mode+0x1c/0x38
     Call trace:
     [<ffff00000808a5c0>] dump_backtrace+0x0/0x3d0
     [<ffff00000808a9a4>] show_stack+0x14/0x20
     [<ffff000008e6c0c0>] dump_stack+0xac/0xe4
     [<ffff0000080fe76c>] ___might_sleep+0x164/0x238
     [<ffff0000080fe890>] __might_sleep+0x50/0x88
     [<ffff0000082261e4>] kmem_cache_alloc+0x17c/0x1d0
     [<ffff000000ea0ae8>] ocelot_set_rx_mode+0x108/0x188 [mscc_ocelot_common]
     [<ffff000008cabcf0>] __dev_set_rx_mode+0x58/0xa0
     [<ffff000008cabd5c>] dev_set_rx_mode+0x24/0x38
    
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7200d0648e5c2cc575f1516712fedaa6468cc2e
Author: Tony Camuso <tcamuso@redhat.com>
Date:   Tue Apr 9 15:20:03 2019 -0400

    ipmi: ipmi_si_hardcode.c: init si_type array to fix a crash
    
    [ Upstream commit a885bcfd152f97b25005298ab2d6b741aed9b49c ]
    
    The intended behavior of function ipmi_hardcode_init_one() is to default
    to kcs interface when no type argument is presented when initializing
    ipmi with hard coded addresses.
    
    However, the array of char pointers allocated on the stack by function
    ipmi_hardcode_init() was not inited to zeroes, so it contained stack
    debris.
    
    Consequently, passing the cruft stored in this array to function
    ipmi_hardcode_init_one() caused a crash when it was unable to detect
    that the char * being passed was nonsense and tried to access the
    address specified by the bogus pointer.
    
    The fix is simply to initialize the si_type array to zeroes, so if
    there were no type argument given to at the command line, function
    ipmi_hardcode_init_one() could properly default to the kcs interface.
    
    Signed-off-by: Tony Camuso <tcamuso@redhat.com>
    Message-Id: <1554837603-40299-1-git-send-email-tcamuso@redhat.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2ae8127d693545cdc7cb36516f00699bd66aa6b
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Mon Apr 15 14:53:33 2019 +0200

    perf top: Always sample time to satisfy needs of use of ordered queuing
    
    [ Upstream commit 1e6db2ee86e6a4399fc0ae5689e55e0fd1c43caf ]
    
    Bastian reported broken 'perf top -p PID' command, it won't display any
    data.
    
    The problem is that for -p option we monitor single thread, so we don't
    enable time in samples, because it's not needed.
    
    However since commit 16c66bc167cc we use ordered queues to stash data
    plus later commits added logic for dropping samples in case there's big
    load and we don't keep up. All this needs timestamp for sample. Enabling
    it unconditionally for perf top.
    
    Reported-by: Bastian Beischer <bastian.beischer@rwth-aachen.de>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: bastian beischer <bastian.beischer@rwth-aachen.de>
    Fixes: 16c66bc167cc ("perf top: Add processing thread")
    Link: http://lkml.kernel.org/r/20190415125333.27160-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b2395e2bfec918b2f3c1226957976a4a514fe10
Author: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Date:   Tue Apr 9 11:15:29 2019 +0200

    tools lib traceevent: Fix missing equality check for strcmp
    
    [ Upstream commit f32c2877bcb068a718bb70094cd59ccc29d4d082 ]
    
    There was a missing comparison with 0 when checking if type is "s64" or
    "u64". Therefore, the body of the if-statement was entered if "type" was
    "u64" or not "s64", which made the first strcmp() redundant since if
    type is "u64", it's not "s64".
    
    If type is "s64", the body of the if-statement is not entered but since
    the remainder of the function consists of if-statements which will not
    be entered if type is "s64", we will just return "val", which is
    correct, albeit at the cost of a few more calls to strcmp(), i.e., it
    will behave just as if the if-statement was entered.
    
    If type is neither "s64" or "u64", the body of the if-statement will be
    entered incorrectly and "val" returned. This means that any type that is
    checked after "s64" and "u64" is handled the same way as "s64" and
    "u64", i.e., the limiting of "val" to fit in for example "s8" is never
    reached.
    
    This was introduced in the kernel tree when the sources were copied from
    trace-cmd in commit f7d82350e597 ("tools/events: Add files to create
    libtraceevent.a"), and in the trace-cmd repo in 1cdbae6035cei
    ("Implement typecasting in parser") when the function was introduced,
    i.e., it has always behaved the wrong way.
    
    Detected by cppcheck.
    
    Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Tzvetomir Stoyanov <tstoyanov@vmware.com>
    Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a")
    Link: http://lkml.kernel.org/r/20190409091529.2686-1-rikard.falkeborn@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b053700b6ce94ca0503594564b39c40e12cc187a
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Wed Mar 27 15:12:20 2019 +0100

    KVM: x86: avoid misreporting level-triggered irqs as edge-triggered in tracing
    
    [ Upstream commit 7a223e06b1a411cef6c4cd7a9b9a33c8d225b10e ]
    
    In __apic_accept_irq() interface trig_mode is int and actually on some code
    paths it is set above u8:
    
    kvm_apic_set_irq() extracts it from 'struct kvm_lapic_irq' where trig_mode
    is u16. This is done on purpose as e.g. kvm_set_msi_irq() sets it to
    (1 << 15) & e->msi.data
    
    kvm_apic_local_deliver sets it to reg & (1 << 15).
    
    Fix the immediate issue by making 'tm' into u16. We may also want to adjust
    __apic_accept_irq() interface and use proper sizes for vector, level,
    trig_mode but this is not urgent.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cee966029037a183d98cb88251ceb92a233fe63
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Apr 11 11:16:47 2019 +0200

    KVM: fix spectrev1 gadgets
    
    [ Upstream commit 1d487e9bf8ba66a7174c56a0029c54b1eca8f99c ]
    
    These were found with smatch, and then generalized when applicable.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac0cd21ff7f3fedd07c74314d3b638f041e68021
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Apr 15 15:57:19 2019 +0200

    KVM: nVMX: always use early vmcs check when EPT is disabled
    
    [ Upstream commit 2b27924bb1d48e3775f432b70bdad5e6dd4e7798 ]
    
    The remaining failures of vmx.flat when EPT is disabled are caused by
    incorrectly reflecting VMfails to the L1 hypervisor.  What happens is
    that nested_vmx_restore_host_state corrupts the guest CR3, reloading it
    with the host's shadow CR3 instead, because it blindly loads GUEST_CR3
    from the vmcs01.
    
    For simplicity let's just always use hardware VMCS checks when EPT is
    disabled.  This way, nested_vmx_restore_host_state is not reached at
    all (or at least shouldn't be reached).
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad0b4845927e1e57994af11a52412ae22ba4b8a4
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Fri Apr 12 16:01:53 2019 +0800

    x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T
    
    [ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]
    
    Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
    shutdown process, but then it hangs in BIOS POST with a black screen.
    
    The problem is intermittent - at some points it has appeared related to
    Secure Boot settings or different kernel builds, but ultimately we have
    not been able to identify the exact conditions that trigger the issue to
    come and go.
    
    Besides, the EFI mode cannot be disabled in the BIOS of this model.
    
    However, after extensive testing, we observe that using the EFI reboot
    method reliably avoids the issue in all cases.
    
    So add a boot time quirk to use EFI reboot on such systems.
    
    Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-efi@vger.kernel.org
    Cc: linux@endlessm.com
    Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-hong@endlessm.com
    [ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47155c33761e735e66361e514d0a525ff216901f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Apr 15 10:46:07 2019 +0200

    x86/mm: Prevent bogus warnings with "noexec=off"
    
    [ Upstream commit 510bb96fe5b3480b4b22d815786377e54cb701e7 ]
    
    Xose Vazquez Perez reported boot warnings when NX is disabled on the kernel command line.
    
    __early_set_fixmap() triggers this warning:
    
      attempted to set unsupported pgprot:    8000000000000163
                                   bits:      8000000000000000
                                   supported: 7fffffffffffffff
    
      WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/pgtable.h:537
                                __early_set_fixmap+0xa2/0xff
    
    because it uses __default_kernel_pte_mask to mask out unsupported bits.
    
    Use __supported_pte_mask instead.
    
    Disabling NX on the command line also triggers the NX warning in the page
    table mapping check:
    
      WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:262 note_page+0x2ae/0x650
      ....
    
    Make the warning depend on NX set in __supported_pte_mask.
    
    Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
    Tested-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rik van Riel <riel@surriel.com>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1904151037530.1729@nanos.tec.linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e011d319f7364eab0518b4896eb5a34a820c297a
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Mon Apr 15 09:49:56 2019 -0700

    x86/build/lto: Fix truncated .bss with -fdata-sections
    
    [ Upstream commit 6a03469a1edc94da52b65478f1e00837add869a3 ]
    
    With CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y, we compile the kernel with
    -fdata-sections, which also splits the .bss section.
    
    The new section, with a new .bss.* name, which pattern gets missed by the
    main x86 linker script which only expects the '.bss' name. This results
    in the discarding of the second part and a too small, truncated .bss
    section and an unhappy, non-working kernel.
    
    Use the common BSS_MAIN macro in the linker script to properly capture
    and merge all the generated BSS sections.
    
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20190415164956.124067-1-samitolvanen@google.com
    [ Extended the changelog. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a8306e3b433ba0c9a06d59d407b9e7d0652fc03
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Fri Apr 12 11:04:50 2019 +0200

    s390/pkey: add one more argument space for debug feature entry
    
    [ Upstream commit 6b1f16ba730d4c0cda1247568c3a1bf4fa3a2f2f ]
    
    The debug feature entries have been used with up to 5 arguents
    (including the pointer to the format string) but there was only
    space reserved for 4 arguemnts. So now the registration does
    reserve space for 5 times a long value.
    
    This fixes a sometime appearing weired value as the last
    value of an debug feature entry like this:
    
    ... pkey_sec2protkey zcrypt_send_cprb (cardnr=10 domain=12)
       failed with errno -2143346254
    
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Reported-by: Christian Rund <Christian.Rund@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a96a56eea045e1178ce1c5894147f448cacd948
Author: David Francis <David.Francis@amd.com>
Date:   Fri Mar 29 13:23:15 2019 -0400

    drm/amd/display: If one stream full updates, full update all planes
    
    [ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ]
    
    [Why]
    On some compositors, with two monitors attached, VT terminal
    switch can cause a graphical issue by the following means:
    
    There are two streams, one for each monitor. Each stream has one
    plane
    
    current state:
            M1:S1->P1
            M2:S2->P2
    
    The user calls for a terminal switch and a commit is made to
    change both planes to linear swizzle mode. In atomic check,
    a new dc_state is constructed with new planes on each stream
    
    new state:
            M1:S1->P3
            M2:S2->P4
    
    In commit tail, each stream is committed, one at a time. The first
    stream (S1) updates properly, triggerring a full update and replacing
    the state
    
    current state:
            M1:S1->P3
            M2:S2->P4
    
    The update for S2 comes in, but dc detects that there is no difference
    between the stream and plane in the new and current states, and so
    triggers a fast update. The fast update does not program swizzle,
    so the second monitor is corrupted
    
    [How]
    Add a flag to dc_plane_state that forces full updates
    
    When a stream undergoes a full update, set this flag on all changed
    planes, then clear it on the current stream
    
    Subsequent streams will get full updates as a result
    
    Signed-off-by: David Francis <David.Francis@amd.com>
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Reviewed-by: Roman Li <Roman.Li@amd.com>
    Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
    Acked-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3a41f93e3376dcf83c7192aa7aa55f8ca786668
Author: Denis Bolotin <dbolotin@marvell.com>
Date:   Sun Apr 14 17:23:08 2019 +0300

    qed: Fix the DORQ's attentions handling
    
    [ Upstream commit 0d72c2ac89185f179da1e8a91c40c82f3fa38f0b ]
    
    Separate the overflow handling from the hardware interrupt status analysis.
    The interrupt status is a single register and is common for all PFs. The
    first PF reading the register is not necessarily the one who overflowed.
    All PFs must check their overflow status on every attention.
    In this change we clear the sticky indication in the attention handler to
    allow doorbells to be processed again as soon as possible, but running
    the doorbell recovery is scheduled for the periodic handler to reduce the
    time spent in the attention handler.
    Checking the need for DORQ flush was changed to "db_bar_no_edpm" because
    qed_edpm_enabled()'s result could change dynamically and might have
    prevented a needed flush.
    
    Signed-off-by: Denis Bolotin <dbolotin@marvell.com>
    Signed-off-by: Michal Kalderon <mkalderon@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 47ef1bab8d1dc1e0e9598cd0390587e84eb4be69
Author: Denis Bolotin <dbolotin@marvell.com>
Date:   Sun Apr 14 17:23:07 2019 +0300

    qed: Fix missing DORQ attentions
    
    [ Upstream commit d4476b8a6151b2dd86c09b5acec64f66430db55d ]
    
    When the DORQ (doorbell block) is overflowed, all PFs get attentions at the
    same time. If one PF finished handling the attention before another PF even
    started, the second PF might miss the DORQ's attention bit and not handle
    the attention at all.
    If the DORQ attention is missed and the issue is not resolved, another
    attention will not be sent, therefore each attention is treated as a
    potential DORQ attention.
    As a result, the attention callback is called more frequently so the debug
    print was moved to reduce its quantity.
    The number of periodic doorbell recovery handler schedules was reduced
    because it was the previous way to mitigating the missed attention issue.
    
    Signed-off-by: Denis Bolotin <dbolotin@marvell.com>
    Signed-off-by: Michal Kalderon <mkalderon@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 deb2cc51dd5221abfe2f320625d3a388a6bf2a9f
Author: Denis Bolotin <dbolotin@marvell.com>
Date:   Sun Apr 14 17:23:06 2019 +0300

    qed: Fix the doorbell address sanity check
    
    [ Upstream commit b61b04ad81d5f975349d66abbecabf96ba211140 ]
    
    Fix the condition which verifies that doorbell address is inside the
    doorbell bar by checking that the end of the address is within range
    as well.
    
    Signed-off-by: Denis Bolotin <dbolotin@marvell.com>
    Signed-off-by: Michal Kalderon <mkalderon@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 2de1573a5ed9640c7ac95e5f3d0c4dc7c3e3e31d
Author: Denis Bolotin <dbolotin@marvell.com>
Date:   Sun Apr 14 17:23:05 2019 +0300

    qed: Delete redundant doorbell recovery types
    
    [ Upstream commit 9ac6bb1414ac0d45fe9cefbd1f5b06f0e1a3c98a ]
    
    DB_REC_DRY_RUN (running doorbell recovery without sending doorbells) is
    never used. DB_REC_ONCE (send a single doorbell from the doorbell recovery)
    is not needed anymore because by running the periodic handler we make sure
    we check the overflow status later instead.
    This patch is needed because in the next patches, the only doorbell
    recovery type being used is DB_REC_REAL_DEAL, and the fixes are much
    cleaner without this enum.
    
    Signed-off-by: Denis Bolotin <dbolotin@marvell.com>
    Signed-off-by: Michal Kalderon <mkalderon@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 775e0e6132504bf36cbe1848626b191a234af840
Author: David Howells <dhowells@redhat.com>
Date:   Sat Apr 13 08:37:37 2019 +0100

    afs: Fix in-progess ops to ignore server-level callback invalidation
    
    [ Upstream commit eeba1e9cf31d064284dd1fa7bd6cfe01395bd03d ]
    
    The in-kernel afs filesystem client counts the number of server-level
    callback invalidation events (CB.InitCallBackState* RPC operations) that it
    receives from the server.  This is stored in cb_s_break in various
    structures, including afs_server and afs_vnode.
    
    If an inode is examined by afs_validate(), say, the afs_server copy is
    compared, along with other break counters, to those in afs_vnode, and if
    one or more of the counters do not match, it is considered that the
    server's callback promise is broken.  At points where this happens,
    AFS_VNODE_CB_PROMISED is cleared to indicate that the status must be
    refetched from the server.
    
    afs_validate() issues an FS.FetchStatus operation to get updated metadata -
    and based on the updated data_version may invalidate the pagecache too.
    
    However, the break counters are also used to determine whether to note a
    new callback in the vnode (which would set the AFS_VNODE_CB_PROMISED flag)
    and whether to cache the permit data included in the YFSFetchStatus record
    by the server.
    
    The problem comes when the server sends us a CB.InitCallBackState op.  The
    first such instance doesn't cause cb_s_break to be incremented, but rather
    causes AFS_SERVER_FL_NEW to be cleared - but thereafter, say some hours
    after last use and all the volumes have been automatically unmounted and
    the server has forgotten about the client[*], this *will* likely cause an
    increment.
    
     [*] There are other circumstances too, such as the server restarting or
         needing to make space in its callback table.
    
    Note that the server won't send us a CB.InitCallBackState op until we talk
    to it again.
    
    So what happens is:
    
     (1) A mount for a new volume is attempted, a inode is created for the root
         vnode and vnode->cb_s_break and AFS_VNODE_CB_PROMISED aren't set
         immediately, as we don't have a nominated server to talk to yet - and
         we may iterate through a few to find one.
    
     (2) Before the operation happens, afs_fetch_status(), say, notes in the
         cursor (fc.cb_break) the break counter sum from the vnode, volume and
         server counters, but the server->cb_s_break is currently 0.
    
     (3) We send FS.FetchStatus to the server.  The server sends us back
         CB.InitCallBackState.  We increment server->cb_s_break.
    
     (4) Our FS.FetchStatus completes.  The reply includes a callback record.
    
     (5) xdr_decode_AFSCallBack()/xdr_decode_YFSCallBack() check to see whether
         the callback promise was broken by checking the break counter sum from
         step (2) against the current sum.
    
         This fails because of step (3), so we don't set the callback record
         and, importantly, don't set AFS_VNODE_CB_PROMISED on the vnode.
    
    This does not preclude the syscall from progressing, and we don't loop here
    rechecking the status, but rather assume it's good enough for one round
    only and will need to be rechecked next time.
    
     (6) afs_validate() it triggered on the vnode, probably called from
         d_revalidate() checking the parent directory.
    
     (7) afs_validate() notes that AFS_VNODE_CB_PROMISED isn't set, so doesn't
         update vnode->cb_s_break and assumes the vnode to be invalid.
    
     (8) afs_validate() needs to calls afs_fetch_status().  Go back to step (2)
         and repeat, every time the vnode is validated.
    
    This primarily affects volume root dir vnodes.  Everything subsequent to
    those inherit an already incremented cb_s_break upon mounting.
    
    The issue is that we assume that the callback record and the cached permit
    information in a reply from the server can't be trusted after getting a
    server break - but this is wrong since the server makes sure things are
    done in the right order, holding up our ops if necessary[*].
    
     [*] There is an extremely unlikely scenario where a reply from before the
         CB.InitCallBackState could get its delivery deferred till after - at
         which point we think we have a promise when we don't.  This, however,
         requires unlucky mass packet loss to one call.
    
    AFS_SERVER_FL_NEW tries to paper over the cracks for the initial mount from
    a server we've never contacted before, but this should be unnecessary.
    It's also further insulated from the problem on an initial mount by
    querying the server first with FS.GetCapabilities, which triggers the
    CB.InitCallBackState.
    
    Fix this by
    
     (1) Remove AFS_SERVER_FL_NEW.
    
     (2) In afs_calc_vnode_cb_break(), don't include cb_s_break in the
         calculation.
    
     (3) In afs_cb_is_broken(), don't include cb_s_break in the check.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35d71b00267edda6eb3f8c989a600c803fb60e7b
Author: Marc Dionne <marc.dionne@auristor.com>
Date:   Sat Apr 13 08:37:37 2019 +0100

    afs: Unlock pages for __pagevec_release()
    
    [ Upstream commit 21bd68f196ca91fc0f3d9bd1b32f6e530e8c1c88 ]
    
    __pagevec_release() complains loudly if any page in the vector is still
    locked.  The pages need to be locked for generic_error_remove_page(), but
    that function doesn't actually unlock them.
    
    Unlock the pages afterwards.
    
    Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Jonathan Billings <jsbillin@umich.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4faab6c903429c14b1a3590993483626662cb86
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Apr 12 15:13:27 2019 +0100

    qede: fix write to free'd pointer error and double free of ptp
    
    [ Upstream commit 1dc2b3d65523780ed1972d446c76e62e13f3e8f5 ]
    
    The err2 error return path calls qede_ptp_disable that cleans up
    on an error and frees ptp. After this, the free'd ptp is dereferenced
    when ptp->clock is set to NULL and the code falls-through to error
    path err1 that frees ptp again.
    
    Fix this by calling qede_ptp_disable and exiting via an error
    return path that does not set ptp->clock or kfree ptp.
    
    Addresses-Coverity: ("Write to pointer after free")
    Fixes: 035744975aec ("qede: Add support for PTP resource locking.")
    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 40990109952a3e7704f11e43abea639c0ebd5bad
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Apr 12 14:45:12 2019 +0100

    vxge: fix return of a free'd memblock on a failed dma mapping
    
    [ Upstream commit 0a2c34f18c94b596562bf3d019fceab998b8b584 ]
    
    Currently if a pci dma mapping failure is detected a free'd
    memblock address is returned rather than a NULL (that indicates
    an error). Fix this by ensuring NULL is returned on this error case.
    
    Addresses-Coverity: ("Use after free")
    Fixes: 528f727279ae ("vxge: code cleanup and reorganization")
    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 4230787c06558620288077c6d89dba88b2283ad3
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri Apr 12 19:52:36 2019 +0900

    mISDN: Check address length before reading address family
    
    [ Upstream commit 238ffdc49ef98b15819cfd5e3fb23194e3ea3d39 ]
    
    KMSAN will complain if valid address length passed to bind() is shorter
    than sizeof("struct sockaddr_mISDN"->family) bytes.
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d56b3f53ac8d9310a0ac20af663e1a44050f868
Author: wentalou <Wentao.Lou@amd.com>
Date:   Fri Apr 12 15:01:14 2019 +0800

    drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in sriov TDR
    
    [ Upstream commit b575f10dbd6f84c2c8744ff1f486bfae1e4f6f38 ]
    
    shadow was added into shadow_list by amdgpu_bo_create_shadow.
    meanwhile, shadow->tbo.mem was not fully configured.
    tbo.mem would be fully configured by amdgpu_vm_sdma_map_table until calling amdgpu_vm_clear_bo.
    If sriov TDR occurred between amdgpu_bo_create_shadow and amdgpu_vm_sdma_map_table,
    amdgpu_device_recover_vram would deal with shadow without tbo.mem.start.
    
    Signed-off-by: Wentao Lou <Wentao.Lou@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf4b7bc690e32e900a475fc195c242686e13ce28
Author: David Ahern <dsahern@gmail.com>
Date:   Tue Apr 9 14:23:10 2019 -0700

    selftests: fib_tests: Fix 'Command line is not complete' errors
    
    [ Upstream commit a5f622984a623df9a84cf43f6b098d8dd76fbe05 ]
    
    A couple of tests are verifying a route has been removed. The helper
    expects the prefix as the first part of the expected output. When
    checking that a route has been deleted the prefix is empty leading
    to an invalid ip command:
    
      $ ip ro ls match
      Command line is not complete. Try option "help"
    
    Fix by moving the comparison of expected output and output to a new
    function that is used by both check_route and check_route6. Use the
    new helper for the 2 checks on route removal.
    
    Also, remove the reset of 'set -x' in route_setup which overrides the
    user managed setting.
    
    Fixes: d69faad76584c ("selftests: fib_tests: Add prefix route tests with metric")
    Signed-off-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1e68de7659a8be67b56b264b7d833704146c1c4
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Tue Mar 12 11:32:56 2019 +0100

    clocksource/drivers/oxnas: Fix OX820 compatible
    
    [ Upstream commit fbc87aa0f7c429999dc31f1bac3b2615008cac32 ]
    
    The OX820 compatible is wrong is the driver, fix it.
    
    Fixes: 2ea3401e2a84 ("clocksource/drivers/oxnas: Add OX820 compatible")
    Reported-by: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 641a9b94456d262e039402c0583d19f3ab731b8e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 5 14:24:48 2019 +0100

    clocksource/drivers/npcm: select TIMER_OF
    
    [ Upstream commit 99834eead2a04e93a120abb112542b87c42ff5e1 ]
    
    When this is disabled, we get a link failure:
    
    drivers/clocksource/timer-npcm7xx.o: In function `npcm7xx_timer_init':
    timer-npcm7xx.c:(.init.text+0xf): undefined reference to `timer_of_init'
    
    Fixes: 1c00289ecd12 ("clocksource/drivers/npcm: Add NPCM7xx timer driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44d7638b39349222d97ac3ba197fef9650e75444
Author: Martin Leung <martin.leung@amd.com>
Date:   Tue Mar 26 13:14:11 2019 -0400

    drm/amd/display: extending AUX SW Timeout
    
    [ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ]
    
    [Why]
    AUX takes longer to reply when using active DP-DVI dongle on some asics
    resulting in up to 2000+ us edid read (timeout).
    
    [How]
    1. Adjust AUX poll to match spec
    2. Extend the SW timeout. This does not affect normal
    operation since we exit the loop as soon as AUX acks.
    
    Signed-off-by: Martin Leung <martin.leung@amd.com>
    Reviewed-by: Jun Lei <Jun.Lei@amd.com>
    Acked-by: Joshua Aberback <Joshua.Aberback@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 6661203b4210f274f1997f6f6671c03a15ebf093
Author: Lin Yi <teroincn@163.com>
Date:   Wed Apr 10 10:23:34 2019 +0800

    drm/ttm: fix dma_fence refcount imbalance on error path
    
    [ Upstream commit 543c364d8eeeb42c0edfaac9764f4e9f3d777ec1 ]
    
    the ttm_bo_add_move_fence takes a reference to the struct dma_fence, but
    failed to release it on the error path, leading to a memory leak.
    add dma_fence_put before return when error occur.
    
    Signed-off-by: Lin Yi <teroincn@163.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e1bdaca091e1d47d31c39cae13e22050721658a
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Wed Apr 3 09:13:34 2019 +0200

    s390/3270: fix lockdep false positive on view->lock
    
    [ Upstream commit 5712f3301a12c0c3de9cc423484496b0464f2faf ]
    
    The spinlock in the raw3270_view structure is used by con3270, tty3270
    and fs3270 in different ways. For con3270 the lock can be acquired in
    irq context, for tty3270 and fs3270 the highest context is bh.
    
    Lockdep sees the view->lock as a single class and if the 3270 driver
    is used for the console the following message is generated:
    
    WARNING: inconsistent lock state
    5.1.0-rc3-05157-g5c168033979d #12 Not tainted
    --------------------------------
    inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    swapper/0/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
    (____ptrval____) (&(&view->lock)->rlock){?.-.}, at: tty3270_update+0x7c/0x330
    
    Introduce a lockdep subclass for the view lock to distinguish bh from
    irq locks.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adefea883c1f71e1613a3b49233c0f60da188c29
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Mon Mar 11 12:47:14 2019 -0700

    tools/testing/nvdimm: Retain security state after overwrite
    
    [ Upstream commit 2170a0d53bee1a6c1a4ebd042f99d85aafc6c0ea ]
    
    Overwrite retains the security state after completion of operation.  Fix
    nfit_test to reflect this so that the kernel can test the behavior it is
    more likely to see in practice.
    
    Fixes: 926f74802cb1 ("tools/testing/nvdimm: Add overwrite support for nfit_test")
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40af621fefdbea783e27ace03e12dfd035178797
Author: Li RongQing <lirongqing@baidu.com>
Date:   Thu Apr 4 10:58:01 2019 +0800

    libnvdimm/pmem: fix a possible OOB access when read and write pmem
    
    [ Upstream commit 9dc6488e84b0f64df17672271664752488cd6a25 ]
    
    If offset is not zero and length is bigger than PAGE_SIZE,
    this will cause to out of boundary access to a page memory
    
    Fixes: 98cc093cba1e ("block, THP: make block_device_operations.rw_page support THP")
    Co-developed-by: Liang ZhiCheng <liangzhicheng@baidu.com>
    Signed-off-by: Liang ZhiCheng <liangzhicheng@baidu.com>
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7547c20fdd1c33802397be5e2452293749b558ee
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Wed Mar 27 11:10:44 2019 -0700

    libnvdimm/security: provide fix for secure-erase to use zero-key
    
    [ Upstream commit 037c8489ade669e0f09ad40d5b91e5e1159a14b1 ]
    
    Add a zero key in order to standardize hardware that want a key of 0's to
    be passed. Some platforms defaults to a zero-key with security enabled
    rather than allow the OS to enable the security. The zero key would allow
    us to manage those platform as well. This also adds a fix to secure erase
    so it can use the zero key to do crypto erase. Some other security commands
    already use zero keys. This introduces a standard zero-key to allow
    unification of semantics cross nvdimm security commands.
    
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f2e6b8c9b0b4e3fc32829bfe682f4786942e41c
Author: Sunil Dutt <usdutt@codeaurora.org>
Date:   Mon Feb 25 15:37:20 2019 +0530

    nl80211: Add NL80211_FLAG_CLEAR_SKB flag for other NL commands
    
    [ Upstream commit d6db02a88a4aaa1cd7105137c67ddec7f3bdbc05 ]
    
    This commit adds NL80211_FLAG_CLEAR_SKB flag to other NL commands
    that carry key data to ensure they do not stick around on heap
    after the SKB is freed.
    
    Also introduced this flag for NL80211_CMD_VENDOR as there are sub
    commands which configure the keys.
    
    Signed-off-by: Sunil Dutt <usdutt@codeaurora.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e36c8ed2d529156e22f0d2fd796d71475e42832
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Mar 16 18:06:31 2019 +0100

    mac80211: fix memory accounting with A-MSDU aggregation
    
    [ Upstream commit eb9b64e3a9f8483e6e54f4e03b2ae14ae5db2690 ]
    
    skb->truesize can change due to memory reallocation or when adding extra
    fragments. Adjust fq->memory_usage accordingly
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c93951de3ecb2937270a6058a0d0ce7672b2bfea
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Fri Mar 15 17:39:00 2019 +0200

    cfg80211: Handle WMM rules in regulatory domain intersection
    
    [ Upstream commit 08a75a887ee46828b54600f4bb7068d872a5edd5 ]
    
    The support added for regulatory WMM rules did not handle
    the case of regulatory domain intersections. Fix it.
    
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Fixes: 230ebaa189af ("cfg80211: read wmm rules from regulatory database")
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c7345f1cad884ba4ad030e4cee6ee9aada6940b
Author: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Date:   Fri Mar 15 17:38:57 2019 +0200

    mac80211: Increase MAX_MSG_LEN
    
    [ Upstream commit 78be2d21cc1cd3069c6138dcfecec62583130171 ]
    
    Looks that 100 chars isn't enough for messages, as we keep getting
    warnings popping from different places due to message shortening.
    Instead of trying to shorten the prints, just increase the buffer size.
    
    Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c077b14bdc0b33c81c0c614f1be3352b56c0468
Author: Felix Fietkau <nbd@nbd.name>
Date:   Wed Mar 13 18:54:27 2019 +0100

    mac80211: fix unaligned access in mesh table hash function
    
    [ Upstream commit 40586e3fc400c00c11151804dcdc93f8c831c808 ]
    
    The pointer to the last four bytes of the address is not guaranteed to be
    aligned, so we need to use __get_unaligned_cpu32 here
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d02fc4b7789af1875e4c0382897ac121389c580
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Fri Mar 22 16:01:17 2019 +0100

    s390/dasd: Fix capacity calculation for large volumes
    
    [ Upstream commit 2cc9637ce825f3a9f51f8f78af7474e9e85bfa5f ]
    
    The DASD driver incorrectly limits the maximum number of blocks of ECKD
    DASD volumes to 32 bit numbers. Volumes with a capacity greater than
    2^32-1 blocks are incorrectly recognized as smaller volumes.
    
    This results in the following volume capacity limits depending on the
    formatted block size:
    
      BLKSIZE  MAX_GB   MAX_CYL
          512    2047   5843492
         1024    4095   8676701
         2048    8191  13634816
         4096   16383  23860929
    
    The same problem occurs when a volume with more than 17895697 cylinders
    is accessed in raw-track-access mode.
    
    Fix this problem by adding an explicit type cast when calculating the
    maximum number of blocks.
    
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 181518b8eb4eb44aae043d584336d715b572902e
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Mon Mar 25 16:55:27 2019 -0500

    libnvdimm/btt: Fix a kmemdup failure check
    
    [ Upstream commit 486fa92df4707b5df58d6508728bdb9321a59766 ]
    
    In case kmemdup fails, the fix releases resources and returns to
    avoid the NULL pointer dereference.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f744a5e31a4756b3e33c3797e0b0fc5425d4d0b8
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Jan 18 14:35:45 2019 -0800

    HID: input: add mapping for "Toggle Display" key
    
    [ Upstream commit c01908a14bf735b871170092807c618bb9dae654 ]
    
    According to HUT 1.12 usage 0xb5 from the generic desktop page is reserved
    for switching between external and internal display, so let's add the
    mapping.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e56b93040c2329e8f91fbd0d453fa4c652b8201
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Jan 18 14:05:52 2019 -0800

    HID: input: add mapping for keyboard Brightness Up/Down/Toggle keys
    
    [ Upstream commit 7975a1d6a7afeb3eb61c971a153d24dd8fa032f3 ]
    
    According to HUTRR73 usages 0x79, 0x7a and 0x7c from the consumer page
    correspond to Brightness Up/Down/Toggle keys, so let's add the mappings.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c64e4d22342cac48dd296dd10ef01a50215dcf92
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Jan 18 13:59:08 2019 -0800

    HID: input: add mapping for Expose/Overview key
    
    [ Upstream commit 96dd86871e1fffbc39e4fa61c9c75ec54ee9af0f ]
    
    According to HUTRR77 usage 0x29f from the consumer page is reserved for
    the Desktop application to present all running user’s application windows.
    Linux defines KEY_SCALE to request Compiz Scale (Expose) mode, so let's
    add the mapping.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e42bcea02b46d9a248d33014ec901f363a77a392
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Tue Mar 12 03:20:34 2019 -0500

    libnvdimm/namespace: Fix a potential NULL pointer dereference
    
    [ Upstream commit 55c1fc0af29a6c1b92f217b7eb7581a882e0c07c ]
    
    In case kmemdup fails, the fix goes to blk_err to avoid NULL
    pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 469cc616e03c22ed3371300dcf82df39902f8642
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Mar 12 12:28:03 2019 -0700

    acpi/nfit: Always dump _DSM output payload
    
    [ Upstream commit 351f339faa308c1c1461314a18c832239a841ca0 ]
    
    The dynamic-debug statements for command payload output only get emitted
    when the command is not ND_CMD_CALL. Move the output payload dumping
    ahead of the early return path for ND_CMD_CALL.
    
    Fixes: 31eca76ba2fc9 ("...whitelisted dimm command marshaling mechanism")
    Reported-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9189a36d66ea1f60e279641a3a53d51b0b5ca82
Author: Sven Van Asbroeck <thesven73@gmail.com>
Date:   Sun Mar 10 14:58:26 2019 -0400

    iio: adc: xilinx: prevent touching unclocked h/w on remove
    
    [ Upstream commit 2e4b88f73966adead360e47621df0183586fac32 ]
    
    In remove, the clock is disabled before canceling the
    delayed work. This means that the delayed work may be
    touching unclocked hardware.
    
    Fix by disabling the clock after the delayed work is
    fully canceled. This is consistent with the probe error
    path order.
    
    Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fc0aeddc0b7490e2fbfb688f66e3c8dc6b5c2d1
Author: Sven Van Asbroeck <thesven73@gmail.com>
Date:   Sun Mar 10 14:58:25 2019 -0400

    iio: adc: xilinx: fix potential use-after-free on probe
    
    [ Upstream commit 862e4644fd2d7df8998edc65e0963ea2f567bde9 ]
    
    If probe errors out after request_irq(), its error path
    does not explicitly cancel the delayed work, which may
    have been scheduled by the interrupt handler.
    
    This means the delayed work may still be running when
    the core frees the private structure (struct xadc).
    This is a potential use-after-free.
    
    Fix by inserting cancel_delayed_work_sync() in the probe
    error path.
    
    Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc92e97e24dfca591e53de7f2649005a7aaedc61
Author: Sven Van Asbroeck <thesven73@gmail.com>
Date:   Sun Mar 10 14:58:24 2019 -0400

    iio: adc: xilinx: fix potential use-after-free on remove
    
    [ Upstream commit 62039b6aef63380ba7a37c113bbaeee8a55c5342 ]
    
    When cancel_delayed_work() returns, the delayed work may still
    be running. This means that the core could potentially free
    the private structure (struct xadc) while the delayed work
    is still using it. This is a potential use-after-free.
    
    Fix by calling cancel_delayed_work_sync(), which waits for
    any residual work to finish before returning.
    
    Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a41382ca99e87805c2717efbeeeb3eb88f45b82b
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 25 18:05:36 2019 +0200

    USB: serial: fix unthrottle races
    
    commit 3f5edd58d040bfa4b74fb89bc02f0bc6b9cd06ab upstream.
    
    Fix two long-standing bugs which could potentially lead to memory
    corruption or leave the port throttled until it is reopened (on weakly
    ordered systems), respectively, when read-URB completion races with
    unthrottle().
    
    First, the URB must not be marked as free before processing is complete
    to prevent it from being submitted by unthrottle() on another CPU.
    
            CPU 1                           CPU 2
            ================                ================
            complete()                      unthrottle()
              process_urb();
              smp_mb__before_atomic();
              set_bit(i, free);               if (test_and_clear_bit(i, free))
                                                      submit_urb();
    
    Second, the URB must be marked as free before checking the throttled
    flag to prevent unthrottle() on another CPU from failing to observe that
    the URB needs to be submitted if complete() sees that the throttled flag
    is set.
    
            CPU 1                           CPU 2
            ================                ================
            complete()                      unthrottle()
              set_bit(i, free);               throttled = 0;
              smp_mb__after_atomic();         smp_mb();
              if (throttled)                  if (test_and_clear_bit(i, free))
                      return;                         submit_urb();
    
    Note that test_and_clear_bit() only implies barriers when the test is
    successful. To handle the case where the URB is still in use an explicit
    barrier needs to be added to unthrottle() for the second race condition.
    
    Fixes: d83b405383c9 ("USB: serial: add support for multiple read urbs")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5f2cb384e118657472350a246b77ba11e936560
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Apr 4 14:39:09 2019 +0200

    virt: vbox: Sanity-check parameter types for hgcm-calls coming from userspace
    
    commit cf4f2ad6b87dda2dbe0573b1ebeb0273f8d4aac6 upstream.
    
    Userspace can make host function calls, called hgcm-calls through the
    /dev/vboxguest device.
    
    In this case we should not accept all hgcm-function-parameter-types, some
    are only valid for in kernel calls.
    
    This commit adds proper hgcm-function-parameter-type validation to the
    ioctl for doing a hgcm-call from userspace.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a16532b59cca93292ae817dfa726fa3052b187ff
Author: Andrea Parri <andrea.parri@amarulasolutions.com>
Date:   Tue Apr 16 14:17:11 2019 +0200

    kernfs: fix barrier usage in __kernfs_new_node()
    
    commit 998267900cee901c5d1dfa029a6304d00acbc29f upstream.
    
    smp_mb__before_atomic() can not be applied to atomic_set().  Remove the
    barrier and rely on RELEASE synchronization.
    
    Fixes: ba16b2846a8c6 ("kernfs: add an API to get kernfs node from inode number")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0748cf2d9d1cb2e49a594e18c275391974458b84
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Apr 11 16:56:31 2019 -0700

    selftests/seccomp: Handle namespace failures gracefully
    
    commit 9dd3fcb0ab73cb1e00b8562ef027a38521aaff87 upstream.
    
    When running without USERNS or PIDNS the seccomp test would hang since
    it was waiting forever for the child to trigger the user notification
    since it seems the glibc() abort handler makes a call to getpid(),
    which would trap again. This changes the getpid filter to getppid, and
    makes sure ASSERTs execute to stop from spawning the listener.
    
    Reported-by: Shuah Khan <shuah@kernel.org>
    Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
    Cc: stable@vger.kernel.org # > 5.0
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Tycho Andersen <tycho@tycho.ws>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c3c0ffa9d74fdbaab2f366f48388a50f95ece84
Author: Lei YU <mine260309@gmail.com>
Date:   Mon Apr 15 18:37:20 2019 +0800

    hwmon: (occ) Fix extended status bits
    
    commit b88c5049219a7f322bb1fd65fc30d17472a23563 upstream.
    
    The occ's extended status is checked and shown as sysfs attributes. But
    the code was incorrectly checking the "status" bits.
    Fix it by checking the "ext_status" bits.
    
    Cc: stable@vger.kernel.org
    Fixes: df04ced684d4 ("hwmon (occ): Add sysfs attributes for additional OCC data")
    Signed-off-by: Lei YU <mine260309@gmail.com>
    Reviewed-by: Eddie James <eajames@linux.ibm.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a91e668131adb5ba7a07e279ee6237a4616e71f4
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Wed Apr 3 14:48:33 2019 +0200

    hwmon: (pwm-fan) Disable PWM if fetching cooling data fails
    
    commit 53f1647da3e8fb3e89066798f0fdc045064d353d upstream.
    
    In case pwm_fan_of_get_cooling_data() fails we should disable the PWM
    just like in the other error cases.
    
    Fixes: 2e5219c77183 ("hwmon: (pwm-fan) Read PWM FAN configuration from device tree")
    Cc: <stable@vger.kernel.org> # 4.14+
    Reported-by: Guenter Rock <linux@roeck-us.net>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9d31180294a898414221a6e52697852641f5cc9
Author: Mario Limonciello <mario.limonciello@dell.com>
Date:   Wed Mar 27 09:25:34 2019 -0500

    platform/x86: dell-laptop: fix rfkill functionality
    
    commit 6cc13c28da5beee0f706db6450e190709700b34a upstream.
    
    When converting the driver two arguments were transposed leading
    to rfkill not working.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201427
    Reported-by: Pepijn de Vos <pepijndevos@gmail.com>
    Fixes: 549b49 ("platform/x86: dell-smbios: Introduce dispatcher for SMM calls")
    Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
    Acked-by: Pali Rohár <pali.rohar@gmail.com>
    Cc: <stable@vger.kernel.org> # 4.14.x
    Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22c8b3235eb2adf0839b0582f67fcc6ec5691225
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Thu Mar 7 17:37:16 2019 +0800

    platform/x86: thinkpad_acpi: Disable Bluetooth for some machines
    
    commit f7db839fccf087664e5587966220821289b6a9cb upstream.
    
    Some AMD based ThinkPads have a firmware bug that calling
    "GBDC" will cause Bluetooth on Intel wireless cards blocked.
    
    Probe these models by DMI match and disable Bluetooth subdriver
    if specified Intel wireless card exist.
    
    Cc: stable <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fb172181a291767cf5803b655bc61d81dd48eb3
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Apr 24 13:09:34 2019 -0500

    platform/x86: sony-laptop: Fix unintentional fall-through
    
    commit 1cbd7a64959d33e7a2a1fa2bf36a62b350a9fcbd upstream.
    
    It seems that the default case should return AE_CTRL_TERMINATE, instead
    of falling through to case ACPI_RESOURCE_TYPE_END_TAG and returning AE_OK;
    otherwise the line of code at the end of the function is unreachable and
    makes no sense:
    
    return AE_CTRL_TERMINATE;
    
    This fix is based on the following thread of discussion:
    
    https://lore.kernel.org/patchwork/patch/959782/
    
    Fixes: 33a04454527e ("sony-laptop: Add SNY6001 device handling (sonypi reimplementation)")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54c140c5b614400d7909a64719774c9ca9858125
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Jan 18 10:34:16 2019 -0700

    bfq: update internal depth state when queue depth changes
    
    [ Upstream commit 77f1e0a52d26242b6c2dba019f6ebebfb9ff701e ]
    
    A previous commit moved the shallow depth and BFQ depth map calculations
    to be done at init time, moving it outside of the hotter IO path. This
    potentially causes hangs if the users changes the depth of the scheduler
    map, by writing to the 'nr_requests' sysfs file for that device.
    
    Add a blk-mq-sched hook that allows blk-mq to inform the scheduler if
    the depth changes, so that the scheduler can update its internal state.
    
    Tested-by: Kai Krakow <kai@kaishome.de>
    Reported-by: Paolo Valente <paolo.valente@linaro.org>
    Fixes: f0635b8a416e ("bfq: calculate shallow depths at init time")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>