commit 5e408889e4af03a27b77cf4635934fefb9f4afab
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 21 07:18:51 2019 +0200

    Linux 5.2.17

commit 12434939ba58717e0259ffe7375f9aa7a5f1c0b8
Author: David Howells <dhowells@redhat.com>
Date:   Mon Mar 25 16:38:22 2019 +0000

    vfs: Fix refcounting of filenames in fs_parser
    
    commit 7cdfa44227b0d8842d46a775cebe4311150cb8f2 upstream.
    
    Fix an overput in which filename_lookup() unconditionally drops a ref to
    the filename it was given, but this isn't taken account of in the caller,
    fs_lookup_param().
    
    Addresses-Coverity-ID: 1443811 ("Use after free")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4911cc1f4b663f5a19707610aa7623d9f94c78a
Author: Sean Young <sean@mess.org>
Date:   Wed Jul 3 10:52:39 2019 -0400

    media: technisat-usb2: break out of loop at end of buffer
    
    commit 0c4df39e504bf925ab666132ac3c98d6cbbe380b upstream.
    
    Ensure we do not access the buffer beyond the end if no 0xff byte
    is encountered.
    
    Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com
    Signed-off-by: Sean Young <sean@mess.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19ad4c4fe19c57acc3add672c5ece6563b26ad43
Author: Jann Horn <jannh@google.com>
Date:   Tue Mar 26 23:03:48 2019 +0100

    floppy: fix usercopy direction
    
    commit 52f6f9d74f31078964ca1574f7bb612da7877ac8 upstream.
    
    As sparse points out, these two copy_from_user() should actually be
    copy_to_user().
    
    Fixes: 229b53c9bf4e ("take floppy compat ioctls to sodding floppy.c")
    Cc: stable@vger.kernel.org
    Acked-by: Alexander Popov <alex.popov@linux.com>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7aa8c546ab97b9011f805042b3647693fce107f
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Fri Jul 12 15:24:34 2019 +0300

    ovl: fix regression caused by overlapping layers detection
    
    commit 0be0bfd2de9dfdd2098a9c5b14bdd8f739c9165d upstream.
    
    Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
    upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
    This change caused a docker regression. The root cause was mount leaks
    by docker, which as far as I know, still exist.
    
    To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
    caused by exclusive upper/work dir protection") in v4.14 turned the
    mount errors into warnings for the default index=off configuration.
    
    Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
    v5.2, re-introduced exclusive upper/work dir checks regardless of
    index=off configuration.
    
    This changes the status quo and mount leak related bug reports have
    started to re-surface. Restore the status quo to fix the regressions.
    To clarify, index=off does NOT relax overlapping layers check for this
    ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
    with another overlayfs mount.
    
    To cover the part of overlapping layers detection that used the
    exclusive upper/work dir checks to detect overlap with self upper/work
    dir, add a trap also on the work base dir.
    
    Link: https://github.com/moby/moby/issues/34672
    Link: https://lore.kernel.org/linux-fsdevel/20171006121405.GA32700@veci.piliscsaba.szeredi.hu/
    Link: https://github.com/containers/libpod/issues/3540
    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
    Cc: <stable@vger.kernel.org> # v4.19+
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Tested-by: Colin Walters <walters@verbum.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52f2aba47d7143cbddac33929e605a7d3022631b
Author: Will Deacon <will@kernel.org>
Date:   Thu Aug 22 14:58:37 2019 +0100

    Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"
    
    commit d0b7a302d58abe24ed0f32a0672dd4c356bb73db upstream.
    
    This reverts commit 24fe1b0efad4fcdd32ce46cffeab297f22581707.
    
    Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
    set_{pte,pmd,pud}") removed ISB instructions immediately following updates
    to the page table, on the grounds that they are not required by the
    architecture and a DSB alone is sufficient to ensure that subsequent data
    accesses use the new translation:
    
      DDI0487E_a, B2-128:
    
      | ... no instruction that appears in program order after the DSB
      | instruction can alter any state of the system or perform any part of
      | its functionality until the DSB completes other than:
      |
      | * Being fetched from memory and decoded
      | * Reading the general-purpose, SIMD and floating-point,
      |   Special-purpose, or System registers that are directly or indirectly
      |   read without causing side-effects.
    
    However, the same document also states the following:
    
      DDI0487E_a, B2-125:
    
      | DMB and DSB instructions affect reads and writes to the memory system
      | generated by Load/Store instructions and data or unified cache
      | maintenance instructions being executed by the PE. Instruction fetches
      | or accesses caused by a hardware translation table access are not
      | explicit accesses.
    
    which appears to claim that the DSB alone is insufficient.  Unfortunately,
    some CPU designers have followed the second clause above, whereas in Linux
    we've been relying on the first. This means that our mapping sequence:
    
            MOV     X0, <valid pte>
            STR     X0, [Xptep]     // Store new PTE to page table
            DSB     ISHST
            LDR     X1, [X2]        // Translates using the new PTE
    
    can actually raise a translation fault on the load instruction because the
    translation can be performed speculatively before the page table update and
    then marked as "faulting" by the CPU. For user PTEs, this is ok because we
    can handle the spurious fault, but for kernel PTEs and intermediate table
    entries this results in a panic().
    
    Revert the offending commit to reintroduce the missing barriers.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}")
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 785ca708a908b9c596ede852470ba28b8dc3e40b
Author: Joerg Roedel <jroedel@suse.de>
Date:   Fri Sep 6 10:39:54 2019 +0200

    iommu/amd: Fix race in increase_address_space()
    
    [ Upstream commit 754265bcab78a9014f0f99cd35e0d610fcd7dfa7 ]
    
    After the conversion to lock-less dma-api call the
    increase_address_space() function can be called without any
    locking. Multiple CPUs could potentially race for increasing
    the address space, leading to invalid domain->mode settings
    and invalid page-tables. This has been happening in the wild
    under high IO load and memory pressure.
    
    Fix the race by locking this operation. The function is
    called infrequently so that this does not introduce
    a performance regression in the dma-api path again.
    
    Reported-by: Qian Cai <cai@lca.pw>
    Fixes: 256e4621c21a ('iommu/amd: Make use of the generic IOVA allocator')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed52f6cf0e84ab34b2f1fa4bc865be941ec606cd
Author: Stuart Hayes <stuart.w.hayes@gmail.com>
Date:   Thu Sep 5 12:09:48 2019 -0500

    iommu/amd: Flush old domains in kdump kernel
    
    [ Upstream commit 36b7200f67dfe75b416b5281ed4ace9927b513bc ]
    
    When devices are attached to the amd_iommu in a kdump kernel, the old device
    table entries (DTEs), which were copied from the crashed kernel, will be
    overwritten with a new domain number.  When the new DTE is written, the IOMMU
    is told to flush the DTE from its internal cache--but it is not told to flush
    the translation cache entries for the old domain number.
    
    Without this patch, AMD systems using the tg3 network driver fail when kdump
    tries to save the vmcore to a network system, showing network timeouts and
    (sometimes) IOMMU errors in the kernel log.
    
    This patch will flush IOMMU translation cache entries for the old domain when
    a DTE gets overwritten with a new domain number.
    
    Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
    Fixes: 3ac3e5ee5ed5 ('iommu/amd: Copy old trans table from old kernel')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24962eb0edd0b75ed5b053627d37c9e9337e08c6
Author: Hillf Danton <hdanton@sina.com>
Date:   Mon Sep 2 13:37:29 2019 +0100

    keys: Fix missing null pointer check in request_key_auth_describe()
    
    [ Upstream commit d41a3effbb53b1bcea41e328d16a4d046a508381 ]
    
    If a request_key authentication token key gets revoked, there's a window in
    which request_key_auth_describe() can see it with a NULL payload - but it
    makes no check for this and something like the following oops may occur:
    
            BUG: Kernel NULL pointer dereference at 0x00000038
            Faulting instruction address: 0xc0000000004ddf30
            Oops: Kernel access of bad area, sig: 11 [#1]
            ...
            NIP [...] request_key_auth_describe+0x90/0xd0
            LR [...] request_key_auth_describe+0x54/0xd0
            Call Trace:
            [...] request_key_auth_describe+0x54/0xd0 (unreliable)
            [...] proc_keys_show+0x308/0x4c0
            [...] seq_read+0x3d0/0x540
            [...] proc_reg_read+0x90/0x110
            [...] __vfs_read+0x3c/0x70
            [...] vfs_read+0xb4/0x1b0
            [...] ksys_read+0x7c/0x130
            [...] system_call+0x5c/0x70
    
    Fix this by checking for a NULL pointer when describing such a key.
    
    Also make the read routine check for a NULL pointer to be on the safe side.
    
    [DH: Modified to not take already-held rcu lock and modified to also check
     in the read routine]
    
    Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a key")
    Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16ed4b9b7bf79120ffdbef81eb0f598068d373cf
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Sep 2 20:44:03 2019 +0900

    dmaengine: rcar-dmac: Fix DMACHCLR handling if iommu is mapped
    
    [ Upstream commit cf24aac38698bfa1d021afd3883df3c4c65143a4 ]
    
    The commit 20c169aceb45 ("dmaengine: rcar-dmac: clear pertinence
    number of channels") forgets to clear the last channel by
    DMACHCLR in rcar_dmac_init() (and doesn't need to clear the first
    channel) if iommu is mapped to the device. So, this patch fixes it
    by using "channels_mask" bitfield.
    
    Note that the hardware and driver don't support more than 32 bits
    in DMACHCLR register anyway, so this patch should reject more than
    32 channels in rcar_dmac_parse_of().
    
    Fixes: 20c169aceb459575 ("dmaengine: rcar-dmac: clear pertinence number of channels")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/1567424643-26629-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d604a12cc6d5eee644a4b88d68f9b547f23442e6
Author: Baolin Wang <baolin.wang@linaro.org>
Date:   Fri Aug 30 15:37:45 2019 +0800

    dmaengine: sprd: Fix the DMA link-list configuration
    
    [ Upstream commit 689379c2f383b1fdfdff03e84cf659daf62f2088 ]
    
    For the Spreadtrum DMA link-list mode, when the DMA engine got a slave
    hardware request, which will trigger the DMA engine to load the DMA
    configuration from the link-list memory automatically. But before the
    slave hardware request, the slave will get an incorrect residue due
    to the first node used to trigger the link-list was configured as the
    last source address and destination address.
    
    Thus we should make sure the first node was configured the start source
    address and destination address, which can fix this issue.
    
    Fixes: 4ac695464763 ("dmaengine: sprd: Support DMA link-list mode")
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Link: https://lore.kernel.org/r/77868edb7aff9d5cb12ac3af8827ef2e244441a6.1567150471.git.baolin.wang@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5898d2f06fc13e163596aab175101c1b1816290
Author: Jacob Pan <jacob.jun.pan@linux.intel.com>
Date:   Mon Aug 26 08:53:29 2019 -0700

    iommu/vt-d: Remove global page flush support
    
    [ Upstream commit 8744daf4b0699b724ee0a56b313a6c0c4ea289e3 ]
    
    Global pages support is removed from VT-d spec 3.0. Since global pages G
    flag only affects first-level paging structures and because DMA request
    with PASID are only supported by VT-d spec. 3.0 and onward, we can
    safely remove global pages support.
    
    For kernel shared virtual address IOTLB invalidation, PASID
    granularity and page selective within PASID will be used. There is
    no global granularity supported. Without this fix, IOTLB invalidation
    will cause invalid descriptor error in the queued invalidation (QI)
    interface.
    
    Fixes: 1c4f88b7f1f9 ("iommu/vt-d: Shared virtual address in scalable mode")
    Reported-by: Sanjay K Kumar <sanjay.k.kumar@intel.com>
    Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5df0a5fd4d1c227a496e2173f240fabdfa2b02d2
Author: Tianyu Lan <Tianyu.Lan@microsoft.com>
Date:   Mon Sep 2 20:41:43 2019 +0800

    x86/hyper-v: Fix overflow bug in fill_gva_list()
    
    [ Upstream commit 4030b4c585c41eeefec7bd20ce3d0e100a0f2e4d ]
    
    When the 'start' parameter is >=  0xFF000000 on 32-bit
    systems, or >= 0xFFFFFFFF'FF000000 on 64-bit systems,
    fill_gva_list() gets into an infinite loop.
    
    With such inputs, 'cur' overflows after adding HV_TLB_FLUSH_UNIT
    and always compares as less than end.  Memory is filled with
    guest virtual addresses until the system crashes.
    
    Fix this by never incrementing 'cur' to be larger than 'end'.
    
    Reported-by: Jong Hyun Park <park.jonghyun@yonsei.ac.kr>
    Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 2ffd9e33ce4a ("x86/hyper-v: Use hypercall for remote TLB flush")
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bdb9988ad3855294c63f7fc5b631cf5e1dc02d5
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Aug 29 10:24:45 2019 +0200

    x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
    
    [ Upstream commit 9b8bd476e78e89c9ea26c3b435ad0201c3d7dbf5 ]
    
    Identical to __put_user(); the __get_user() argument evalution will too
    leak UBSAN crud into the __uaccess_begin() / __uaccess_end() region.
    While uncommon this was observed to happen for:
    
      drivers/xen/gntdev.c: if (__get_user(old_status, batch->status[i]))
    
    where UBSAN added array bound checking.
    
    This complements commit:
    
      6ae865615fc4 ("x86/uaccess: Dont leak the AC flag into __put_user() argument evaluation")
    
    Tested-by Sedat Dilek <sedat.dilek@gmail.com>
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: broonie@kernel.org
    Cc: sfr@canb.auug.org.au
    Cc: akpm@linux-foundation.org
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: mhocko@suse.cz
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lkml.kernel.org/r/20190829082445.GM2369@hirez.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4dabe50389c45c2882cf7e7aec91bdf337719eaf
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Fri Aug 16 01:56:08 2019 -0500

    dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe()
    
    [ Upstream commit 962411b05a6d3342aa649e39cda1704c1fc042c6 ]
    
    If devm_request_irq() fails to disable all interrupts, no cleanup is
    performed before retuning the error. To fix this issue, invoke
    omap_dma_free() to do the cleanup.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Link: https://lore.kernel.org/r/1565938570-7528-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9de496fe242a151ec953bb127f4f73bfa6813051
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Fri Aug 16 01:48:55 2019 -0500

    dmaengine: ti: dma-crossbar: Fix a memory leak bug
    
    [ Upstream commit 2c231c0c1dec42192aca0f87f2dc68b8f0cbc7d2 ]
    
    In ti_dra7_xbar_probe(), 'rsv_events' is allocated through kcalloc(). Then
    of_property_read_u32_array() is invoked to search for the property.
    However, if this process fails, 'rsv_events' is not deallocated, leading to
    a memory leak bug. To fix this issue, free 'rsv_events' before returning
    the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Link: https://lore.kernel.org/r/1565938136-7249-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b898223a979138bf81ea150fe56903b24bb3e14
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Jul 31 09:48:01 2019 +0200

    arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name
    
    [ Upstream commit 45f5d5a9e34d3fe4140a9a3b5f7ebe86c252440a ]
    
    Currently there are two nodes named "regulator1" in the Draak DTS: a
    3.3V regulator for the eMMC and the LVDS decoder, and a 12V regulator
    for the backlight.  This causes the former to be overwritten by the
    latter.
    
    Fix this by renaming all regulators with numerical suffixes to use named
    suffixes, which are less likely to conflict.
    
    Fixes: 4fbd4158fe8967e9 ("arm64: dts: renesas: r8a77995: draak: Add backlight")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ad64281e4d331a29ff21c1097aa7c46b6bd8a72
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 31 09:17:51 2019 +0200

    net: seeq: Fix the function used to release some memory in an error handling path
    
    [ Upstream commit e1e54ec7fb55501c33b117c111cb0a045b8eded2 ]
    
    In commit 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv"),
    a call to 'get_zeroed_page()' has been turned into a call to
    'dma_alloc_coherent()'. Only the remove function has been updated to turn
    the corresponding 'free_page()' into 'dma_free_attrs()'.
    The error hndling path of the probe function has not been updated.
    
    Fix it now.
    
    Rename the corresponding label to something more in line.
    
    Fixes: 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0275857577e5e2e482383d3674765d2f51cc610d
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Aug 30 22:23:12 2019 +0200

    enetc: Add missing call to 'pci_free_irq_vectors()' in probe and remove functions
    
    [ Upstream commit dd7078f05e1b774a9e8c9f117101d97e4ccd0691 ]
    
    Call to 'pci_free_irq_vectors()' are missing both in the error handling
    path of the probe function, and in the remove function.
    Add them.
    
    Fixes: 19971f5ea0ab ("enetc: add PTP clock driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d18638671b96904a41c6307ff27ec57d2e83d749
Author: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Date:   Fri Aug 30 10:52:02 2019 +0300

    net: dsa: microchip: add KSZ8563 compatibility string
    
    [ Upstream commit d9033ae95cf445150fcc5856ccf024f41f0bd0b9 ]
    
    It is a 3-Port 10/100 Ethernet Switch with 1588v2 PTP.
    
    Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05172612ab3a5ba4824bd8aab5817a277eed230e
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Fri Aug 30 12:08:38 2019 +0000

    net: aquantia: fix out of memory condition on rx side
    
    [ Upstream commit be6cef69ba570ebb327eba1ef6438f7af49aaf86 ]
    
    On embedded environments with hard memory limits it is a normal although
    rare case when skb can't be allocated on rx part under high traffic.
    
    In such OOM cases napi_complete_done() was not called.
    So the napi object became in an invalid state like it is "scheduled".
    Kernel do not re-schedules the poll of that napi object.
    
    Consequently, kernel can not remove that object the system hangs on
    `ifconfig down` waiting for a poll.
    
    We are fixing this by gracefully closing napi poll routine with correct
    invocation of napi_complete_done.
    
    This was reproduced with artificially failing the allocation of skb to
    simulate an "out of memory" error case and check that traffic does
    not get stuck.
    
    Fixes: 970a2e9864b0 ("net: ethernet: aquantia: Vector operations")
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95acd66ba70a1b0327de04d3a4de459d83b7c082
Author: Igor Russkikh <Igor.Russkikh@aquantia.com>
Date:   Fri Aug 30 12:08:36 2019 +0000

    net: aquantia: linkstate irq should be oneshot
    
    [ Upstream commit 5c47e3ba6fe52465603cf9d816b3371e6881d649 ]
    
    Declaring threaded irq handler should also indicate the irq is
    oneshot. It is oneshot indeed, because HW implements irq automasking
    on trigger.
    
    Not declaring this causes some kernel configurations to fail
    on interface up, because request_threaded_irq returned an err code.
    
    The issue was originally hidden on normal x86_64 configuration with
    latest kernel, because depending on interrupt controller, irq driver
    added ONESHOT flag on its own.
    
    Issue was observed on older kernels (4.14) where no such logic exists.
    
    Fixes: 4c83f170b3ac ("net: aquantia: link status irq handling")
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Reported-by: Michael Symolkin <Michael.Symolkin@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4d1449ca4a59c24ad7ef9bdabd876301675247b
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Fri Aug 30 12:08:35 2019 +0000

    net: aquantia: reapply vlan filters on up
    
    [ Upstream commit c2ef057ee775e229d3138add59f937d93a3a59d8 ]
    
    In case of device reconfiguration the driver may reset the device invisible
    for other modules, vlan module in particular. So vlans will not be
    removed&created and vlan filters will not be configured in the device.
    The patch reapplies the vlan filters at device start.
    
    Fixes: 7975d2aff5afb ("net: aquantia: add support of rx-vlan-filter offload")
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a6e09b7a51913d7ce65983b2b821905b2ed6d28
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Fri Aug 30 12:08:30 2019 +0000

    net: aquantia: fix removal of vlan 0
    
    [ Upstream commit 6fdc060d7476ef73c8029b652d252c1a7b4de948 ]
    
    Due to absence of checking against the rx flow rule when vlan 0 is being
    removed, the other rule could be removed instead of the rule with vlan 0
    
    Fixes: 7975d2aff5afb ("net: aquantia: add support of rx-vlan-filter offload")
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5789a160c2d152027c72d6b30cb68311e84b0da
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Tue Aug 27 10:57:14 2019 -0700

    tools/power turbostat: Fix CPU%C1 display value
    
    [ Upstream commit 1e9042b9c8d46ada9ee7b3339a31f50d12e5d291 ]
    
    In some case C1% will be wrong value, when platform doesn't have MSR for
    C1 residency.
    
    For example:
    Core    CPU     CPU%c1
    -       -       100.00
    0       0       100.00
    0       2       100.00
    1       1       100.00
    1       3       100.00
    
    But adding Busy% will fix this
    Core    CPU     Busy%   CPU%c1
    -       -       99.77   0.23
    0       0       99.77   0.23
    0       2       99.77   0.23
    1       1       99.77   0.23
    1       3       99.77   0.23
    
    This issue can be reproduced on most of the recent systems including
    Broadwell, Skylake and later.
    
    This is because if we don't select Busy% or Avg_MHz or Bzy_MHz then
    mperf value will not be read from MSR, so it will be 0. But this
    is required for C1% calculation when MSR for C1 residency is not present.
    Same is true for C3, C6 and C7 column selection.
    
    So add another define DO_BIC_READ(), which doesn't depend on user
    column selection and use for mperf, C3, C6 and C7 related counters.
    So when there is no platform support for C1 residency counters,
    we still read these counters, if the CPU has support and user selected
    display of CPU%c1.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54f4f3b381331a7d96b3df913c05ee5de0e2efb2
Author: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
Date:   Fri Jun 14 13:09:46 2019 +0530

    tools/power turbostat: Add Ice Lake NNPI support
    
    [ Upstream commit d93ea567fc4eec2d3581015e23d2c555f8b393ba ]
    
    This enables turbostat utility on Ice Lake NNPI SoC.
    
    Link: https://lkml.org/lkml/2019/6/5/1034
    Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8bae84e5203b4c6aa5b1f6da00ae7850e51951e9
Author: Len Brown <len.brown@intel.com>
Date:   Sat Aug 31 14:09:29 2019 -0400

    tools/power turbostat: Fix Haswell Core systems
    
    [ Upstream commit cd188af5282d9f9e65f63915b13239bafc746f8d ]
    
    turbostat: cpu0: msr offset 0x630 read failed: Input/output error
    
    because Haswell Core does not have C8-C10.
    
    Output C8-C10 only on Haswell ULT.
    
    Fixes: f5a4c76ad7de ("tools/power turbostat: consolidate duplicate model numbers")
    
    Reported-by: Prarit Bhargava <prarit@redhat.com>
    Suggested-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0926ee9f5327c77db7efd60dbc3989546cc525c2
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Apr 3 16:02:14 2019 +0900

    tools/power turbostat: fix buffer overrun
    
    [ Upstream commit eeb71c950bc6eee460f2070643ce137e067b234c ]
    
    turbostat could be terminated by general protection fault on some latest
    hardwares which (for example) support 9 levels of C-states and show 18
    "tADDED" lines. That bloats the total output and finally causes buffer
    overrun.  So let's extend the buffer to avoid this.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94132aca9472a6cff8292149f5cea69f6ffeb51e
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Mon Apr 8 11:12:40 2019 -0500

    tools/power turbostat: fix file descriptor leaks
    
    [ Upstream commit 605736c6929d541c78a85dffae4d33a23b6b2149 ]
    
    Fix file descriptor leaks by closing fp before return.
    
    Addresses-Coverity-ID: 1444591 ("Resource leak")
    Addresses-Coverity-ID: 1444592 ("Resource leak")
    Fixes: 5ea7647b333f ("tools/power turbostat: Warn on bad ACPI LPIT data")
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Reviewed-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a1ba2cd9d620ec815ca901ca19d6ffb36f3b551
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Apr 8 10:00:44 2019 +0100

    tools/power turbostat: fix leak of file descriptor on error return path
    
    [ Upstream commit 15423b958f33132152e209e98df0dedc7a78f22c ]
    
    Currently the error return path does not close the file fp and leaks
    a file descriptor. Fix this by closing the file.
    
    Fixes: 5ea7647b333f ("tools/power turbostat: Warn on bad ACPI LPIT data")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit caab8b8b3acafd7406ba21707a46a5165d6eaaee
Author: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
Date:   Sat Feb 9 05:25:48 2019 -0800

    tools/power x86_energy_perf_policy: Fix argument parsing
    
    [ Upstream commit 03531482402a2bc4ab93cf6dde46833775e035e9 ]
    
    The -w argument in x86_energy_perf_policy currently triggers an
    unconditional segfault.
    
    This is because the argument string reads: "+a:c:dD:E:e:f:m:M:rt:u:vw" and
    yet the argument handler expects an argument.
    
    When parse_optarg_string is called with a null argument, we then proceed to
    crash in strncmp, not horribly friendly.
    
    The man page describes -w as taking an argument, the long form
    (--hwp-window) is correctly marked as taking a required argument, and the
    code expects it.
    
    As such, this patch simply marks the short form (-w) as requiring an
    argument.
    
    Signed-off-by: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edf8ba32bc2bf2f5a3a794a326fc3de110809920
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Sep 16 16:05:53 2018 +0100

    tools/power x86_energy_perf_policy: Fix "uninitialized variable" warnings at -O2
    
    [ Upstream commit adb8049097a9ec4acd09fbd3aa8636199a78df8a ]
    
    x86_energy_perf_policy first uses __get_cpuid() to check the maximum
    CPUID level and exits if it is too low.  It then assumes that later
    calls will succeed (which I think is architecturally guaranteed).  It
    also assumes that CPUID works at all (which is not guaranteed on
    x86_32).
    
    If optimisations are enabled, gcc warns about potentially
    uninitialized variables.  Fix this by adding an exit-on-error after
    every call to __get_cpuid() instead of just checking the maximum
    level.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9e492c92d8c61f63cbef2da5a85341ac878aca7
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 27 21:23:45 2019 +0200

    netfilter: nf_flow_table: clear skb tstamp before xmit
    
    [ Upstream commit de20900fbe1c4fd36de25a7a5a43223254ecf0d0 ]
    
    If 'fq' qdisc is used and a program has requested timestamps,
    skb->tstamp needs to be cleared, else fq will treat these as
    'transmit time'.
    
    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 27264af16969f4e8610b151ac1bb776427ebd1d0
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Aug 29 10:46:00 2019 +0800

    amd-xgbe: Fix error path in xgbe_mod_init()
    
    [ Upstream commit b6b4dc4c1fa7f1c99398e7dc85758049645e9588 ]
    
    In xgbe_mod_init(), we should do cleanup if some error occurs
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: efbaa828330a ("amd-xgbe: Add support to handle device renaming")
    Fixes: 47f164deab22 ("amd-xgbe: Add PCI device support")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b7bf7b1b2dd51db61da06e5fa5823df7557d45a
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Thu Aug 22 17:45:17 2019 +0800

    i2c: mediatek: disable zero-length transfers for mt8183
    
    [ Upstream commit abf4923e97c3abbbd1e59f0e13c7c214c93c6aaa ]
    
    Quoting from mt8183 datasheet, the number of transfers to be
    transferred in one transaction should be set to bigger than 1,
    so we should forbid zero-length transfer and update functionality.
    
    Reported-by: Alexandru M Stan <amstan@chromium.org>
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: Qii Wang <qii.wang@mediatek.com>
    [wsa: shortened commit message a little]
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 316c15048f405002af720d7764c434d95d6cfca5
Author: Lori Hikichi <lori.hikichi@broadcom.com>
Date:   Thu Aug 8 09:07:52 2019 +0530

    i2c: iproc: Stop advertising support of SMBUS quick cmd
    
    [ Upstream commit b3d604d405166edfd4e1e6053409b85008f4f56d ]
    
    The driver does not support the SMBUS Quick command so remove the
    flag that indicates that level of support.
    By default the i2c_detect tool uses the quick command to try and
    detect devices at some bus addresses.  If the quick command is used
    then we will not detect the device, even though it is present.
    
    Fixes: e6e5dd3566e0 (i2c: iproc: Add Broadcom iProc I2C Driver)
    Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
    Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
    Reviewed-by: Ray Jui <ray.jui@broadcom.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9027939cc8f73354f6d1075e16544d62c8ed2a58
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Mon Aug 26 14:57:30 2019 -0500

    perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops
    
    [ Upstream commit 0f4cd769c410e2285a4e9873a684d90423f03090 ]
    
    When counting dispatched micro-ops with cnt_ctl=1, in order to prevent
    sample bias, IBS hardware preloads the least significant 7 bits of
    current count (IbsOpCurCnt) with random values, such that, after the
    interrupt is handled and counting resumes, the next sample taken
    will be slightly perturbed.
    
    The current count bitfield is in the IBS execution control h/w register,
    alongside the maximum count field.
    
    Currently, the IBS driver writes that register with the maximum count,
    leaving zeroes to fill the current count field, thereby overwriting
    the random bits the hardware preloaded for itself.
    
    Fix the driver to actually retain and carry those random bits from the
    read of the IBS control register, through to its write, instead of
    overwriting the lower current count bits with zeroes.
    
    Tested with:
    
    perf record -c 100001 -e ibs_op/cnt_ctl=1/pp -a -C 0 taskset -c 0 <workload>
    
    'perf annotate' output before:
    
     15.70  65:   addsd     %xmm0,%xmm1
     17.30        add       $0x1,%rax
     15.88        cmp       %rdx,%rax
                  je        82
     17.32  72:   test      $0x1,%al
                  jne       7c
      7.52        movapd    %xmm1,%xmm0
      5.90        jmp       65
      8.23  7c:   sqrtsd    %xmm1,%xmm0
     12.15        jmp       65
    
    'perf annotate' output after:
    
     16.63  65:   addsd     %xmm0,%xmm1
     16.82        add       $0x1,%rax
     16.81        cmp       %rdx,%rax
                  je        82
     16.69  72:   test      $0x1,%al
                  jne       7c
      8.30        movapd    %xmm1,%xmm0
      8.13        jmp       65
      8.24  7c:   sqrtsd    %xmm1,%xmm0
      8.39        jmp       65
    
    Tested on Family 15h and 17h machines.
    
    Machines prior to family 10h Rev. C don't have the RDWROPCNT capability,
    and have the IbsOpCurCnt bitfield reserved, so this patch shouldn't
    affect their operation.
    
    It is unknown why commit db98c5faf8cb ("perf/x86: Implement 64-bit
    counter support for IBS") ignored the lower 4 bits of the IbsOpCurCnt
    field; the number of preloaded random bits has always been 7, AFAICT.
    
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org>
    Cc: <x86@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "Borislav Petkov" <bp@alien8.de>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: "Namhyung Kim" <namhyung@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: https://lkml.kernel.org/r/20190826195730.30614-1-kim.phillips@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1efdaaa9b46d570681fd2abc1df5e5b7c9abb2d
Author: Josh Hunt <johunt@akamai.com>
Date:   Mon Aug 19 19:13:31 2019 -0400

    perf/x86/intel: Restrict period on Nehalem
    
    [ Upstream commit 44d3bbb6f5e501b873218142fe08cdf62a4ac1f3 ]
    
    We see our Nehalem machines reporting 'perfevents: irq loop stuck!' in
    some cases when using perf:
    
    perfevents: irq loop stuck!
    WARNING: CPU: 0 PID: 3485 at arch/x86/events/intel/core.c:2282 intel_pmu_handle_irq+0x37b/0x530
    ...
    RIP: 0010:intel_pmu_handle_irq+0x37b/0x530
    ...
    Call Trace:
    <NMI>
    ? perf_event_nmi_handler+0x2e/0x50
    ? intel_pmu_save_and_restart+0x50/0x50
    perf_event_nmi_handler+0x2e/0x50
    nmi_handle+0x6e/0x120
    default_do_nmi+0x3e/0x100
    do_nmi+0x102/0x160
    end_repeat_nmi+0x16/0x50
    ...
    ? native_write_msr+0x6/0x20
    ? native_write_msr+0x6/0x20
    </NMI>
    intel_pmu_enable_event+0x1ce/0x1f0
    x86_pmu_start+0x78/0xa0
    x86_pmu_enable+0x252/0x310
    __perf_event_task_sched_in+0x181/0x190
    ? __switch_to_asm+0x41/0x70
    ? __switch_to_asm+0x35/0x70
    ? __switch_to_asm+0x41/0x70
    ? __switch_to_asm+0x35/0x70
    finish_task_switch+0x158/0x260
    __schedule+0x2f6/0x840
    ? hrtimer_start_range_ns+0x153/0x210
    schedule+0x32/0x80
    schedule_hrtimeout_range_clock+0x8a/0x100
    ? hrtimer_init+0x120/0x120
    ep_poll+0x2f7/0x3a0
    ? wake_up_q+0x60/0x60
    do_epoll_wait+0xa9/0xc0
    __x64_sys_epoll_wait+0x1a/0x20
    do_syscall_64+0x4e/0x110
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7fdeb1e96c03
    ...
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: acme@kernel.org
    Cc: Josh Hunt <johunt@akamai.com>
    Cc: bpuranda@akamai.com
    Cc: mingo@redhat.com
    Cc: jolsa@redhat.com
    Cc: tglx@linutronix.de
    Cc: namhyung@kernel.org
    Cc: alexander.shishkin@linux.intel.com
    Link: https://lkml.kernel.org/r/1566256411-18820-1-git-send-email-johunt@akamai.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ffda54f0546c7931891b9e44a6dcf000bf0831d
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date:   Thu Aug 15 16:52:11 2019 +0300

    i2c: designware: Synchronize IRQs when unregistering slave client
    
    [ Upstream commit c486dcd2f1bbdd524a1e0149734b79e4ae329650 ]
    
    Make sure interrupt handler i2c_dw_irq_handler_slave() has finished
    before clearing the the dev->slave pointer in i2c_dw_unreg_slave().
    
    There is possibility for a race if i2c_dw_irq_handler_slave() is running
    on another CPU while clearing the dev->slave pointer.
    
    Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
    Reported-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0910434c455df15ff8c1eca024cd4146472eda08
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Aug 28 08:31:19 2019 +0200

    sky2: Disable MSI on yet another ASUS boards (P6Xxxx)
    
    [ Upstream commit 189308d5823a089b56e2299cd96589507dac7319 ]
    
    A similar workaround for the suspend/resume problem is needed for yet
    another ASUS machines, P6X models.  Like the previous fix, the BIOS
    doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_*
    entries are used instead.
    
    Reported-and-tested-by: SteveM <swm@swm1.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd6901e723fc4e2d72e9ccd3e50c530cd824b456
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Tue Aug 27 11:10:04 2019 -0500

    ibmvnic: Do not process reset during or after device removal
    
    [ Upstream commit 36f1031c51a2538e5558fb44c6d6b88f98d3c0f2 ]
    
    Currently, the ibmvnic driver will not schedule device resets
    if the device is being removed, but does not check the device
    state before the reset is actually processed. This leads to a race
    where a reset is scheduled with a valid device state but is
    processed after the driver has been removed, resulting in an oops.
    
    Fix this by checking the device state before processing a queued
    reset event.
    
    Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
    Tested-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ee4ed9cd3a095f4041b13e59b5efc0bc0f94c30
Author: zhaoyang <huangzhaoyang@gmail.com>
Date:   Mon Aug 26 04:07:37 2019 +0100

    ARM: 8901/1: add a criteria for pfn_valid of arm
    
    [ Upstream commit 5b3efa4f1479c91cb8361acef55f9c6662feba57 ]
    
    pfn_valid can be wrong when parsing a invalid pfn whose phys address
    exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
    
    The issue originally arise from bellowing call stack, which corresponding to
    an access of the /proc/kpageflags from userspace with a invalid pfn parameter
    and leads to kernel panic.
    
    [46886.723249] c7 [<c031ff98>] (stable_page_flags) from [<c03203f8>]
    [46886.723264] c7 [<c0320368>] (kpageflags_read) from [<c0312030>]
    [46886.723280] c7 [<c0311fb0>] (proc_reg_read) from [<c02a6e6c>]
    [46886.723290] c7 [<c02a6e24>] (__vfs_read) from [<c02a7018>]
    [46886.723301] c7 [<c02a6f74>] (vfs_read) from [<c02a778c>]
    [46886.723315] c7 [<c02a770c>] (SyS_pread64) from [<c0108620>]
    (ret_fast_syscall+0x0/0x28)
    
    Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eaaa11a4f8d04107b5c2e8fbf1563b4a6f45b0df
Author: Anup Patel <Anup.Patel@wdc.com>
Date:   Mon Aug 19 05:14:23 2019 +0000

    RISC-V: Fix FIXMAP area corruption on RV32 systems
    
    [ Upstream commit a256f2e329df0773022d28df2c3d206b9aaf1e61 ]
    
    Currently, various virtual memory areas of Linux RISC-V are organized
    in increasing order of their virtual addresses is as follows:
    1. User space area (This is lowest area and starts at 0x0)
    2. FIXMAP area
    3. VMALLOC area
    4. Kernel area (This is highest area and starts at PAGE_OFFSET)
    
    The maximum size of user space aread is represented by TASK_SIZE.
    
    On RV32 systems, TASK_SIZE is defined as VMALLOC_START which causes the
    user space area to overlap the FIXMAP area. This allows user space apps
    to potentially corrupt the FIXMAP area and kernel OF APIs will crash
    whenever they access corrupted FDT in the FIXMAP area.
    
    On RV64 systems, TASK_SIZE is set to fixed 256GB and no other areas
    happen to overlap so we don't see any FIXMAP area corruptions.
    
    This patch fixes FIXMAP area corruption on RV32 systems by setting
    TASK_SIZE to FIXADDR_START. We also move FIXADDR_TOP, FIXADDR_SIZE,
    and FIXADDR_START defines to asm/pgtable.h so that we can avoid cyclic
    header includes.
    
    Signed-off-by: Anup Patel <anup.patel@wdc.com>
    Tested-by: Alistair Francis <alistair.francis@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22c52133552215a8f41cc6a14249be364573b7f1
Author: Nagarjuna Kristam <nkristam@nvidia.com>
Date:   Wed Aug 28 16:24:57 2019 +0530

    usb: host: xhci-tegra: Set DMA mask correctly
    
    [ Upstream commit 993cc8753453fccfe060a535bbe21fcf1001b626 ]
    
    The Falcon microcontroller that runs the XUSB firmware and which is
    responsible for exposing the XHCI interface can address only 40 bits of
    memory. Typically that's not a problem because Tegra devices don't have
    enough system memory to exceed those 40 bits.
    
    However, if the ARM SMMU is enable on Tegra186 and later, the addresses
    passed to the XUSB controller can be anywhere in the 48-bit IOV address
    space of the ARM SMMU. Since the DMA/IOMMU API starts allocating from
    the top of the IOVA space, the Falcon microcontroller is not able to
    load the firmware successfully.
    
    Fix this by setting the DMA mask to 40 bits, which will force the DMA
    API to map the buffer for the firmware to an IOVA that is addressable by
    the Falcon.
    
    Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/1566989697-13049-1-git-send-email-nkristam@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97b1d81abc613a3e6b1caf9565897824ff1fb2a4
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Wed Jul 24 17:43:06 2019 +0800

    libceph: don't call crypto_free_sync_skcipher() on a NULL tfm
    
    [ Upstream commit e8c99200b4d117c340c392ebd5e62d85dfeed027 ]
    
    In set_secret(), key->tfm is assigned to NULL on line 55, and then
    ceph_crypto_key_destroy(key) is executed.
    
    ceph_crypto_key_destroy(key)
      crypto_free_sync_skcipher(key->tfm)
        crypto_free_skcipher(&tfm->base);
    
    This happens to work because crypto_sync_skcipher is a trivial wrapper
    around crypto_skcipher: &tfm->base is still 0 and crypto_free_skcipher()
    handles that.  Let's not rely on the layout of crypto_sync_skcipher.
    
    This bug is found by a static analysis tool STCheck written by us.
    
    Fixes: 69d6302b65a8 ("libceph: Remove VLA usage of skcipher").
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8632186884a030da2cd83b2e02645e521ab2bbd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Aug 27 13:59:17 2019 +0300

    cifs: Use kzfree() to zero out the password
    
    [ Upstream commit 478228e57f81f6cb60798d54fc02a74ea7dd267e ]
    
    It's safer to zero out the password so that it can never be disclosed.
    
    Fixes: 0c219f5799c7 ("cifs: set domainName when a domain-key is used in multiuser")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8db988a982908b7bff76e095000adabf9c29698b
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Thu Aug 22 08:09:50 2019 +1000

    cifs: set domainName when a domain-key is used in multiuser
    
    [ Upstream commit f2aee329a68f5a907bcff11a109dfe17c0b41aeb ]
    
    RHBZ: 1710429
    
    When we use a domain-key to authenticate using multiuser we must also set
    the domainnmame for the new volume as it will be used and passed to the server
    in the NTLMSSP Domain-name.
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8bf51b5c6f5b6ae443a3f1384c50d5e8e72a461
Author: Evan Quan <evan.quan@amd.com>
Date:   Mon Aug 19 13:17:53 2019 +0800

    drm/amd/powerplay: correct Vega20 dpm level related settings
    
    [ Upstream commit 83e09d5bddbee749fc83063890244397896a1971 ]
    
    Correct the settings for auto mode and skip the unnecessary
    settings for dcefclk and fclk.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5c6d0245f975d23740f2913f222d75a47b823a0
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 27 13:24:52 2019 +0200

    netfilter: conntrack: make sysctls per-namespace again
    
    [ Upstream commit 478553fd1b6f819390b64a2e13ac756c4d1a2836 ]
    
    When I merged the extension sysctl tables with the main one I forgot to
    reset them on netns creation.  They currently read/write init_net settings.
    
    Fixes: d912dec12428 ("netfilter: conntrack: merge acct and helper sysctl table with main one")
    Fixes: cb2833ed0044 ("netfilter: conntrack: merge ecache and timestamp sysctl tables with main one")
    Reported-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
    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 6612f6edf1f10bed542b205cc8e41fa7ef6dff88
Author: Marc Zyngier <maz@kernel.org>
Date:   Sat Aug 24 14:12:31 2019 +0100

    kallsyms: Don't let kallsyms_lookup_size_offset() fail on retrieving the first symbol
    
    [ Upstream commit 2a1a3fa0f29270583f0e6e3100d609e09697add1 ]
    
    An arm64 kernel configured with
    
      CONFIG_KPROBES=y
      CONFIG_KALLSYMS=y
      # CONFIG_KALLSYMS_ALL is not set
      CONFIG_KALLSYMS_BASE_RELATIVE=y
    
    reports the following kprobe failure:
    
      [    0.032677] kprobes: failed to populate blacklist: -22
      [    0.033376] Please take care of using kprobes.
    
    It appears that kprobe fails to retrieve the symbol at address
    0xffff000010081000, despite this symbol being in System.map:
    
      ffff000010081000 T __exception_text_start
    
    This symbol is part of the first group of aliases in the
    kallsyms_offsets array (symbol names generated using ugly hacks in
    scripts/kallsyms.c):
    
      kallsyms_offsets:
              .long   0x1000 // do_undefinstr
              .long   0x1000 // efi_header_end
              .long   0x1000 // _stext
              .long   0x1000 // __exception_text_start
              .long   0x12b0 // do_cp15instr
    
    Looking at the implementation of get_symbol_pos(), it returns the
    lowest index for aliasing symbols. In this case, it return 0.
    
    But kallsyms_lookup_size_offset() considers 0 as a failure, which
    is obviously wrong (there is definitely a valid symbol living there).
    In turn, the kprobe blacklisting stops abruptly, hence the original
    error.
    
    A CONFIG_KALLSYMS_ALL kernel wouldn't fail as there is always
    some random symbols at the beginning of this array, which are never
    looked up via kallsyms_lookup_size_offset.
    
    Fix it by considering that get_symbol_pos() is always successful
    (which is consistent with the other uses of this function).
    
    Fixes: ffc5089196446 ("[PATCH] Create kallsyms_lookup_size_offset()")
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c1a4283b60675f95c1f97c743e75948de15fc70
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Aug 27 15:16:36 2019 +0800

    NFS: remove set but not used variable 'mapping'
    
    [ Upstream commit 99300a85260c2b7febd57082a617d1062532067e ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    fs/nfs/write.c: In function nfs_page_async_flush:
    fs/nfs/write.c:609:24: warning: variable mapping set but not used [-Wunused-but-set-variable]
    
    It is not use since commit aefb623c422e ("NFS: Fix
    writepage(s) error handling to not report errors twice")
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de932b20ed88cd9899046b7abc4c20b9a3356f5c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Aug 27 07:03:28 2019 -0400

    NFSv2: Fix write regression
    
    [ Upstream commit d33d4beb522987d1c305c12500796f9be3687dee ]
    
    Ensure we update the write result count on success, since the
    RPC call itself does not do so.
    
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Tested-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 646d295fdded37e69b81652a8c89e9d9c0c58f93
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Aug 26 20:41:16 2019 -0400

    NFSv2: Fix eof handling
    
    [ Upstream commit 71affe9be45a5c60b9772e1b2701710712637274 ]
    
    If we received a reply from the server with a zero length read and
    no error, then that implies we are at eof.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16986c7cf8b5fc2ca5bcf6b3dc84c4e3dac504e1
Author: Thomas Jarosch <thomas.jarosch@intra2net.com>
Date:   Wed Aug 21 16:14:28 2019 +0200

    netfilter: nf_conntrack_ftp: Fix debug output
    
    [ Upstream commit 3a069024d371125227de3ac8fa74223fcf473520 ]
    
    The find_pattern() debug output was printing the 'skip' character.
    This can be a NULL-byte and messes up further pr_debug() output.
    
    Output without the fix:
    kernel: nf_conntrack_ftp: Pattern matches!
    kernel: nf_conntrack_ftp: Skipped up to `<7>nf_conntrack_ftp: find_pattern `PORT': dlen = 8
    kernel: nf_conntrack_ftp: find_pattern `EPRT': dlen = 8
    
    Output with the fix:
    kernel: nf_conntrack_ftp: Pattern matches!
    kernel: nf_conntrack_ftp: Skipped up to 0x0 delimiter!
    kernel: nf_conntrack_ftp: Match succeeded!
    kernel: nf_conntrack_ftp: conntrack_ftp: match `172,17,0,100,200,207' (20 bytes at 4150681645)
    kernel: nf_conntrack_ftp: find_pattern `PORT': dlen = 8
    
    Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dec70d3c24931cbc159c2c08ef1b7669e714c6d
Author: Todd Seidelmann <tseidelmann@linode.com>
Date:   Wed Aug 21 11:47:53 2019 -0400

    netfilter: xt_physdev: Fix spurious error message in physdev_mt_check
    
    [ Upstream commit 3cf2f450fff304be9cf4868bf0df17f253bc5b1c ]
    
    Simplify the check in physdev_mt_check() to emit an error message
    only when passed an invalid chain (ie, NF_INET_LOCAL_OUT).
    This avoids cluttering up the log with errors against valid rules.
    
    For large/heavily modified rulesets, current behavior can quickly
    overwhelm the ring buffer, because this function gets called on
    every change, regardless of the rule that was changed.
    
    Signed-off-by: Todd Seidelmann <tseidelmann@linode.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 e3813a30bd6fce930935634466f6c020dfcdf4a3
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Aug 16 14:56:35 2019 +0200

    drm/amdgpu: fix dma_fence_wait without reference
    
    [ Upstream commit 42068e1ef961c719f967dbbb4ddcb394a0ba7917 ]
    
    We need to grab a reference to the fence we wait for.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b914306b0f76710d3699e0bdf1ee6ab1035d703
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat Aug 24 10:39:00 2019 -0400

    NFS: Fix writepage(s) error handling to not report errors twice
    
    [ Upstream commit 96c4145599b30c0eb6cbeaa24207802452dd1872 ]
    
    If writepage()/writepages() saw an error, but handled it without
    reporting it, we should not be re-reporting that error on exit.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78f0f9007523f2e0bbe840f75ef77ec60e153b2d
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Aug 15 12:26:05 2019 -0400

    NFS: Fix spurious EIO read errors
    
    [ Upstream commit 8f54c7a4babf58bbaf849e126f7ae9664bdc9e04 ]
    
    If the client attempts to read a page, but the read fails due to some
    spurious error (e.g. an ACCESS error or a timeout, ...) then we need
    to allow other processes to retry.
    Also try to report errors correctly when doing a synchronous readpage.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa38f165c78a0b73627e0f2fa6e89a3df14e284c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Aug 23 08:37:50 2019 -0400

    pNFS/flexfiles: Don't time out requests on hard mounts
    
    [ Upstream commit 7af46292dadcf8870946916f79fdddf79bd7267f ]
    
    If the mount is hard, we should ignore the 'io_maxretrans' module
    parameter so that we always keep retrying.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7999b21e22246b58a800655ee5cc63ea819b34d5
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Aug 21 15:16:31 2019 +0200

    x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled machines
    
    [ Upstream commit 3e5bedc2c258341702ddffbd7688c5e6eb01eafa ]
    
    Rahul Tanwar reported the following bug on DT systems:
    
    > 'ioapic_dynirq_base' contains the virtual IRQ base number. Presently, it is
    > updated to the end of hardware IRQ numbers but this is done only when IOAPIC
    > configuration type is IOAPIC_DOMAIN_LEGACY or IOAPIC_DOMAIN_STRICT. There is
    > a third type IOAPIC_DOMAIN_DYNAMIC which applies when IOAPIC configuration
    > comes from devicetree.
    >
    > See dtb_add_ioapic() in arch/x86/kernel/devicetree.c
    >
    > In case of IOAPIC_DOMAIN_DYNAMIC (DT/OF based system), 'ioapic_dynirq_base'
    > remains to zero initialized value. This means that for OF based systems,
    > virtual IRQ base will get set to zero.
    
    Such systems will very likely not even boot.
    
    For DT enabled machines ioapic_dynirq_base is irrelevant and not
    updated, so simply map the IRQ base 1:1 instead.
    
    Reported-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
    Tested-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
    Tested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: alan@linux.intel.com
    Cc: bp@alien8.de
    Cc: cheol.yong.kim@intel.com
    Cc: qi-ming.wu@intel.com
    Cc: rahul.tanwar@intel.com
    Cc: rppt@linux.ibm.com
    Cc: tony.luck@intel.com
    Link: http://lkml.kernel.org/r/20190821081330.1187-1-rahul.tanwar@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c19a0d7ef095adaad3c0e6d021bc623537c020e6
Author: Prashant Malani <pmalani@chromium.org>
Date:   Sat Aug 24 01:36:19 2019 -0700

    r8152: Set memory to all 0xFFs on failed reg reads
    
    [ Upstream commit f53a7ad189594a112167efaf17ea8d0242b5ac00 ]
    
    get_registers() blindly copies the memory written to by the
    usb_control_msg() call even if the underlying urb failed.
    
    This could lead to junk register values being read by the driver, since
    some indirect callers of get_registers() ignore the return values. One
    example is:
      ocp_read_dword() ignores the return value of generic_ocp_read(), which
      calls get_registers().
    
    So, emulate PCI "Master Abort" behavior by setting the buffer to all
    0xFFs when usb_control_msg() fails.
    
    This patch is copied from the r8152 driver (v2.12.0) published by
    Realtek (www.realtek.com).
    
    Signed-off-by: Prashant Malani <pmalani@chromium.org>
    Acked-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1b6d7c8de4ca31e2d1ae6d4a5a766d940048089
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Tue Aug 20 17:50:25 2019 +0200

    bpf: allow narrow loads of some sk_reuseport_md fields with offset > 0
    
    [ Upstream commit 2c238177bd7f4b14bdf7447cc1cd9bb791f147e6 ]
    
    test_select_reuseport fails on s390 due to verifier rejecting
    test_select_reuseport_kern.o with the following message:
    
            ; data_check.eth_protocol = reuse_md->eth_protocol;
            18: (69) r1 = *(u16 *)(r6 +22)
            invalid bpf_context access off=22 size=2
    
    This is because on big-endian machines casts from __u32 to __u16 are
    generated by referencing the respective variable as __u16 with an offset
    of 2 (as opposed to 0 on little-endian machines).
    
    The verifier already has all the infrastructure in place to allow such
    accesses, it's just that they are not explicitly enabled for
    eth_protocol field. Enable them for eth_protocol field by using
    bpf_ctx_range instead of offsetof.
    
    Ditto for ip_protocol, bind_inany and len, since they already allow
    narrowing, and the same problem can arise when working with them.
    
    Fixes: 2dbb9b9e6df6 ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e0251d82954b488c652befe3f330bacfe0fadce
Author: Jakub Sitnicki <jakub@cloudflare.com>
Date:   Wed Aug 21 14:17:20 2019 +0200

    flow_dissector: Fix potential use-after-free on BPF_PROG_DETACH
    
    [ Upstream commit db38de39684dda2bf307f41797db2831deba64e9 ]
    
    Call to bpf_prog_put(), with help of call_rcu(), queues an RCU-callback to
    free the program once a grace period has elapsed. The callback can run
    together with new RCU readers that started after the last grace period.
    New RCU readers can potentially see the "old" to-be-freed or already-freed
    pointer to the program object before the RCU update-side NULLs it.
    
    Reorder the operations so that the RCU update-side resets the protected
    pointer before the end of the grace period after which the program will be
    freed.
    
    Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
    Reported-by: Lorenz Bauer <lmb@cloudflare.com>
    Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
    Acked-by: Petar Penkov <ppenkov@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31320b857d1365cceaa663b078a3713e183ecad4
Author: Sven Eckelmann <sven@narfation.org>
Date:   Thu Aug 22 08:55:36 2019 +0200

    batman-adv: Only read OGM2 tvlv_len after buffer len check
    
    [ Upstream commit 0ff0f15a32c093381ad1abc06abe85afb561ab28 ]
    
    Multiple batadv_ogm2_packet can be stored in an skbuff. The functions
    batadv_v_ogm_send_to_if() uses batadv_v_ogm_aggr_packet() to check if there
    is another additional batadv_ogm2_packet in the skb or not before they
    continue processing the packet.
    
    The length for such an OGM2 is BATADV_OGM2_HLEN +
    batadv_ogm2_packet->tvlv_len. The check must first check that at least
    BATADV_OGM2_HLEN bytes are available before it accesses tvlv_len (which is
    part of the header. Otherwise it might try read outside of the currently
    available skbuff to get the content of tvlv_len.
    
    Fixes: 9323158ef9f4 ("batman-adv: OGMv2 - implement originators logic")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ae47d48cd2da69e0df6762fceee99205f4e3065
Author: Doug Berger <opendmb@gmail.com>
Date:   Mon Jul 1 18:50:11 2019 +0100

    ARM: 8874/1: mm: only adjust sections of valid mm structures
    
    [ Upstream commit c51bc12d06b3a5494fbfcbd788a8e307932a06e9 ]
    
    A timing hazard exists when an early fork/exec thread begins
    exiting and sets its mm pointer to NULL while a separate core
    tries to update the section information.
    
    This commit ensures that the mm pointer is not NULL before
    setting its section parameters. The arguments provided by
    commit 11ce4b33aedc ("ARM: 8672/1: mm: remove tasklist locking
    from update_sections_early()") are equally valid for not
    requiring grabbing the task_lock around this check.
    
    Fixes: 08925c2f124f ("ARM: 8464/1: Update all mm structures with section adjustments")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Acked-by: Laura Abbott <labbott@redhat.com>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Rob Herring <robh@kernel.org>
    Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
    Cc: Peng Fan <peng.fan@nxp.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b77b8c17df13fede07e8cbe0a188a94926a07b31
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed Aug 21 13:12:09 2019 +0200

    drm/virtio: use virtio_max_dma_size
    
    [ Upstream commit 9b2a0a1ef66f96bf34921a3865581eca32ff05ec ]
    
    We must make sure our scatterlist segments are not too big, otherwise
    we might see swiotlb failures (happens with sev, also reproducable with
    swiotlb=force).
    
    Suggested-by: Laszlo Ersek <lersek@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20190821111210.27165-1-kraxel@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a2ffd1ffa54f6f7e67bfdd84b83dad63d91282a
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Wed Aug 21 21:32:26 2019 +0300

    drm/omap: Fix port lookup for SDI output
    
    [ Upstream commit 8090f7eb318d4241625449252db2741e7703e027 ]
    
    When refactoring port lookup for DSS outputs, commit d17eb4537a7e
    ("drm/omap: Factor out common init/cleanup code for output devices")
    incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
    (which uses the DT port 1) and DPI outputs other than DPI0 (which are
    not used in mainline DT sources).
    
    Fix this by using the port number from the output omap_dss_device
    of_ports field.
    
    Fixes: d17eb4537a7e ("drm/omap: Factor out common init/cleanup code for output devices")
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190821183226.13784-1-laurent.pinchart@ideasonboard.com
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc45ccc7b85b69ec142689ebf423ff982591d5c2
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 20 23:46:36 2019 -0500

    qed: Add cleanup in qed_slowpath_start()
    
    [ Upstream commit de0e4fd2f07ce3bbdb69dfb8d9426b7227451b69 ]
    
    If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
    memory leaks. To fix this issue, introduce the label 'err4' to perform the
    cleanup work before returning the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 304a65866fbec17cdf1ea5f8c75f331c7df81a97
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Tue Aug 20 15:41:34 2019 +0200

    selftests/bpf: add config fragment BPF_JIT
    
    [ Upstream commit 0604409df9e04cdec7b08d471c8c1c0c10b5554d ]
    
    When running test_kmod.sh the following shows up
    
     # sysctl cannot stat /proc/sys/net/core/bpf_jit_enable No such file or directory
     cannot: stat_/proc/sys/net/core/bpf_jit_enable #
     # sysctl cannot stat /proc/sys/net/core/bpf_jit_harden No such file or directory
     cannot: stat_/proc/sys/net/core/bpf_jit_harden #
    
    Rework to enable CONFIG_BPF_JIT to solve "No such file or directory"
    
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c963cd4ec138094015a96ede53dc4e61d3cd2c01
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Tue Aug 20 16:18:04 2019 +0200

    selftests/bpf: fix test_cgroup_storage on s390
    
    [ Upstream commit 806ce6e2117a42528e7bb979e04e28229b34a612 ]
    
    test_cgroup_storage fails on s390 with an assertion failure: packets are
    dropped when they shouldn't. The problem is that BPF_DW packet count is
    accessed as BPF_W with an offset of 0, which is not correct on
    big-endian machines.
    
    Since the point of this test is not to verify narrow loads/stores,
    simply use BPF_DW when working with packet counts.
    
    Fixes: 68cfa3ac6b8d ("selftests/bpf: add a cgroup storage test")
    Fixes: 919646d2a3a9 ("selftests/bpf: extend the storage test to test per-cpu cgroup storage")
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4a9b28782c609b184a746c3549f0c161198c0b5
Author: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date:   Thu Aug 15 23:56:35 2019 +0300

    xdp: unpin xdp umem pages in error path
    
    [ Upstream commit fb89c39455e4b49881c5a42761bd71f03d3ef888 ]
    
    Fix mem leak caused by missed unpin routine for umem pages.
    
    Fixes: 8aef7340ae9695 ("xsk: introduce xdp_umem_page")
    Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
    Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b484e28554d0a69488144fda2a1bba5add8cf2a7
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Aug 19 07:04:25 2019 +0200

    Kconfig: Fix the reference to the IDT77105 Phy driver in the description of ATM_NICSTAR_USE_IDT77105
    
    [ Upstream commit cd9d4ff9b78fcd0fc4708900ba3e52e71e1a7690 ]
    
    This should be IDT77105, not IDT77015.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8438c08476c2cecde71c4501cb3ad01801f9e22
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Aug 14 15:42:43 2019 -0400

    NFS: On fatal writeback errors, we need to call nfs_inode_remove_request()
    
    [ Upstream commit 06c9fdf3b9f1acc6e53753c99c54c39764cc979f ]
    
    If the writeback error is fatal, we need to remove the tracking structures
    (i.e. the nfs_page) from the inode.
    
    Fixes: 6fbda89b257f ("NFS: Replace custom error reporting mechanism...")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 518c9d0158e06324f51845faccf58073f79be926
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Aug 14 14:19:09 2019 -0400

    NFS: Fix initialisation of I/O result struct in nfs_pgio_rpcsetup
    
    [ Upstream commit 17d8c5d145000070c581f2a8aa01edc7998582ab ]
    
    Initialise the result count to 0 rather than initialising it to the
    argument count. The reason is that we want to ensure we record the
    I/O stats correctly in the case where an error is returned (for
    instance in the layoutstats).
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d29a04e98cdb2f17b64b51d5dcf5a6848e1ba2e5
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Aug 9 12:15:07 2019 -0400

    NFSv4: Fix return value in nfs_finish_open()
    
    [ Upstream commit 9821421a291b548ef4369c6998745baa36ddecd5 ]
    
    If the file turns out to be of the wrong type after opening, we want
    to revalidate the path and retry, so return EOPENSTALE rather than
    ESTALE.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8cb57c86f936b3a629d0e15819400a942c6831c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Aug 9 15:03:11 2019 -0400

    NFSv4: Fix return values for nfs4_file_open()
    
    [ Upstream commit 90cf500e338ab3f3c0f126ba37e36fb6a9058441 ]
    
    Currently, we are translating RPC level errors such as timeouts,
    as well as interrupts etc into EOPENSTALE, which forces a single
    replay of the open attempt. What we actually want to do is
    force the replay only in the cases where the returned error
    indicates that the file may have changed on the server.
    
    So the fix is to spell out the exact set of errors where we want
    to return EOPENSTALE.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7844dde203db2656bb32849764fb48dc140c4cd6
Author: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
Date:   Fri Aug 16 17:02:22 2019 +0200

    netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info
    
    [ Upstream commit 89a26cd4b501e9511d3cd3d22327fc76a75a38b3 ]
    
    When running a 64-bit kernel with a 32-bit iptables binary, the size of
    the xt_nfacct_match_info struct diverges.
    
        kernel: sizeof(struct xt_nfacct_match_info) : 40
        iptables: sizeof(struct xt_nfacct_match_info)) : 36
    
    Trying to append nfacct related rules results in an unhelpful message.
    Although it is suggested to look for more information in dmesg, nothing
    can be found there.
    
        # iptables -A <chain> -m nfacct --nfacct-name <acct-object>
        iptables: Invalid argument. Run `dmesg' for more information.
    
    This patch fixes the memory misalignment by enforcing 8-byte alignment
    within the struct's first revision. This solution is often used in many
    other uapi netfilter headers.
    
    Signed-off-by: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.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 f30dade2d5d5f20b285e8fcb9f9d3d371a7a7dd8
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Aug 16 11:23:58 2019 +0200

    netfilter: nft_flow_offload: missing netlink attribute policy
    
    [ Upstream commit 14c415862c0630e01712a4eeaf6159a2b1b6d2a4 ]
    
    The netlink attribute policy for NFTA_FLOW_TABLE_NAME is missing.
    
    Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 399676d85515354affca656ca8d98286ba58795b
Author: Todd Seidelmann <tseidelmann@linode.com>
Date:   Wed Aug 14 10:54:16 2019 -0400

    netfilter: ebtables: Fix argument order to ADD_COUNTER
    
    [ Upstream commit f20faa06d83de440bec8e200870784c3458793c4 ]
    
    The ordering of arguments to the x_tables ADD_COUNTER macro
    appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
    and arp_tables.c).
    
    This causes data corruption in the ebtables userspace tools
    because they get incorrect packet & byte counts from the kernel.
    
    Fixes: d72133e628803 ("netfilter: ebtables: use ADD_COUNTER macro")
    Signed-off-by: Todd Seidelmann <tseidelmann@linode.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b0d408d8ad60c431282a814c11a7d8985dbe221
Author: Phil Reid <preid@electromag.com.au>
Date:   Thu Jul 25 10:48:45 2019 +0800

    fpga: altera-ps-spi: Fix getting of optional confd gpio
    
    [ Upstream commit dec43da46f63eb71f519d963ba6832838e4262a3 ]
    
    Currently the driver does not handle EPROBE_DEFER for the confd gpio.
    Use devm_gpiod_get_optional() instead of devm_gpiod_get() and return
    error codes from altera_ps_probe().
    
    Fixes: 5692fae0742d ("fpga manager: Add altera-ps-spi driver for Altera FPGAs")
    Signed-off-by: Phil Reid <preid@electromag.com.au>
    Signed-off-by: Moritz Fischer <mdf@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52ba08b93fee220b416e98254e8f95e8d0958158
Author: Quentin Monnet <quentin.monnet@netronome.com>
Date:   Thu Aug 15 15:22:23 2019 +0100

    tools: bpftool: close prog FD before exit on showing a single program
    
    [ Upstream commit d34b044038bfb0e19caa8b019910efc465f41d5f ]
    
    When showing metadata about a single program by invoking
    "bpftool prog show PROG", the file descriptor referring to the program
    is not closed before returning from the function. Let's close it.
    
    Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
    Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
    Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Acked-by: Andrii Nakryiko <andriin@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 840aec7a8b483429f25c2963a6ba302b22c0a4ee
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Wed Aug 14 12:41:09 2019 +0200

    selftests/bpf: fix "bind{4, 6} deny specific IP & port" on s390
    
    [ Upstream commit 27df5c7068bf23cab282dc64b1c9894429b3b8a0 ]
    
    "bind4 allow specific IP & port" and "bind6 deny specific IP & port"
    fail on s390 because of endianness issue: the 4 IP address bytes are
    loaded as a word and compared with a constant, but the value of this
    constant should be different on big- and little- endian machines, which
    is not the case right now.
    
    Use __bpf_constant_ntohl to generate proper value based on machine
    endianness.
    
    Fixes: 1d436885b23b ("selftests/bpf: Selftest for sys_bind post-hooks.")
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99eb87b50faa264105a40343a31c72211ec5e9e3
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Mon Aug 12 18:18:07 2019 +0200

    s390/bpf: use 32-bit index for tail calls
    
    [ Upstream commit 91b4db5313a2c793aabc2143efb8ed0cf0fdd097 ]
    
    "p runtime/jit: pass > 32bit index to tail_call" fails when
    bpf_jit_enable=1, because the tail call is not executed.
    
    This in turn is because the generated code assumes index is 64-bit,
    while it must be 32-bit, and as a result prog array bounds check fails,
    while it should pass. Even if bounds check would have passed, the code
    that follows uses 64-bit index to compute prog array offset.
    
    Fix by using clrj instead of clgrj for comparing index with array size,
    and also by using llgfr for truncating index to 32 bits before using it
    to compute prog array offset.
    
    Fixes: 6651ee070b31 ("s390/bpf: implement bpf_tail_call() helper")
    Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
    Acked-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62c3bfff7d9e9ae9e0f56e0cd2fc5b13e3a41f7f
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Jul 23 00:29:23 2019 -0700

    ARM: dts: Fix incomplete dts data for am3 and am4 mmc
    
    [ Upstream commit 5b63fb90adb95a178ad403e1703f59bf1ff2c16b ]
    
    Commit 4e27f752ab8c ("ARM: OMAP2+: Drop mmc platform data for am330x and
    am43xx") dropped legacy mmc platform data for am3 and am4, but missed the
    fact that we never updated the dts files for mmc3 that is directly on l3
    interconnect instead of l4 interconnect. This leads to a situation with
    no legacy platform data and incomplete dts data.
    
    Let's update the mmc instances on l3 interconnect to probe properly with
    ti-sysc interconnect target module driver to make mmc3 work again. Let's
    still keep legacy "ti,hwmods" property around for v5.2 kernel and only
    drop it later on.
    
    Note that there is no need to use property status = "disabled" for mmc3.
    The default for dts is enabled, and runtime PM will idle unused instances
    just fine.
    
    Fixes: 4e27f752ab8c ("ARM: OMAP2+: Drop mmc platform data for am330x and am43xx")
    Reported-by: David Lechner <david@lechnology.com>
    Tested-by: David Lechner <david@lechnology.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a3d2a039339b446cd8f901e65a5843a2962db3a
Author: Suman Anna <s-anna@ti.com>
Date:   Tue Jun 25 18:33:15 2019 -0500

    bus: ti-sysc: Simplify cleanup upon failures in sysc_probe()
    
    [ Upstream commit a304f483b6b00d42bde41c45ca52c670945348e2 ]
    
    The clocks are not yet parsed and prepared until after a successful
    sysc_get_clocks(), so there is no need to unprepare the clocks upon
    any failure of any of the prior functions in sysc_probe(). The current
    code path would have been a no-op because of the clock validity checks
    within sysc_unprepare(), but let's just simplify the cleanup path by
    returning the error directly.
    
    While at this, also fix the cleanup path for a sysc_init_resets()
    failure which is executed after the clocks are prepared.
    
    Signed-off-by: Suman Anna <s-anna@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e92814b0aae18a95fe6c5e7002b32fa9aaa0a640
Author: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date:   Sun Aug 11 10:48:02 2019 +0200

    ARM: OMAP1: ams-delta-fiq: Fix missing irq_ack
    
    [ Upstream commit fa8397e45c64e60c80373bc19ee56e42a6bed9b6 ]
    
    Non-serio path of Amstrad Delta FIQ deferred handler depended on
    irq_ack() method provided by OMAP GPIO driver.  That method has been
    removed by commit 693de831c6e5 ("gpio: omap: remove irq_ack method").
    Remove useless code from the deferred handler and reimplement the
    missing operation inside the base FIQ handler.
    
    Should another dependency - irq_unmask() - be ever removed from the OMAP
    GPIO driver, WARN once if missing.
    
    Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d8729676adb9963e1d787390ec05d14bd894ab1
Author: Faiz Abbas <faiz_abbas@ti.com>
Date:   Wed Aug 7 16:22:38 2019 +0530

    ARM: dts: dra74x: Fix iodelay configuration for mmc3
    
    [ Upstream commit 07f9a8be66a9bd86f9eaedf8f8aeb416195adab8 ]
    
    According to the latest am572x[1] and dra74x[2] data manuals, mmc3
    default, hs, sdr12 and sdr25 modes use iodelay values given in
    MMC3_MANUAL1. Set the MODE_SELECT bit for these so that manual mode is
    selected and correct iodelay values can be configured.
    
    [1] http://www.ti.com/lit/ds/symlink/am5728.pdf
    [2] http://www.ti.com/lit/ds/symlink/dra746.pdf
    
    Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70af7f6d9e6a7e1db12a8e3045580f83eb9cfacf
Author: Emmanuel Vadot <manu@freebsd.org>
Date:   Wed Jul 24 14:23:29 2019 +0200

    ARM: dts: am335x: Fix UARTs length
    
    [ Upstream commit 8613e2ca4fff764f23785eadfa54a08631ee682a ]
    
    As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size.
    Fix this in the DTS.
    
    Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6858c94d535c396e0854f2cbcd33c97d1828f36
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Jul 23 04:37:45 2019 -0700

    ARM: OMAP2+: Fix omap4 errata warning on other SoCs
    
    [ Upstream commit 45da5e09dd32fa98c32eaafe2513db6bd75e2f4f ]
    
    We have errata i688 workaround produce warnings on SoCs other than
    omap4 and omap5:
    
    omap4_sram_init:Unable to allocate sram needed to handle errata I688
    omap4_sram_init:Unable to get sram pool needed to handle errata I688
    
    This is happening because there is no ti,omap4-mpu node, or no SRAM
    to configure for the other SoCs, so let's remove the warning based
    on the SoC revision checks.
    
    As nobody has complained it seems that the other SoC variants do not
    need this workaround.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71d668a95351dbdd7763627075baf321e5eae380
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Mon Aug 12 17:03:32 2019 +0200

    s390/bpf: fix lcgr instruction encoding
    
    [ Upstream commit bb2d267c448f4bc3a3389d97c56391cb779178ae ]
    
    "masking, test in bounds 3" fails on s390, because
    BPF_ALU64_IMM(BPF_NEG, BPF_REG_2, 0) ignores the top 32 bits of
    BPF_REG_2. The reason is that JIT emits lcgfr instead of lcgr.
    The associated comment indicates that the code was intended to
    emit lcgr in the first place, it's just that the wrong opcode
    was used.
    
    Fix by using the correct opcode.
    
    Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Acked-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f262a47d4bc97b93bb2b53cf517ba08f3883c523
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Tue Jun 25 14:36:47 2019 +0200

    arm64: dts: meson-g12a: add missing dwc2 phy-names
    
    [ Upstream commit 3d4bacdc207a7b62941700b374e7199cbb184a43 ]
    
    The G12A USB2 OTG capable PHY uses a 8bit large UTMI bus, and the OTG
    controller gets the PHY but width by probing the associated phy.
    
    By default it will use 16bit wide settings if a phy is not specified,
    in our case we specified the phy, but not the phy-names.
    
    The dwc2 bindings specifies that if phys is present, phy-names shall be
    "usb2-phy".
    
    Adding phy-names = "usb2-phy" solves the OTG PHY bus configuration.
    
    Fixes: 9baf7d6be730 ("arm64: dts: meson: g12a: Add G12A USB nodes")
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d3879d57e3b6d6f6fb8a5059d4622c190ffbc51
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jul 22 03:44:42 2019 -0700

    ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7
    
    [ Upstream commit 89bbc6f1eb90809b1538b3a9c54030c558180e3b ]
    
    We are currently using a wrong register for dcan revision. Although
    this is currently only used for detecting the dcan module, let's
    fix it to avoid confusion.
    
    Tested-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d326307187b37026706ba225b4b307cb962ed9a
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jul 22 03:44:47 2019 -0700

    ARM: dts: Fix flags for gpio7
    
    [ Upstream commit 2e8647bbe1c8233a20c32fd2648258f2c05c7335 ]
    
    The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at
    the interconnect target module level for the modules that have it
    defined. Otherwise we get the following warnings:
    
    dts flag should be at module level for ti,no-idle-on-init
    dts flag should be at module level for ti,no-reset-on-init
    
    Reviewed-by: Suman Anna <s-anna@ti.com>
    Tested-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de457d8d0f18d5f1b6523e6bfc80f9154fe2f6e7
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jul 22 03:44:52 2019 -0700

    bus: ti-sysc: Fix using configured sysc mask value
    
    [ Upstream commit e212abd452a4af3174fcd469d46656f83e135a19 ]
    
    We have cases where there are no softreset bits like with am335x lcdc.
    In that case ti,sysc-mask = <0> needs to be handled properly.
    
    Tested-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84b9540898a9f4b15040b1ea1f42bf11c499336a
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jul 22 03:44:42 2019 -0700

    bus: ti-sysc: Fix handling of forced idle
    
    [ Upstream commit 6ee8241d17c68b94a91efabfd6bdfe63bb1b79c1 ]
    
    For some devices we can get the following warning on boot:
    
    ti-sysc 48485200.target-module: sysc_disable_module: invalid midlemode
    
    Fix this by treating SYSC_IDLE_FORCE like we do for the other bits
    for idlemodes mask.
    
    Fixes: d59b60564cbf ("bus: ti-sysc: Add generic enable/disable functions")
    Cc: Roger Quadros <rogerq@ti.com>
    Reviewed-by: Suman Anna <s-anna@ti.com>
    Tested-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f500d6b3df25c0ed55a558a7305c9111dca1730
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jul 22 03:44:52 2019 -0700

    ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss
    
    [ Upstream commit afd58b162e48076e3fe66d08a69eefbd6fe71643 ]
    
    TRM says PWMSS_SYSCONFIG bit for SOFTRESET changes to zero when
    reset is completed. Let's configure it as otherwise we get warnings
    on boot when we check the data against dts provided data. Eventually
    the legacy platform data will be just dropped, but let's fix the
    warning first.
    
    Reviewed-by: Suman Anna <s-anna@ti.com>
    Tested-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cff4410f5d31aa29172e13b02d7d2f693f977673
Author: Faiz Abbas <faiz_abbas@ti.com>
Date:   Wed Jun 19 15:54:54 2019 +0530

    ARM: dts: am57xx: Disable voltage switching for SD card
    
    [ Upstream commit fb59ee37cfe20d10d19568899d1458a58361246c ]
    
    If UHS speed modes are enabled, a compatible SD card switches down to
    1.8V during enumeration. If after this a software reboot/crash takes
    place and on-chip ROM tries to enumerate the SD card, the difference in
    IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card.
    
    The fix for this is to have support for power cycling the card in
    hardware (with a PORz/soft-reset line causing a power cycle of the
    card). Because the beaglebone X15 (rev A,B and C), am57xx-idks and
    am57xx-evms don't have this capability, disable voltage switching for
    these boards.
    
    The major effect of this is that the maximum supported speed
    mode is now high speed(50 MHz) down from SDR104(200 MHz).
    
    commit 88a748419b84 ("ARM: dts: am57xx-idk: Remove support for voltage
    switching for SD card") did this only for idk boards. Do it for all
    affected boards.
    
    Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05b57db138f369e9d6a27d6584f8faf865e5d358
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sun Apr 28 23:48:10 2019 +0800

    ieee802154: hwsim: unregister hw while hwsim_subscribe_all_others fails
    
    [ Upstream commit de166bbe861738c8bc3e5dad5b03f45d7d6ef914 ]
    
    KASAN report this:
    
    kernel BUG at net/mac802154/main.c:130!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 0 PID: 19932 Comm: modprobe Not tainted 5.1.0-rc6+ #22
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    RIP: 0010:ieee802154_free_hw+0x2a/0x30 [mac802154]
    Code: 55 48 8d 57 38 48 89 e5 53 48 89 fb 48 8b 47 38 48 39 c2 75 15 48 8d 7f 48 e8 82 85 16 e1 48 8b 7b 28 e8 f9 ef 83 e2 5b 5d c3 <0f> 0b 0f 1f 40 00 55 48 89 e5 53 48 89 fb 0f b6 86 80 00 00 00 88
    RSP: 0018:ffffc90001c7b9f0 EFLAGS: 00010206
    RAX: ffff88822df3aa80 RBX: ffff88823143d5c0 RCX: 0000000000000002
    RDX: ffff88823143d5f8 RSI: ffff88822b1fabc0 RDI: ffff88823143d5c0
    RBP: ffffc90001c7b9f8 R08: 0000000000000000 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffff4
    R13: ffff88822dea4f50 R14: ffff88823143d7c0 R15: 00000000fffffff4
    FS: 00007ff52e999540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fdc06dba768 CR3: 000000023160a000 CR4: 00000000000006f0
    Call Trace:
     hwsim_add_one+0x2dd/0x540 [mac802154_hwsim]
     hwsim_probe+0x2f/0xb0 [mac802154_hwsim]
     platform_drv_probe+0x3a/0x90
     ? driver_sysfs_add+0x79/0xb0
     really_probe+0x1d4/0x2d0
     driver_probe_device+0x50/0xf0
     device_driver_attach+0x54/0x60
     __driver_attach+0x7e/0xd0
     ? device_driver_attach+0x60/0x60
     bus_for_each_dev+0x68/0xc0
     driver_attach+0x19/0x20
     bus_add_driver+0x15e/0x200
     driver_register+0x5b/0xf0
     __platform_driver_register+0x31/0x40
     hwsim_init_module+0x74/0x1000 [mac802154_hwsim]
     ? 0xffffffffa00e9000
     do_one_initcall+0x6c/0x3cc
     ? kmem_cache_alloc_trace+0x248/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
    RIP: 0033:0x7ff52e4a2839
    Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
    RSP: 002b:00007ffffa7b3c08 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 00005647560a2a00 RCX: 00007ff52e4a2839
    RDX: 0000000000000000 RSI: 00005647547f3c2e RDI: 0000000000000003
    RBP: 00005647547f3c2e R08: 0000000000000000 R09: 00005647560a2a00
    R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
    R13: 00005647560a2c10 R14: 0000000000040000 R15: 00005647560a2a00
    Modules linked in: mac802154_hwsim(+) mac802154 [last unloaded: mac802154_hwsim]
    
    In hwsim_add_one, if hwsim_subscribe_all_others fails, we
    should call ieee802154_unregister_hw to free resources.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Alexander Aring <aring@mojatatu.com>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b090ed1779d8f94f009286729e6a5281b462f03d
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sun Apr 28 22:14:51 2019 +0800

    ieee802154: hwsim: Fix error handle path in hwsim_init_module
    
    [ Upstream commit 1cbbbf39efab05fae67f59e6ed01bb85061c69e2 ]
    
    KASAN report this:
    
    BUG: unable to handle kernel paging request at fffffbfff834f001
    PGD 237fe8067 P4D 237fe8067 PUD 237e64067 PMD 1c968d067 PTE 0
    Oops: 0000 [#1] SMP KASAN PTI
    CPU: 1 PID: 8871 Comm: syz-executor.0 Tainted: G         C        5.0.0+ #5
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    RIP: 0010:strcmp+0x31/0xa0 lib/string.c:328
    Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
    RSP: 0018:ffff8881e0c57800 EFLAGS: 00010246
    RAX: 1ffffffff834f001 RBX: ffffffffc1a78000 RCX: ffffffff827b9503
    RDX: 0000000000000000 RSI: ffffffffc1a40008 RDI: ffffffffc1a78008
    RBP: ffffffffc1a78009 R08: fffffbfff6a92195 R09: fffffbfff6a92195
    R10: ffff8881e0c578b8 R11: fffffbfff6a92194 R12: ffffffffc1a40008
    R13: dffffc0000000000 R14: ffffffffc1a3e470 R15: ffffffffc1a40000
    FS:  00007fdcc02ff700(0000) GS:ffff8881f7300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: fffffbfff834f001 CR3: 00000001b3134003 CR4: 00000000007606e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     genl_family_find_byname+0x7f/0xf0 net/netlink/genetlink.c:104
     genl_register_family+0x1e1/0x1070 net/netlink/genetlink.c:333
     ? 0xffffffffc1978000
     hwsim_init_module+0x6a/0x1000 [mac802154_hwsim]
     ? 0xffffffffc1978000
     ? 0xffffffffc1978000
     ? 0xffffffffc1978000
     do_one_initcall+0xbc/0x47d init/main.c:887
     do_init_module+0x1b5/0x547 kernel/module.c:3456
     load_module+0x6405/0x8c10 kernel/module.c:3804
     __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
     do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x462e99
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fdcc02fec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
    RBP: 00007fdcc02fec70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdcc02ff6bc
    R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
    Modules linked in: mac802154_hwsim(+) mac802154 ieee802154 speakup(C) rc_proteus_2309 rtc_rk808 streebog_generic rds vboxguest madera_spi madera da9052_wdt mISDN_core ueagle_atm usbatm atm ir_imon_decoder scsi_transport_sas rc_dntv_live_dvb_t panel_samsung_s6d16d0 drm drm_panel_orientation_quirks lib80211 fb_agm1264k_fl(C) gspca_pac7302 gspca_main videobuf2_v4l2 soundwire_intel_init i2c_dln2 dln2 usbcore hid_gaff 88pm8607 nfnetlink axp20x_i2c axp20x uio pata_marvell pmbus_core snd_sonicvibes gameport snd_pcm snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore rtc_ds1511 rtc_ds1742 vsock dwc_xlgmac rtc_rx8010 libphy twofish_x86_64_3way twofish_x86_64 twofish_common ad5696_i2c ad5686 lp8788_charger cxd2880_spi dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops fbtft(C) sysimgblt sysfillrect syscopyarea fb_sys_fops janz_ican3 firewire_net firewire_core crc_itu_t spi_slave_system_control i2c_matroxfb i2c_algo_bit
     matroxfb_base fb fbdev matroxfb_DAC1064 matroxfb_accel cfbcopyarea cfbimgblt cfbfillrect matroxfb_Ti3026 matroxfb_g450 g450_pll matroxfb_misc leds_blinkm ti_dac7311 intel_spi_pci intel_spi spi_nor hid_elan hid async_tx rc_cinergy_1400 rc_core intel_ishtp kxcjk_1013 industrialio_triggered_buffer kfifo_buf can_dev intel_th spi_pxa2xx_platform pata_artop vme_ca91cx42 gb_gbphy(C) greybus(C) industrialio mptbase st_drv cmac ttpci_eeprom via_wdt gpio_xra1403 mtd iptable_security iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun joydev mousedev ppdev kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 input_leds crypto_simd cryptd glue_helper ide_pci_generic piix psmouse
     ide_core serio_raw ata_generic i2c_piix4 pata_acpi parport_pc parport floppy rtc_cmos intel_agp intel_gtt agpgart sch_fq_codel ip_tables x_tables sha1_ssse3 sha1_generic ipv6 [last unloaded: speakup]
    Dumping ftrace buffer:
       (ftrace buffer empty)
    CR2: fffffbfff834f001
    ---[ end trace 5aa772c793e0e971 ]---
    RIP: 0010:strcmp+0x31/0xa0 lib/string.c:328
    Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
    RSP: 0018:ffff8881e0c57800 EFLAGS: 00010246
    RAX: 1ffffffff834f001 RBX: ffffffffc1a78000 RCX: ffffffff827b9503
    RDX: 0000000000000000 RSI: ffffffffc1a40008 RDI: ffffffffc1a78008
    RBP: ffffffffc1a78009 R08: fffffbfff6a92195 R09: fffffbfff6a92195
    R10: ffff8881e0c578b8 R11: fffffbfff6a92194 R12: ffffffffc1a40008
    R13: dffffc0000000000 R14: ffffffffc1a3e470 R15: ffffffffc1a40000
    FS:  00007fdcc02ff700(0000) GS:ffff8881f7300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: fffffbfff834f001 CR3: 00000001b3134003 CR4: 00000000007606e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    
    The error handing path misplace the cleanup in hwsim_init_module,
    switch the two cleanup functions to fix above issues.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Alexander Aring <aring@mojatatu.com>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fc6065f5f2c36028f757cc1eb0995aabe2e15ca
Author: Masashi Honma <masashi.honma@gmail.com>
Date:   Sun Sep 8 09:56:53 2019 +0900

    nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
    
    commit 4b2c5a14cd8005a900075f7dfec87473c6ee66fb upstream.
    
    commit 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM
    RSSI thresholds") was incomplete and requires one more fix to
    prevent accessing to rssi_thresholds[n] because user can control
    rssi_thresholds[i] values to make i reach to n. For example,
    rssi_thresholds = {-400, -300, -200, -100} when last is -34.
    
    Cc: stable@vger.kernel.org
    Fixes: 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
    Link: https://lore.kernel.org/r/20190908005653.17433-1-masashi.honma@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb91d697f8514c2dd8b1800633436e12fb0452c9
Author: Wen Huang <huangwenabc@gmail.com>
Date:   Wed Aug 28 10:07:51 2019 +0800

    mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings
    
    commit 7caac62ed598a196d6ddf8d9c121e12e082cac3a upstream.
    
    mwifiex_update_vs_ie(),mwifiex_set_uap_rates() and
    mwifiex_set_wmm_params() call memcpy() without checking
    the destination size.Since the source is given from
    user-space, this may trigger a heap buffer overflow.
    
    Fix them by putting the length check before performing memcpy().
    
    This fix addresses CVE-2019-14814,CVE-2019-14815,CVE-2019-14816.
    
    Signed-off-by: Wen Huang <huangwenabc@gmail.com>
    Acked-by: Ganapathi Bhat <gbhat@marvell.comg>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 314a961abd99e0c9f9f4d31bde56f4af8705ab94
Author: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Date:   Tue Aug 13 10:40:25 2019 +0300

    tty/serial: atmel: reschedule TX after RX was started
    
    commit d2ace81bf902a9f11d52e59e5d232d2255a0e353 upstream.
    
    When half-duplex RS485 communication is used, after RX is started, TX
    tasklet still needs to be  scheduled tasklet. This avoids console freezing
    when more data is to be transmitted, if the serial communication is not
    closed.
    
    Fixes: 69646d7a3689 ("tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped")
    Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190813074025.16218-1-razvan.stefanescu@microchip.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bf0e241c8136fde93f72d33b8485d43adf1234a
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Thu Sep 5 15:41:51 2019 +0800

    serial: sprd: correct the wrong sequence of arguments
    
    commit 9c801e313195addaf11c16e155f50789d6ebfd19 upstream.
    
    The sequence of arguments which was passed to handle_lsr_errors() didn't
    match the parameters defined in that function, &lsr was passed to flag
    and &flag was passed to lsr, this patch fixed that.
    
    Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support")
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Signed-off-by: Chunyan Zhang <zhang.lyra@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190905074151.5268-1-zhang.lyra@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3049e5125169f4a59a7296fc75b639789a8f5c94
Author: Hung-Te Lin <hungte@chromium.org>
Date:   Fri Aug 30 10:23:58 2019 +0800

    firmware: google: check if size is valid when decoding VPD data
    
    commit 4b708b7b1a2c09fbdfff6b942ebe3a160213aacd upstream.
    
    The VPD implementation from Chromium Vital Product Data project used to
    parse data from untrusted input without checking if the meta data is
    invalid or corrupted. For example, the size from decoded content may
    be negative value, or larger than whole input buffer. Such invalid data
    may cause buffer overflow.
    
    To fix that, the size parameters passed to vpd_decode functions should
    be changed to unsigned integer (u32) type, and the parsing of entry
    header should be refactored so every size field is correctly verified
    before starting to decode.
    
    Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files")
    Signed-off-by: Hung-Te Lin <hungte@chromium.org>
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20190830022402.214442-1-hungte@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad0ef1b06e7bd834060f62a4c24f5b88f714b01b
Author: Matt Delco <delco@chromium.org>
Date:   Mon Sep 16 14:16:54 2019 -0700

    KVM: coalesced_mmio: add bounds checking
    
    commit b60fe990c6b07ef6d4df67bc0530c7c90a62623a upstream.
    
    The first/last indexes are typically shared with a user app.
    The app can change the 'last' index that the kernel uses
    to store the next result.  This change sanity checks the index
    before using it for writing to a potentially arbitrary address.
    
    This fixes CVE-2019-14821.
    
    Cc: stable@vger.kernel.org
    Fixes: 5f94c1741bdc ("KVM: Add coalesced MMIO support (common part)")
    Signed-off-by: Matt Delco <delco@chromium.org>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com
    [Use READ_ONCE. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d84424bdfcd15e9ce01cfcd28e5c9e2a599f8db
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Thu Sep 12 15:16:45 2019 +0200

    net: dsa: Fix load order between DSA drivers and taggers
    
    [ Upstream commit 23426a25e55a417dc104df08781b6eff95e65f3f ]
    
    The DSA core, DSA taggers and DSA drivers all make use of
    module_init(). Hence they get initialised at device_initcall() time.
    The ordering is non-deterministic. It can be a DSA driver is bound to
    a device before the needed tag driver has been initialised, resulting
    in the message:
    
    No tagger for this switch
    
    Rather than have this be fatal, return -EPROBE_DEFER so that it is
    tried again later once all the needed drivers have been loaded.
    
    Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules")
    Signed-off-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 7f4aa339581bf60abd8909e9cfbb04205c596615
Author: Dongli Zhang <dongli.zhang@oracle.com>
Date:   Mon Sep 16 11:46:59 2019 +0800

    xen-netfront: do not assume sk_buff_head list is empty in error handling
    
    [ Upstream commit 00b368502d18f790ab715e055869fd4bb7484a9b ]
    
    When skb_shinfo(skb) is not able to cache extra fragment (that is,
    skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
    the sk_buff_head list is already empty. As a result, cons is increased only
    by 1 and returns to error handling path in xennet_poll().
    
    However, if the sk_buff_head list is not empty, queue->rx.rsp_cons may be
    set incorrectly. That is, queue->rx.rsp_cons would point to the rx ring
    buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are
    already cleared to NULL. This leads to NULL pointer access in the next
    iteration to process rx ring buffer entries.
    
    Below is how xennet_poll() does error handling. All remaining entries in
    tmpq are accounted to queue->rx.rsp_cons without assuming how many
    outstanding skbs are remained in the list.
    
     985 static int xennet_poll(struct napi_struct *napi, int budget)
    ... ...
    1032           if (unlikely(xennet_set_skb_gso(skb, gso))) {
    1033                   __skb_queue_head(&tmpq, skb);
    1034                   queue->rx.rsp_cons += skb_queue_len(&tmpq);
    1035                   goto err;
    1036           }
    
    It is better to always have the error handling in the same way.
    
    Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
    Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82369aa61ec7f3a006f8e687dd0b80c5782f8a83
Author: Willem de Bruijn <willemb@google.com>
Date:   Thu Sep 12 21:16:39 2019 -0400

    udp: correct reuseport selection with connected sockets
    
    [ Upstream commit acdcecc61285faed359f1a3568c32089cc3a8329 ]
    
    UDP reuseport groups can hold a mix unconnected and connected sockets.
    Ensure that connections only receive all traffic to their 4-tuple.
    
    Fast reuseport returns on the first reuseport match on the assumption
    that all matches are equal. Only if connections are present, return to
    the previous behavior of scoring all sockets.
    
    Record if connections are present and if so (1) treat such connected
    sockets as an independent match from the group, (2) only return
    2-tuple matches from reuseport and (3) do not return on the first
    2-tuple reuseport match to allow for a higher scoring match later.
    
    New field has_conns is set without locks. No other fields in the
    bitmap are modified at runtime and the field is only ever set
    unconditionally, so an RMW cannot miss a change.
    
    Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection")
    Link: http://lkml.kernel.org/r/CA+FuTSfRP09aJNYRt04SS6qj22ViiOEWaWmLAwX0psk8-PGNxw@mail.gmail.com
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Craig Gallek <kraig@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4cb1c43dc6c69e04f77615d4c7e4e968a64c5d7
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Thu Sep 12 10:22:30 2019 -0700

    net_sched: let qdisc_put() accept NULL pointer
    
    [ Upstream commit 6efb971ba8edfbd80b666f29de12882852f095ae ]
    
    When tcf_block_get() fails in sfb_init(), q->qdisc is still a NULL
    pointer which leads to a crash in sfb_destroy(). Similar for
    sch_dsmark.
    
    Instead of fixing each separately, Linus suggested to just accept
    NULL pointer in qdisc_put(), which would make callers easier.
    
    (For sch_dsmark, the bug probably exists long before commit
    6529eaba33f0.)
    
    Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
    Reported-by: syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81608038502a1afb03a3916689cce51340bd3169
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Sep 12 12:02:42 2019 +0200

    net/sched: fix race between deactivation and dequeue for NOLOCK qdisc
    
    [ Upstream commit d518d2ed8640c1cbbbb6f63939e3e65471817367 ]
    
    The test implemented by some_qdisc_is_busy() is somewhat loosy for
    NOLOCK qdisc, as we may hit the following scenario:
    
    CPU1                                            CPU2
    // in net_tx_action()
    clear_bit(__QDISC_STATE_SCHED...);
                                                    // in some_qdisc_is_busy()
                                                    val = (qdisc_is_running(q) ||
                                                           test_bit(__QDISC_STATE_SCHED,
                                                                    &q->state));
                                                    // here val is 0 but...
    qdisc_run(q)
    // ... CPU1 is going to run the qdisc next
    
    As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
    in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
    both the above bit operations are under the root qdisc lock().
    
    After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
    the race can cause use after free and/or null ptr dereference, but the root
    cause is likely older.
    
    This patch addresses the issue explicitly checking for deactivation under
    the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
    scenario becomes a no-op.
    
    Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
    but that is safe due to the skb_array() locking, and we can't avoid that
    for NOLOCK qdiscs.
    
    Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
    Reported-by: Li Shuang <shuali@redhat.com>
    Reported-and-tested-by: Davide Caratti <dcaratti@redhat.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a00845c5d64870bc2ce948578dbf98dc18b52e7
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Sep 13 17:45:47 2019 +0800

    ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit
    
    [ Upstream commit 28e486037747c2180470b77c290d4090ad42f259 ]
    
    In ip6erspan_tunnel_xmit(), if the skb will not be sent out, it has to
    be freed on the tx_err path. Otherwise when deleting a netns, it would
    cause dst/dev to leak, and dmesg shows:
    
      unregister_netdevice: waiting for lo to become free. Usage count = 1
    
    Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: William Tu <u9012063@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d3dc8dfe890f98107aa727526246cb0365f316d
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Fri Aug 30 12:08:33 2019 +0000

    net: aquantia: fix limit of vlan filters
    
    commit 392349f60110dc2c3daf86464fd926afc53d6143 upstream.
    
    Fix a limit condition of vlans on the interface before setting vlan
    promiscuous mode
    
    Fixes: 48dd73d08d4dd ("net: aquantia: fix vlans not working over bridged network")
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd950d777e3a22469917977eea5e6f421c916dc4
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Mon Jul 22 13:59:12 2019 +0800

    net: hns: fix LED configuration for marvell phy
    
    commit f4e5f775db5a4631300dccd0de5eafb50a77c131 upstream.
    
    Since commit(net: phy: marvell: change default m88e1510 LED configuration),
    the active LED of Hip07 devices is always off, because Hip07 just
    use 2 LEDs.
    This patch adds a phy_register_fixup_for_uid() for m88e1510 to
    correct the LED configuration.
    
    Fixes: 077772468ec1 ("net: phy: marvell: change default m88e1510 LED configuration")
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Reviewed-by: linyunsheng <linyunsheng@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 854c67e19e73e36e2acf59c17f549ec9bbf2d03c
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Thu Jul 11 20:52:27 2019 -0700

    scripts/decode_stacktrace: match basepath using shell prefix operator, not regex
    
    commit 31013836a71e07751a6827f9d2ad41ef502ddaff upstream.
    
    The basepath may contain special characters, which would confuse the regex
    matcher.  ${var#prefix} does the right thing.
    
    Link: http://lkml.kernel.org/r/20190518055946.181563-1-drinkcat@chromium.org
    Fixes: 67a28de47faa8358 ("scripts/decode_stacktrace: only strip base path when a prefix of the path")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.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 88f16147459fe1c42e543cf697cdcb7ddf061ffa
Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Date:   Mon Jul 1 20:04:42 2019 +0530

    powerpc/mm/radix: Use the right page size for vmemmap mapping
    
    commit 89a3496e0664577043666791ec07fb731d57c950 upstream.
    
    We use mmu_vmemmap_psize to find the page size for mapping the vmmemap area.
    With radix translation, we are suboptimally setting this value to PAGE_SIZE.
    
    We do check for 2M page size support and update mmu_vmemap_psize to use
    hugepage size but we suboptimally reset the value to PAGE_SIZE in
    radix__early_init_mmu(). This resulted in always mapping vmemmap area with
    64K page size.
    
    Fixes: 2bfd65e45e87 ("powerpc/mm/radix: Add radix callbacks for early init routines")
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit badbf863ed911900c2db0de1634b850c3073d164
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Fri May 31 14:06:05 2019 -0700

    nfs: disable client side deduplication
    
    commit 9026b3a973b0b0b73c15ba40aff87cd0959fd0f3 upstream.
    
    The NFS protocol doesn't support deduplication, so turn it off again.
    
    Fixes: ce96e888fe48e ("Fix nfs4.2 return -EINVAL when do dedupe operation")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 543792290cce90676a1b272694715a250288b55d
Author: Fabien Dessenne <fabien.dessenne@st.com>
Date:   Fri May 31 05:18:15 2019 -0400

    media: stm32-dcmi: fix irq = 0 case
    
    commit dbb9fcc8c2d8d4ea1104f51d4947a8a8199a2cb5 upstream.
    
    Manage the irq = 0 case, where we shall return an error.
    
    Fixes: b5b5a27bee58 ("media: stm32-dcmi: return appropriate error codes during probe")
    
    Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
    Reported-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fb6db57b831bdbfcf9adde3617d56fad2511381
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Aug 16 08:58:48 2019 -0400

    SUNRPC: Handle connection breakages correctly in call_status()
    
    commit c82e5472c9980e0e483f4b689044150eefaca408 upstream.
    
    If the connection breaks while we're waiting for a reply from the
    server, then we want to immediately try to reconnect.
    
    Fixes: ec6017d90359 ("SUNRPC fix regression in umount of a secure mount")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d96613b372d0357c9eaef41b17a4971a31365b3
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Sep 6 12:02:32 2019 -0700

    Input: elan_i2c - remove Lenovo Legion Y7000 PnpID
    
    commit 0c043d70d04711fe6c380df9065fdc44192c49bf upstream.
    
    Looks like the Bios of the Lenovo Legion Y7000 is using ELAN061B
    when the actual device is supposed to be used with hid-multitouch.
    
    Remove it from the list of the supported device, hoping that
    no one will complain about the loss in functionality.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=203467
    Fixes: 738c06d0e456 ("Input: elan_i2c - add hardware ID for multiple Lenovo laptops")
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41a22481ec5d450069fa688d253a540c63b2a0b3
Author: Aaron Armstrong Skomra <skomra@gmail.com>
Date:   Wed Jun 12 14:19:29 2019 -0700

    HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report
    
    commit 184eccd40389df29abefab88092c4ff33191fd0c upstream.
    
    In the generic code path, HID_DG_CONTACTMAX was previously
    only read from the second byte of report 0x23.
    
    Another report (0x82) has the HID_DG_CONTACTMAX in the
    higher nibble of the third byte. We should support reading the
    value of HID_DG_CONTACTMAX no matter what report we are reading
    or which position that value is in.
    
    To do this we submit the feature report as a event report
    using hid_report_raw_event(). Our modified finger event path
    records the value of HID_DG_CONTACTMAX when it sees that usage.
    
    Fixes: 8ffffd5212846 ("HID: wacom: fix timeout on probe for some wacoms")
    Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7902ff2b8c97277e242229af2c5bd794283c15ec
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Sep 2 19:37:43 2019 +0200

    netfilter: nf_flow_table: set default timeout after successful insertion
    
    commit 110e48725db6262f260f10727d0fb2d3d25895e4 upstream.
    
    Set up the default timeout for this new entry otherwise the garbage
    collector might quickly remove it right after the flowtable insertion.
    
    Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9bc4f96c596aea475933ac8ac12bc2c443ba346
Author: Huazhong Tan <tanhuazhong@huawei.com>
Date:   Tue May 28 17:03:01 2019 +0800

    net: hns3: adjust hns3_uninit_phy()'s location in the hns3_client_uninit()
    
    commit 0d2f68c7bcf4c7bbdd6f810f7b6e658f43d4461e upstream.
    
    hns3_uninit_phy() should be called before checking
    HNS3_NIC_STATE_INITED flags, otherwise when this checking fails,
    there is nobody to call hns3_uninit_phy().
    
    Fixes: c8a8045b2d0a ("net: hns3: Fix NULL deref when unloading driver")
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: Peng Li <lipeng321@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32e50e282ea7f5dd008a4149be3fd7f42ccb9e07
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Aug 6 17:51:19 2019 +0900

    phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current
    
    commit e6839c31a608e79f2057fab987dd814f5d3477e6 upstream.
    
    The hardware manual should be revised, but the initial value of
    VBCTRL.OCCLREN is set to 1 actually. If the bit is set, the hardware
    clears VBCTRL.VBOUT and ADPCTRL.DRVVBUS registers automatically
    when the hardware detects over-current signal from a USB power switch.
    However, since the hardware doesn't have any registers which
    indicates over-current, the driver cannot handle it at all. So, if
    "is_otg_channel" hardware detects over-current, since ADPCTRL.DRVVBUS
    register is cleared automatically, the channel cannot be used after
    that.
    
    To resolve this behavior, this patch sets the VBCTRL.OCCLREN to 0
    to keep ADPCTRL.DRVVBUS even if the "is_otg_channel" hardware
    detects over-current. (We assume a USB power switch itself protects
    over-current and turns the VBUS off.)
    
    This patch is inspired by a BSP patch from Kazuya Mizuguchi.
    
    Fixes: 1114e2d31731 ("phy: rcar-gen3-usb2: change the mode to OTG on the combined channel")
    Cc: <stable@vger.kernel.org> # v4.5+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 262c7b193cbbde8ed6315d94ebb2b9ae1f4b2a8e
Author: Sean Young <sean@mess.org>
Date:   Tue Aug 13 13:45:09 2019 -0300

    media: tm6000: double free if usb disconnect while streaming
    
    commit 699bf94114151aae4dceb2d9dbf1a6312839dcae upstream.
    
    The usb_bulk_urb will kfree'd on disconnect, so ensure the pointer is set
    to NULL after each free.
    
    stop stream
    urb killing
    urb buffer free
    tm6000: got start feed request tm6000_start_feed
    tm6000: got start stream request tm6000_start_stream
    tm6000: pipe reset
    tm6000: got start feed request tm6000_start_feed
    tm6000: got start feed request tm6000_start_feed
    tm6000: got start feed request tm6000_start_feed
    tm6000: got start feed request tm6000_start_feed
    tm6000: IR URB failure: status: -71, length 0
    xhci_hcd 0000:00:14.0: ERROR unknown event type 37
    xhci_hcd 0000:00:14.0: ERROR unknown event type 37
    tm6000:  error tm6000_urb_received
    usb 1-2: USB disconnect, device number 5
    tm6000: disconnecting tm6000 #0
    ==================================================================
    BUG: KASAN: use-after-free in dvb_fini+0x75/0x140 [tm6000_dvb]
    Read of size 8 at addr ffff888241044060 by task kworker/2:0/22
    
    CPU: 2 PID: 22 Comm: kworker/2:0 Tainted: G        W         5.3.0-rc4+ #1
    Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET65W (1.40 ) 07/02/2019
    Workqueue: usb_hub_wq hub_event
    Call Trace:
     dump_stack+0x9a/0xf0
     print_address_description.cold+0xae/0x34f
     __kasan_report.cold+0x75/0x93
     ? tm6000_fillbuf+0x390/0x3c0 [tm6000_alsa]
     ? dvb_fini+0x75/0x140 [tm6000_dvb]
     kasan_report+0xe/0x12
     dvb_fini+0x75/0x140 [tm6000_dvb]
     tm6000_close_extension+0x51/0x80 [tm6000]
     tm6000_usb_disconnect.cold+0xd4/0x105 [tm6000]
     usb_unbind_interface+0xe4/0x390
     device_release_driver_internal+0x121/0x250
     bus_remove_device+0x197/0x260
     device_del+0x268/0x550
     ? __device_links_no_driver+0xd0/0xd0
     ? usb_remove_ep_devs+0x30/0x3b
     usb_disable_device+0x122/0x400
     usb_disconnect+0x153/0x430
     hub_event+0x800/0x1e40
     ? trace_hardirqs_on_thunk+0x1a/0x20
     ? hub_port_debounce+0x1f0/0x1f0
     ? retint_kernel+0x10/0x10
     ? lock_is_held_type+0xf1/0x130
     ? hub_port_debounce+0x1f0/0x1f0
     ? process_one_work+0x4ae/0xa00
     process_one_work+0x4ba/0xa00
     ? pwq_dec_nr_in_flight+0x160/0x160
     ? do_raw_spin_lock+0x10a/0x1d0
     worker_thread+0x7a/0x5c0
     ? process_one_work+0xa00/0xa00
     kthread+0x1d5/0x200
     ? kthread_create_worker_on_cpu+0xd0/0xd0
     ret_from_fork+0x3a/0x50
    
    Allocated by task 2682:
     save_stack+0x1b/0x80
     __kasan_kmalloc.constprop.0+0xc2/0xd0
     usb_alloc_urb+0x28/0x60
     tm6000_start_feed+0x10a/0x300 [tm6000_dvb]
     dmx_ts_feed_start_filtering+0x86/0x120 [dvb_core]
     dvb_dmxdev_start_feed+0x121/0x180 [dvb_core]
     dvb_dmxdev_filter_start+0xcb/0x540 [dvb_core]
     dvb_demux_do_ioctl+0x7ed/0x890 [dvb_core]
     dvb_usercopy+0x97/0x1f0 [dvb_core]
     dvb_demux_ioctl+0x11/0x20 [dvb_core]
     do_vfs_ioctl+0x5d8/0x9d0
     ksys_ioctl+0x5e/0x90
     __x64_sys_ioctl+0x3d/0x50
     do_syscall_64+0x74/0xe0
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Freed by task 22:
     save_stack+0x1b/0x80
     __kasan_slab_free+0x12c/0x170
     kfree+0xfd/0x3a0
     xhci_giveback_urb_in_irq+0xfe/0x230
     xhci_td_cleanup+0x276/0x340
     xhci_irq+0x1129/0x3720
     __handle_irq_event_percpu+0x6e/0x420
     handle_irq_event_percpu+0x6f/0x100
     handle_irq_event+0x55/0x84
     handle_edge_irq+0x108/0x3b0
     handle_irq+0x2e/0x40
     do_IRQ+0x83/0x1a0
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fc15d29540a69cfb55c8b8f8c38f1af33178243
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Sep 4 11:56:27 2019 -0400

    USB: usbcore: Fix slab-out-of-bounds bug during device reset
    
    commit 3dd550a2d36596a1b0ee7955da3b611c031d3873 upstream.
    
    The syzbot fuzzer provoked a slab-out-of-bounds error in the USB core:
    
    BUG: KASAN: slab-out-of-bounds in memcmp+0xa6/0xb0 lib/string.c:904
    Read of size 1 at addr ffff8881d175bed6 by task kworker/0:3/2746
    
    CPU: 0 PID: 2746 Comm: kworker/0:3 Not tainted 5.3.0-rc5+ #28
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Workqueue: usb_hub_wq hub_event
    Call Trace:
      __dump_stack lib/dump_stack.c:77 [inline]
      dump_stack+0xca/0x13e lib/dump_stack.c:113
      print_address_description+0x6a/0x32c mm/kasan/report.c:351
      __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
      kasan_report+0xe/0x12 mm/kasan/common.c:612
      memcmp+0xa6/0xb0 lib/string.c:904
      memcmp include/linux/string.h:400 [inline]
      descriptors_changed drivers/usb/core/hub.c:5579 [inline]
      usb_reset_and_verify_device+0x564/0x1300 drivers/usb/core/hub.c:5729
      usb_reset_device+0x4c1/0x920 drivers/usb/core/hub.c:5898
      rt2x00usb_probe+0x53/0x7af
    drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:806
    
    The error occurs when the descriptors_changed() routine (called during
    a device reset) attempts to compare the old and new BOS and capability
    descriptors.  The length it uses for the comparison is the
    wTotalLength value stored in BOS descriptor, but this value is not
    necessarily the same as the length actually allocated for the
    descriptors.  If it is larger the routine will call memcmp() with a
    length that is too big, thus reading beyond the end of the allocated
    region and leading to this fault.
    
    The kernel reads the BOS descriptor twice: first to get the total
    length of all the capability descriptors, and second to read it along
    with all those other descriptors.  A malicious (or very faulty) device
    may send different values for the BOS descriptor fields each time.
    The memory area will be allocated using the wTotalLength value read
    the first time, but stored within it will be the value read the second
    time.
    
    To prevent this possibility from causing any errors, this patch
    modifies the BOS descriptor after it has been read the second time:
    It sets the wTotalLength field to the actual length of the descriptors
    that were read in and validated.  Then the memcpy() call, or any other
    code using these descriptors, will be able to rely on wTotalLength
    being valid.
    
    Reported-and-tested-by: syzbot+35f4d916c623118d576e@syzkaller.appspotmail.com
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1909041154260.1722-100000@iolanthe.rowland.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>