commit bb7b450e61a1dbe2bfbe998a1afeda654c6a67e9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jun 9 09:17:25 2019 +0200

    Linux 4.19.49

commit 9861e2cd461665dba770238f81ab2e901bed531f
Author: Nadav Amit <namit@vmware.com>
Date:   Mon Jun 4 09:47:13 2018 -0400

    media: uvcvideo: Fix uvc_alloc_entity() allocation alignment
    
    commit 89dd34caf73e28018c58cd193751e41b1f8bdc56 upstream.
    
    The use of ALIGN() in uvc_alloc_entity() is incorrect, since the size of
    (entity->pads) is not a power of two. As a stop-gap, until a better
    solution is adapted, use roundup() instead.
    
    Found by a static assertion. Compile-tested only.
    
    Fixes: 4ffc2d89f38a ("uvcvideo: Register subdevices for each entity")
    
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Cc: Doug Anderson <dianders@chromium.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b52ca352489be8beb7de3a8181509a0deaf72e21
Author: Frank Rowand <frank.rowand@sony.com>
Date:   Fri Oct 12 19:21:16 2018 -0700

    of: overlay: set node fields from properties when add new overlay node
    
    commit f96278810150fc39085d1872e5b39ea06366d03e upstream.
    
    Overlay nodes added by add_changeset_node() do not have the node
    fields name, phandle, and type set.
    
    The node passed to __of_attach_node() when the add node changeset
    entry is processed does not contain any properties.  The node's
    properties are located in add property changeset entries that will
    be processed after the add node changeset is applied.
    
    Set the node's fields in the node contained in the add node
    changeset entry and do not set them to incorrect values in
    add_changeset_node().
    
    A visible symptom that is fixed by this patch is the names of nodes
    added by overlays that have an entry in /sys/bus/platform/drivers/*/
    will contain the unit-address but the node-name will be <NULL>,  for
    example, "fc4ab000.<NULL>".  After applying the patch the name, in
    this example, for node restart@fc4ab000 is "fc4ab000.restart".
    
    Tested-by: Alan Tull <atull@kernel.org>
    Signed-off-by: Frank Rowand <frank.rowand@sony.com>
    Cc: Phil Elwell <phil@raspberrypi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15151d0013c9280921476bbeb7b43cfcc96008d6
Author: Frank Rowand <frank.rowand@sony.com>
Date:   Thu Oct 4 20:32:04 2018 -0700

    of: overlay: validate overlay properties #address-cells and #size-cells
    
    commit 6f75118800acf77f8ad6afec61ca1b2349ade371 upstream.
    
    If overlay properties #address-cells or #size-cells are already in
    the live devicetree for any given node, then the values in the
    overlay must match the values in the live tree.
    
    If the properties are already in the live tree then there is no
    need to create a changeset entry to add them since they must
    have the same value.  This reduces the memory used by the
    changeset and eliminates a possible memory leak.
    
    Tested-by: Alan Tull <atull@kernel.org>
    Signed-off-by: Frank Rowand <frank.rowand@sony.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26dace362e7fb77a51039e91d9e15ab90b0eaac0
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Jun 6 10:41:25 2019 -0700

    scsi: lpfc: Fix backport of faf5a744f4f8 ("scsi: lpfc: avoid uninitialized variable warning")
    
    Prior to commit 4c47efc140fa ("scsi: lpfc: Move SCSI and NVME Stats to
    hardware queue structures") upstream, we allocated a cstat structure in
    lpfc_nvme_create_localport. When commit faf5a744f4f8 ("scsi: lpfc: avoid
    uninitialized variable warning") was backported, it was placed after the
    allocation so we leaked memory whenever this function was called and
    that conditional was true (so whenever CONFIG_NVME_FC is disabled).
    
    Move the IS_ENABLED if statement above the allocation since it is not
    needed when the condition is true.
    
    Reported-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca309fef7a69b8e71e6c84b84b6b97fa2db19e9f
Author: Nadav Amit <namit@vmware.com>
Date:   Thu Apr 25 17:11:30 2019 -0700

    x86/kprobes: Set instruction page as executable
    
    [ Upstream commit 7298e24f904224fa79eb8fd7e0fbd78950ccf2db ]
    
    Set the page as executable after allocation.  This patch is a
    preparatory patch for a following patch that makes module allocated
    pages non-executable.
    
    While at it, do some small cleanup of what appears to be unnecessary
    masking.
    
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <akpm@linux-foundation.org>
    Cc: <ard.biesheuvel@linaro.org>
    Cc: <deneen.t.dock@intel.com>
    Cc: <kernel-hardening@lists.openwall.com>
    Cc: <kristen@linux.intel.com>
    Cc: <linux_dti@icloud.com>
    Cc: <will.deacon@arm.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/20190426001143.4983-11-namit@vmware.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b49ca4bf1b9c7e7c4e6ca046d1c76109e8a9d0e7
Author: Nadav Amit <namit@vmware.com>
Date:   Thu Apr 25 17:11:29 2019 -0700

    x86/ftrace: Set trampoline pages as executable
    
    [ Upstream commit 3c0dab44e22782359a0a706cbce72de99a22aa75 ]
    
    Since alloc_module() will not set the pages as executable soon, set
    ftrace trampoline pages as executable after they are allocated.
    
    For the time being, do not change ftrace to use the text_poke()
    interface. As a result, ftrace still breaks W^X.
    
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: <akpm@linux-foundation.org>
    Cc: <ard.biesheuvel@linaro.org>
    Cc: <deneen.t.dock@intel.com>
    Cc: <kernel-hardening@lists.openwall.com>
    Cc: <kristen@linux.intel.com>
    Cc: <linux_dti@icloud.com>
    Cc: <will.deacon@arm.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/20190426001143.4983-10-namit@vmware.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fa953c94882ebe73dcb545b4906ee849821e357
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Sat Dec 8 12:58:51 2018 -0500

    x86/ftrace: Do not call function graph from dynamic trampolines
    
    [ Upstream commit d2a68c4effd821f0871d20368f76b609349c8a3b ]
    
    Since commit 79922b8009c07 ("ftrace: Optimize function graph to be
    called directly"), dynamic trampolines should not be calling the
    function graph tracer at the end. If they do, it could cause the function
    graph tracer to trace functions that it filtered out.
    
    Right now it does not cause a problem because there's a test to check if
    the function graph tracer is attached to the same function as the
    function tracer, which for now is true. But the function graph tracer is
    undergoing changes that can make this no longer true which will cause
    the function graph tracer to trace other functions.
    
     For example:
    
     # cd /sys/kernel/tracing/
     # echo do_IRQ > set_ftrace_filter
     # mkdir instances/foo
     # echo ip_rcv > instances/foo/set_ftrace_filter
     # echo function_graph > current_tracer
     # echo function > instances/foo/current_tracer
    
    Would cause the function graph tracer to trace both do_IRQ and ip_rcv,
    if the current tests change.
    
    As the current tests prevent this from being a problem, this code does
    not need to be backported. But it does make the code cleaner.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d57cfd4e9d81400c1fe2b7cd4503f54830b46c2
Author: Todd Kjos <tkjos@android.com>
Date:   Wed Jun 5 09:38:25 2019 -0700

    binder: fix race between munmap() and direct reclaim
    
    commit 5cec2d2e5839f9c0fec319c523a911e0a7fd299f upstream.
    
    An munmap() on a binder device causes binder_vma_close() to be called
    which clears the alloc->vma pointer.
    
    If direct reclaim causes binder_alloc_free_page() to be called, there
    is a race where alloc->vma is read into a local vma pointer and then
    used later after the mm->mmap_sem is acquired. This can result in
    calling zap_page_range() with an invalid vma which manifests as a
    use-after-free in zap_page_range().
    
    The fix is to check alloc->vma after acquiring the mmap_sem (which we
    were acquiring anyway) and skip zap_page_range() if it has changed
    to NULL.
    
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Cc: stable <stable@vger.kernel.org> # 4.19
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 137c838f177b86797a9a805bb131e0f96cdac565
Author: Todd Kjos <tkjos@android.com>
Date:   Wed Jun 5 09:38:24 2019 -0700

    Revert "binder: fix handling of misaligned binder object"
    
    This reverts commit 6bf7d3c5c0c5dad650bfc4345ed553c18b69d59e.
    
    The commit message is for a different patch. Reverting and then adding
    the same patch back with the correct commit message.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: stable <stable@vger.kernel.org> # 4.19
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 385dab299c8a3dd75dd6a2ded368b00f5867a193
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 5 20:40:30 2019 +0200

    Revert "x86/build: Move _etext to actual end of .text"
    
    This reverts commit 392bef709659abea614abfe53cf228e7a59876a4.
    
    It seems to cause lots of problems when using the gold linker, and no
    one really needs this at the moment, so just revert it from the stable
    trees.
    
    Cc: Sami Tolvanen <samitolvanen@google.com>
    Reported-by: Kees Cook <keescook@chromium.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Reported-by: Alec Ari <neotheuser@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9468870f7cbdb4d7ca828d02d4ff507c01fe591d
Author: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Sat Jan 19 20:59:34 2019 +0100

    include/linux/module.h: copy __init/__exit attrs to init/cleanup_module
    
    commit a6e60d84989fa0e91db7f236eda40453b0e44afa upstream.
    
    The upcoming GCC 9 release extends the -Wmissing-attributes warnings
    (enabled by -Wall) to C and aliases: it warns when particular function
    attributes are missing in the aliases but not in their target.
    
    In particular, it triggers for all the init/cleanup_module
    aliases in the kernel (defined by the module_init/exit macros),
    ending up being very noisy.
    
    These aliases point to the __init/__exit functions of a module,
    which are defined as __cold (among other attributes). However,
    the aliases themselves do not have the __cold attribute.
    
    Since the compiler behaves differently when compiling a __cold
    function as well as when compiling paths leading to calls
    to __cold functions, the warning is trying to point out
    the possibly-forgotten attribute in the alias.
    
    In order to keep the warning enabled, we decided to silence
    this case. Ideally, we would mark the aliases directly
    as __init/__exit. However, there are currently around 132 modules
    in the kernel which are missing __init/__exit in their init/cleanup
    functions (either because they are missing, or for other reasons,
    e.g. the functions being called from somewhere else); and
    a section mismatch is a hard error.
    
    A conservative alternative was to mark the aliases as __cold only.
    However, since we would like to eventually enforce __init/__exit
    to be always marked,  we chose to use the new __copy function
    attribute (introduced by GCC 9 as well to deal with this).
    With it, we copy the attributes used by the target functions
    into the aliases. This way, functions that were not marked
    as __init/__exit won't have their aliases marked either,
    and therefore there won't be a section mismatch.
    
    Note that the warning would go away marking either the extern
    declaration, the definition, or both. However, we only mark
    the definition of the alias, since we do not want callers
    (which only see the declaration) to be compiled as if the function
    was __cold (and therefore the paths leading to those calls
    would be assumed to be unlikely).
    
    Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/
    Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/
    Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
    Acked-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a0f719db71c69f5a04fcfc164f12f58f3ee7703
Author: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Fri Feb 8 23:51:05 2019 +0100

    Compiler Attributes: add support for __copy (gcc >= 9)
    
    commit c0d9782f5b6d7157635ae2fd782a4b27d55a6013 upstream.
    
    From the GCC manual:
    
      copy
      copy(function)
    
        The copy attribute applies the set of attributes with which function
        has been declared to the declaration of the function to which
        the attribute is applied. The attribute is designed for libraries
        that define aliases or function resolvers that are expected
        to specify the same set of attributes as their targets. The copy
        attribute can be used with functions, variables, or types. However,
        the kind of symbol to which the attribute is applied (either
        function or variable) must match the kind of symbol to which
        the argument refers. The copy attribute copies only syntactic and
        semantic attributes but not attributes that affect a symbol’s
        linkage or visibility such as alias, visibility, or weak.
        The deprecated attribute is also not copied.
    
      https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
    
    The upcoming GCC 9 release extends the -Wmissing-attributes warnings
    (enabled by -Wall) to C and aliases: it warns when particular function
    attributes are missing in the aliases but not in their target, e.g.:
    
        void __cold f(void) {}
        void __alias("f") g(void);
    
    diagnoses:
    
        warning: 'g' specifies less restrictive attribute than
        its target 'f': 'cold' [-Wmissing-attributes]
    
    Using __copy(f) we can copy the __cold attribute from f to g:
    
        void __cold f(void) {}
        void __copy(f) __alias("f") g(void);
    
    This attribute is most useful to deal with situations where an alias
    is declared but we don't know the exact attributes the target has.
    
    For instance, in the kernel, the widely used module_init/exit macros
    define the init/cleanup_module aliases, but those cannot be marked
    always as __init/__exit since some modules do not have their
    functions marked as such.
    
    Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 390a0fd31b02f2f7086af2f3bdb8ae576b9a4b84
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Feb 28 15:49:08 2019 +0100

    drm/lease: Make sure implicit planes are leased
    
    commit 204f640da6914844b3270b41b29c84f6e3b74083 upstream.
    
    If userspace doesn't enable universal planes, then we automatically
    add the primary and cursor planes. But for universal userspace there's
    no such check (and maybe we only want to give the lessee one plane,
    maybe not even the primary one), hence we need to check for the
    implied plane.
    
    v2: don't forget setcrtc ioctl.
    
    v3: Still allow disabling of the crtc in SETCRTC.
    
    Cc: stable@vger.kernel.org
    Cc: Keith Packard <keithp@keithp.com>
    Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-6-daniel.vetter@ffwll.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 699f0e9d24c85545403794208051c5a5f5633dad
Author: Vicente Bergas <vicencb@gmail.com>
Date:   Tue Apr 2 13:37:53 2019 +0200

    drm/rockchip: shutdown drm subsystem on shutdown
    
    commit b8f9d7f37b6af829c34c49d1a4f73ce6ed58e403 upstream.
    
    As explained by Robin Murphy:
    > the IOMMU shutdown disables paging, so if the VOP is still
    > scanning out then that will result in whatever IOVAs it was using now going
    > straight out onto the bus as physical addresses.
    
    We had a more radical approach before in commit
    7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
    but that resulted in new warnings and oopses on shutdown on rk3399
    chromeos devices.
    
    So second try is resurrecting Vicentes shutdown change which should
    achieve the same result but in a less drastic way.
    
    Fixes: 63238173b2fa ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"")
    Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Brian Norris <briannorris@chromium.org>
    Cc: Doug Anderson <dianders@chromium.org>
    Cc: stable@vger.kernel.org
    Suggested-by: JeffyChen <jeffy.chen@rock-chips.com>
    Suggested-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Vicente Bergas <vicencb@gmail.com>
    [adapted commit message to explain the history]
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Tested-by: Brian Norris <briannorris@chromium.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190402113753.10118-1-heiko@sntech.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ca811507e416b774681447df27be134485fd155
Author: Jernej Skrabec <jernej.skrabec@siol.net>
Date:   Tue May 14 22:43:37 2019 +0200

    drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz
    
    commit 831adffb3b7b8df4c8e20b7b00843129fb87a166 upstream.
    
    Vendor provided documentation says that EMP bits should be set to 3 for
    pixel clocks greater than 148.5 MHz.
    
    Fix that.
    
    Cc: stable@vger.kernel.org # 4.17+
    Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190514204337.11068-3-jernej.skrabec@siol.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f1372206e0b2bf9e5208df3e603c84fa85b0d94
Author: Jernej Skrabec <jernej.skrabec@siol.net>
Date:   Tue May 14 22:43:36 2019 +0200

    drm/sun4i: Fix sun8i HDMI PHY clock initialization
    
    commit 8a943c6021ba8b95a36c842327e468df1fddd4a7 upstream.
    
    Current code initializes HDMI PHY clock driver before reset line is
    deasserted and clocks enabled. Because of that, initial readout of
    clock divider is incorrect (0 instead of 2). This causes any clock
    rate with divider 1 (register value 0) to be set incorrectly.
    
    Fix this by moving initialization of HDMI PHY clock driver after reset
    line is deasserted and clocks enabled.
    
    Cc: stable@vger.kernel.org # 4.17+
    Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190514204337.11068-2-jernej.skrabec@siol.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a20515c3c44b13d4851f408cc4d5e1ac32688f1
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue May 7 11:07:53 2019 +0200

    drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set
    
    commit 63cb44441826e842b7285575b96db631cc9f2505 upstream.
    
    This may confuse user-space clients like plymouth that opens a drm
    file descriptor as a result of a hotplug event and then generates a
    new event...
    
    Cc: <stable@vger.kernel.org>
    Fixes: 5ea1734827bb ("drm/vmwgfx: Send a hotplug event at master_set")
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Deepak Rawat <drawat@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1715a46322fa17037f2b1cc05f3cf9e1046c8a9e
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Thu Mar 7 01:55:19 2019 +0300

    drm/tegra: gem: Fix CPU-cache maintenance for BO's allocated using get_pages()
    
    commit 61b51fb51c01a519a249d28ec55c6513a13be5a3 upstream.
    
    The allocated pages need to be invalidated in CPU caches. On ARM32 the
    DMA_BIDIRECTIONAL flag only ensures that data is written-back to DRAM and
    the data stays in CPU cache lines. While the DMA_FROM_DEVICE flag ensures
    that the corresponding CPU cache lines are getting invalidated and nothing
    more, that's exactly what is needed for a newly allocated pages.
    
    This fixes randomly failing rendercheck tests on Tegra30 using the
    Opentegra driver for tests that use small-sized pixmaps (10x10 and less,
    i.e. 1-2 memory pages) because apparently CPU reads out stale data from
    caches and/or that data is getting evicted to DRAM at the time of HW job
    execution.
    
    Fixes: bd43c9f0fa1f ("drm/tegra: gem: Map pages via the DMA API")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 132137d1bfa16d6b127d7b3761c07540ea42a529
Author: Kees Cook <keescook@chromium.org>
Date:   Mon May 20 11:50:42 2019 -0700

    gcc-plugins: Fix build failures under Darwin host
    
    commit 7210e060155b9cf557fb13128353c3e494fa5ed3 upstream.
    
    The gcc-common.h file did not take into account certain macros that
    might have already been defined in the build environment. This updates
    the header to avoid redefining the macros, as seen on a Darwin host
    using gcc 4.9.2:
    
     HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
    In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
    scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
    ^
    In file included from /usr/include/stdio.h:64:0,
                    from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40,
                    from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28,
                    from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23,
                    from scripts/gcc-plugins/gcc-common.h:9,
                    from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
    /usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition
    ^
    
    Reported-and-tested-by: "H. Nikolaus Schaller" <hns@goldelico.com>
    Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 873041930dab5e03e9ef6f6adbee9f0a3e9dc034
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Mon May 20 10:33:07 2019 -0400

    Revert "lockd: Show pid of lockd for remote locks"
    
    commit 141731d15d6eb2fd9aaefbf9b935ce86ae243074 upstream.
    
    This reverts most of commit b8eee0e90f97 ("lockd: Show pid of lockd for
    remote locks"), which caused remote locks to not be differentiated between
    remote processes for NLM.
    
    We retain the fixup for setting the client's fl_pid to a negative value.
    
    Fixes: b8eee0e90f97 ("lockd: Show pid of lockd for remote locks")
    Cc: stable@vger.kernel.org
    
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: XueWei Zhang <xueweiz@google.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 297a251062c0d616e5d6644d4a041532c77d601f
Author: Roberto Bergantinos Corpas <rbergant@redhat.com>
Date:   Tue May 28 09:38:14 2019 +0200

    CIFS: cifs_read_allocate_pages: don't iterate through whole page array on ENOMEM
    
    commit 31fad7d41e73731f05b8053d17078638cf850fa6 upstream.
    
     In cifs_read_allocate_pages, in case of ENOMEM, we go through
    whole rdata->pages array but we have failed the allocation before
    nr_pages, therefore we may end up calling put_page with NULL
    pointer, causing oops
    
    Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
    Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32d57c0c063cdab6639da074e8b0f28517862e41
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri May 17 09:12:33 2019 +0100

    cifs: fix memory leak of pneg_inbuf on -EOPNOTSUPP ioctl case
    
    commit 210782038b54ec8e9059a3c12d6f6ae173efa3a9 upstream.
    
    Currently in the case where SMB2_ioctl returns the -EOPNOTSUPP error
    there is a memory leak of pneg_inbuf. Fix this by returning via
    the out_free_inbuf exit path that will perform the relevant kfree.
    
    Addresses-Coverity: ("Resource leak")
    Fixes: 969ae8e8d4ee ("cifs: Accept validate negotiate if server return NT_STATUS_NOT_SUPPORTED")
    CC: Stable <stable@vger.kernel.org> # v5.1+
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6a39f877feb5342aee6b7ca63a61ceedaa92be7
Author: Tim Collier <osdevtc@gmail.com>
Date:   Sat May 11 18:40:46 2019 +0100

    staging: wlan-ng: fix adapter initialization failure
    
    commit a67fedd788182764dc8ed59037c604b7e60349f1 upstream.
    
    Commit e895f00a8496 ("Staging: wlan-ng: hfa384x_usb.c Fixed too long
    code line warnings.") moved the retrieval of the transfer buffer from
    the URB from the top of function hfa384x_usbin_callback to a point
    after reposting of the URB via a call to submit_rx_urb. The reposting
    of the URB allocates a new transfer buffer so the new buffer is
    retrieved instead of the buffer containing the response passed into
    the callback. This results in failure to initialize the adapter with
    an error reported in the system log (something like "CTLX[1] error:
    state(Request failed)").
    
    This change moves the retrieval to just before the point where the URB
    is reposted so that the correct transfer buffer is retrieved and
    initialization of the device succeeds.
    
    Signed-off-by: Tim Collier <osdevtc@gmail.com>
    Fixes: e895f00a8496 ("Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27a4b6c8c1cf6c899afdd525b559b307bf21617a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 15 12:38:33 2019 +0300

    staging: vc04_services: prevent integer overflow in create_pagelist()
    
    commit ca641bae6da977d638458e78cd1487b6160a2718 upstream.
    
    The create_pagelist() "count" parameter comes from the user in
    vchiq_ioctl() and it could overflow.  If you look at how create_page()
    is called in vchiq_prepare_bulk_data(), then the "size" variable is an
    int so it doesn't make sense to allow negatives or larger than INT_MAX.
    
    I don't know this code terribly well, but I believe that typical values
    of "count" are typically quite low and I don't think this check will
    affect normal valid uses at all.
    
    The "pagelist_size" calculation can also overflow on 32 bit systems, but
    not on 64 bit systems.  I have added an integer overflow check for that
    as well.
    
    The Raspberry PI doesn't offer the same level of memory protection that
    x86 does so these sorts of bugs are probably not super critical to fix.
    
    Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3078e80b03c8f5ba35fa265c2aa8242275236890
Author: George G. Davis <george_davis@mentor.com>
Date:   Tue May 14 23:29:34 2019 -0400

    serial: sh-sci: disable DMA for uart_console
    
    commit 099506cbbc79c0bd52b19cb6b930f256dabc3950 upstream.
    
    As noted in commit 84b40e3b57ee ("serial: 8250: omap: Disable DMA for
    console UART"), UART console lines use low-level PIO only access functions
    which will conflict with use of the line when DMA is enabled, e.g. when
    the console line is also used for systemd messages. So disable DMA
    support for UART console lines.
    
    Reported-by: Michael Rodin <mrodin@de.adit-jv.com>
    Link: https://patchwork.kernel.org/patch/10929511/
    Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff818b449a5bbf29c5c7085f391fe384830d4830
Author: Grzegorz Halat <ghalat@redhat.com>
Date:   Fri Apr 26 16:59:46 2019 +0200

    vt/fbcon: deinitialize resources in visual_init() after failed memory allocation
    
    commit a1ad1cc9704f64c169261a76e1aee1cf1ae51832 upstream.
    
    After memory allocation failure vc_allocate() doesn't clean up data
    which has been initialized in visual_init(). In case of fbcon this
    leads to divide-by-0 in fbcon_init() on next open of the same tty.
    
    memory allocation in vc_allocate() may fail here:
    1097:     vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
    
    on next open() fbcon_init() skips vc_font.data initialization:
    1088:     if (!p->fontdata) {
    
    division by zero in fbcon_init() happens here:
    1149:     new_cols /= vc->vc_font.width;
    
    Additional check is needed in fbcon_deinit() to prevent
    usage of uninitialized vc_screenbuf:
    
    1251:        if (vc->vc_hi_font_mask && vc->vc_screenbuf)
    1252:                set_vc_hi_font(vc, false);
    
    Crash:
    
     #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4
        [exception RIP: fbcon_init+463]
        RIP: ffffffff814b860f  RSP: ffffc90001eafb18  RFLAGS: 00010246
    ...
     #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e
     #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c
     #9 [ffffc90001eafbc8] con_install at ffffffff8154f624
    ...
    
    Signed-off-by: Grzegorz Halat <ghalat@redhat.com>
    Reviewed-by: Oleksandr Natalenko <oleksandr@redhat.com>
    Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e322a9e42cd9099121e786b326bc840ac28b5e0
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Wed May 29 15:30:33 2019 +0200

    evm: check hash algorithm passed to init_desc()
    
    commit 221be106d75c1b511973301542f47d6000d0b63e upstream.
    
    This patch prevents memory access beyond the evm_tfm array by checking the
    validity of the index (hash algorithm) passed to init_desc(). The hash
    algorithm can be arbitrarily set if the security.ima xattr type is not
    EVM_XATTR_HMAC.
    
    Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f85b87a9a2a8bdd2eee28a378a7124d775800122
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Wed May 29 15:30:35 2019 +0200

    ima: show rules with IMA_INMASK correctly
    
    commit 8cdc23a3d9ec0944000ad43bad588e36afdc38cd upstream.
    
    Show the '^' character when a policy rule has flag IMA_INMASK.
    
    Fixes: 80eae209d63ac ("IMA: allow reading back the current IMA policy")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21158982f6b7c408c6e0fa90b6a26ceb983a4461
Author: Jonathan Corbet <corbet@lwn.net>
Date:   Tue May 21 14:23:43 2019 -0600

    doc: Cope with Sphinx logging deprecations
    
    commit 096ea522e84ea68f8e6c41e5e7294731a81e29bc upstream.
    
    Recent versions of sphinx will emit messages like:
    
      Documentation/sphinx/kerneldoc.py:103:
         RemovedInSphinx20Warning: app.warning() is now deprecated.
         Use sphinx.util.logging instead.
    
    Switch to sphinx.util.logging to make this unsightly message go away.
    Alas, that interface was only added in version 1.6, so we have to add a
    version check to keep things working with older sphinxes.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0742228bba633537f3d268275a4bdb93afbdc50
Author: Jonathan Corbet <corbet@lwn.net>
Date:   Tue May 21 14:42:34 2019 -0600

    doc: Cope with the deprecation of AutoReporter
    
    commit 2404dad1f67f8917e30fc22a85e0dbcc85b99955 upstream.
    
    AutoReporter is going away; recent versions of sphinx emit a warning like:
    
      Documentation/sphinx/kerneldoc.py:125:
          RemovedInSphinx20Warning: AutodocReporter is now deprecated.
          Use sphinx.util.docutils.switch_source_input() instead.
    
    Make the switch.  But switch_source_input() only showed up in 1.7, so we
    have to do ugly version checks to keep things working in older versions.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 301b18edbf5673ceabd096e95bff0d4cd228a854
Author: Jonathan Corbet <corbet@lwn.net>
Date:   Wed May 22 14:30:45 2019 -0600

    docs: Fix conf.py for Sphinx 2.0
    
    commit 3bc8088464712fdcb078eefb68837ccfcc413c88 upstream.
    
    Our version check in Documentation/conf.py never envisioned a world where
    Sphinx moved beyond 1.x.  Now that the unthinkable has happened, fix our
    version check to handle higher version numbers correctly.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 871953434bd952a8820832452d3ce2b9ee236cb8
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue May 28 12:39:34 2019 +0100

    arm64: Fix the arm64_personality() syscall wrapper redirection
    
    commit 00377277166bac6939d8f72b429301369acaf2d8 upstream.
    
    Following commit 4378a7d4be30 ("arm64: implement syscall wrappers"), the
    syscall function names gained the '__arm64_' prefix. Ensure that we
    have the correct #define for redirecting a default syscall through a
    wrapper.
    
    Fixes: 4378a7d4be30 ("arm64: implement syscall wrappers")
    Cc: <stable@vger.kernel.org> # 4.19.x-
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f8d26270ce359ff53837febf0993842611a6cfe
Author: Zhenliang Wei <weizhenliang@huawei.com>
Date:   Fri May 31 22:30:52 2019 -0700

    kernel/signal.c: trace_signal_deliver when signal_group_exit
    
    commit 98af37d624ed8c83f1953b1b6b2f6866011fc064 upstream.
    
    In the fixes commit, removing SIGKILL from each thread signal mask and
    executing "goto fatal" directly will skip the call to
    "trace_signal_deliver".  At this point, the delivery tracking of the
    SIGKILL signal will be inaccurate.
    
    Therefore, we need to add trace_signal_deliver before "goto fatal" after
    executing sigdelset.
    
    Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info.
    
    Link: http://lkml.kernel.org/r/20190425025812.91424-1-weizhenliang@huawei.com
    Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
    Signed-off-by: Zhenliang Wei <weizhenliang@huawei.com>
    Reviewed-by: Christian Brauner <christian@brauner.io>
    Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Ivan Delalande <colona@arista.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Deepa Dinamani <deepa.kernel@gmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b057ad846c5919ec4e3462fa373a86e75594a41
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri May 31 22:30:26 2019 -0700

    memcg: make it work on sparse non-0-node systems
    
    commit 3e8589963773a5c23e2f1fe4bcad0e9a90b7f471 upstream.
    
    We have a single node system with node 0 disabled:
      Scanning NUMA topology in Northbridge 24
      Number of physical nodes 2
      Skipping disabled node 0
      Node 1 MemBase 0000000000000000 Limit 00000000fbff0000
      NODE_DATA(1) allocated [mem 0xfbfda000-0xfbfeffff]
    
    This causes crashes in memcg when system boots:
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      #PF error: [normal kernel read fault]
    ...
      RIP: 0010:list_lru_add+0x94/0x170
    ...
      Call Trace:
       d_lru_add+0x44/0x50
       dput.part.34+0xfc/0x110
       __fput+0x108/0x230
       task_work_run+0x9f/0xc0
       exit_to_usermode_loop+0xf5/0x100
    
    It is reproducible as far as 4.12.  I did not try older kernels.  You have
    to have a new enough systemd, e.g.  241 (the reason is unknown -- was not
    investigated).  Cannot be reproduced with systemd 234.
    
    The system crashes because the size of lru array is never updated in
    memcg_update_all_list_lrus and the reads are past the zero-sized array,
    causing dereferences of random memory.
    
    The root cause are list_lru_memcg_aware checks in the list_lru code.  The
    test in list_lru_memcg_aware is broken: it assumes node 0 is always
    present, but it is not true on some systems as can be seen above.
    
    So fix this by avoiding checks on node 0.  Remember the memcg-awareness by
    a bool flag in struct list_lru.
    
    Link: http://lkml.kernel.org/r/20190522091940.3615-1-jslaby@suse.cz
    Fixes: 60d3fd32a7a9 ("list_lru: introduce per-memcg lists")
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Suggested-by: Vladimir Davydov <vdavydov.dev@gmail.com>
    Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e29e2ecf186cf2bb4c1e949cb25e25f36699d96
Author: Joe Burmeister <joe.burmeister@devtank.co.uk>
Date:   Mon May 13 11:23:57 2019 +0100

    tty: max310x: Fix external crystal register setup
    
    commit 5d24f455c182d5116dd5db8e1dc501115ecc9c2c upstream.
    
    The datasheet states:
    
      Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking
    (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable
    clocking
      Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal
    oscillator. When using an external clock source at XIN, CrystalEn must
    be set low.
    
    The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not.
    
    This was required to make the MAX3107 with an external crystal on our
    board able to send or receive data.
    
    Signed-off-by: Joe Burmeister <joe.burmeister@devtank.co.uk>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a071517b85cc2f33102c61a674de1dc8af79cf34
Author: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Date:   Mon May 20 20:38:48 2019 +0200

    tty: serial: msm_serial: Fix XON/XOFF
    
    commit 61c0e37950b88bad590056286c1d766b1f167f4e upstream.
    
    When the tty layer requests the uart to throttle, the current code
    executing in msm_serial will trigger "Bad mode in Error Handler" and
    generate an invalid stack frame in pstore before rebooting (that is if
    pstore is indeed configured: otherwise the user shall just notice a
    reboot with no further information dumped to the console).
    
    This patch replaces the PIO byte accessor with the word accessor
    already used in PIO mode.
    
    Fixes: 68252424a7c7 ("tty: serial: msm: Support big-endian CPUs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb03290431bcd133a2e95b886b176c3e9e297317
Author: Masahisa Kojima <masahisa.kojima@linaro.org>
Date:   Tue May 21 10:33:50 2019 +0900

    i2c: synquacer: fix synquacer_i2c_doxfer() return value
    
    commit ff9378904d9d7a3fcb8406604e089e535e357b1d upstream.
    
    master_xfer should return the number of messages successfully
    processed.
    
    Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller")
    Cc: <stable@vger.kernel.org> # v4.19+
    Signed-off-by: Okamoto Satoru <okamoto.satoru@socionext.com>
    Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2d8f64012543898a0158b1fc5c07af3d41c89d8
Author: Vadim Pasternak <vadimp@mellanox.com>
Date:   Thu May 16 17:15:41 2019 +0000

    i2c: mlxcpld: Fix wrong initialization order in probe
    
    commit 13067ef73f337336e3149f5bb9f3fd05fe7f87a0 upstream.
    
    Fix wrong order in probing routine initialization - field `base_addr'
    is used before it's initialized. Move assignment of 'priv->base_addr`
    to the beginning, prior the call to mlxcpld_i2c_read_comm().
    Wrong order caused the first read of capability register to be executed
    at wrong offset 0x0 instead of 0x2000. By chance it was a "good
    garbage" at 0x0 offset.
    
    Fixes: 313ce648b5a4 ("i2c: mlxcpld: Add support for extended transaction length for i2c-mlxcpld")
    Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88ad86b807823791ab4f87b25f2100dc6189d3ba
Author: Lyude Paul <lyude@redhat.com>
Date:   Tue Apr 9 16:23:30 2019 -0400

    drm/nouveau/i2c: Disable i2c bus access after ->fini()
    
    commit 342406e4fbba9a174125fbfe6aeac3d64ef90f76 upstream.
    
    For a while, we've had the problem of i2c bus access not grabbing
    a runtime PM ref when it's being used in userspace by i2c-dev, resulting
    in nouveau spamming the kernel log with errors if anything attempts to
    access the i2c bus while the GPU is in runtime suspend. An example:
    
    [  130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff
    
    Since the GPU is in runtime suspend, the MMIO region that the i2c bus is
    on isn't accessible. On x86, the standard behavior for accessing an
    unavailable MMIO region is to just return ~0.
    
    Except, that turned out to be a lie. While computers with a clean
    concious will return ~0 in this scenario, some machines will actually
    completely hang a CPU on certian bad MMIO accesses. This was witnessed
    with someone's Lenovo ThinkPad P50, where sensors-detect attempting to
    access the i2c bus while the GPU was suspended would result in a CPU
    hang:
    
      CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1
      Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017
      RIP: 0010:ioread32+0x2b/0x30
      Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3
      48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f
      40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48
      RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13
      RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186
      RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4
      RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7
      R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000
      R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000
      FS:  00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       g94_i2c_aux_xfer+0x326/0x850 [nouveau]
       nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau]
       __i2c_transfer+0x14b/0x620
       i2c_smbus_xfer_emulated+0x159/0x680
       ? _raw_spin_unlock_irqrestore+0x1/0x60
       ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0
       ? __lock_is_held+0x59/0xa0
       __i2c_smbus_xfer+0x138/0x5a0
       i2c_smbus_xfer+0x4f/0x80
       i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev]
       i2cdev_ioctl+0x1db/0x2c0 [i2c_dev]
       do_vfs_ioctl+0x408/0x750
       ksys_ioctl+0x5e/0x90
       __x64_sys_ioctl+0x16/0x20
       do_syscall_64+0x60/0x1e0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7f25317f546b
      Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
      ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
      f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b
      RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003
      RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0
      R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80
      R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0
      watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438]
    
    Yikes! While I wanted to try to make it so that accessing an i2c bus on
    nouveau would wake up the GPU as needed, airlied pointed out that pretty
    much any usecase for userspace accessing an i2c bus on a GPU (mainly for
    the DDC brightness control that some displays have) is going to only be
    useful while there's at least one display enabled on the GPU anyway, and
    the GPU never sleeps while there's displays running.
    
    Since teaching the i2c bus to wake up the GPU on userspace accesses is a
    good deal more difficult than it might seem, mostly due to the fact that
    we have to use the i2c bus during runtime resume of the GPU, we instead
    opt for the easiest solution: don't let userspace access i2c busses on
    the GPU at all while it's in runtime suspend.
    
    Changes since v1:
    * Also disable i2c busses that run over DP AUX
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a2fbec70766670b967f6e092ceb9bfd3dd935ba
Author: Thomas Huth <thuth@redhat.com>
Date:   Thu May 23 18:43:08 2019 +0200

    KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
    
    commit a86cb413f4bf273a9d341a3ab2c2ca44e12eb317 upstream.
    
    KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all
    architectures. However, on s390x, the amount of usable CPUs is determined
    during runtime - it is depending on the features of the machine the code
    is running on. Since we are using the vcpu_id as an index into the SCA
    structures that are defined by the hardware (see e.g. the sca_add_vcpu()
    function), it is not only the amount of CPUs that is limited by the hard-
    ware, but also the range of IDs that we can use.
    Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too.
    So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common
    code into the architecture specific code, and on s390x we have to return
    the same value here as for KVM_CAP_MAX_VCPUS.
    This problem has been discovered with the kvm_create_max_vcpus selftest.
    With this change applied, the selftest now passes on s390x, too.
    
    Reviewed-by: Andrew Jones <drjones@redhat.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Message-Id: <20190523164309.13345-9-thuth@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3834630ef4d33f2a372e01dadeb6980761259a90
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed May 29 12:41:38 2019 +0800

    ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops
    
    commit 9cb40eb184c4220d244a532bd940c6345ad9dbd9 upstream.
    
    We met another Acer Aspire laptop which has the problem on the
    headset-mic, the Pin 0x19 is not set the corret configuration for a
    mic and the pin presence can't be detected too after plugging a
    headset. Kailang suggested that we should set the coeff to enable the
    mic and apply the ALC269_FIXUP_LIFEBOOK_EXTMIC. After doing that,
    both headset-mic presence and headset-mic work well.
    
    The existing ALC255_FIXUP_ACER_MIC_NO_PRESENCE set the headset-mic
    jack to be a phantom jack. Now since the jack can support presence
    unsol event, let us imporve it to set the jack to be a normal jack.
    
    https://bugs.launchpad.net/bugs/1821269
    Fixes: 5824ce8de7b1c ("ALSA: hda/realtek - Add support for Acer Aspire E5-475 headset mic")
    Cc: Chris Chiu <chiu@endlessm.com>
    CC: Daniel Drake <drake@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cfd6c36759b1e54c2bbf36f1d03b4e1bbc61d7e
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu May 23 14:43:04 2019 +0800

    ALSA: hda/realtek - Set default power save node to 0
    
    commit 317d9313925cd8388304286c0d3c8dda7f060a2d upstream.
    
    I measured power consumption between power_save_node=1 and power_save_node=0.
    It's almost the same.
    Codec will enter to runtime suspend and suspend.
    That pin also will enter to D3. Don't need to enter to D3 by single pin.
    So, Disable power_save_node as default. It will avoid more issues.
    Windows Driver also has not this option at runtime PM.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb2eeec920fb1b9b6faf8ea340f6295a2d03602b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue May 28 08:39:44 2019 +0200

    ALSA: line6: Assure canceling delayed work at disconnection
    
    commit 0b074ab7fc0d575247b9cc9f93bb7e007ca38840 upstream.
    
    The current code performs the cancel of a delayed work at the late
    stage of disconnection procedure, which may lead to the access to the
    already cleared state.
    
    This patch assures to call cancel_delayed_work_sync() at the beginning
    of the disconnection procedure for avoiding that race.  The delayed
    work object is now assigned in the common line6 object instead of its
    derivative, so that we can call cancel_delayed_work_sync().
    
    Along with the change, the startup function is called via the new
    callback instead.  This will make it easier to port other LINE6
    drivers to use the delayed work for startup in later patches.
    
    Reported-by: syzbot+5255458d5e0a2b10bbb9@syzkaller.appspotmail.com
    Fixes: 7f84ff68be05 ("ALSA: line6: toneport: Fix broken usage of timer for delayed execution")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca221cf9ab6f30ecbd6280606d6f32253ee8d72b
Author: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Date:   Sat May 11 08:12:17 2019 +0530

    powerpc/perf: Fix MMCRA corruption by bhrb_filter
    
    commit 3202e35ec1c8fc19cea24253ff83edf702a60a02 upstream.
    
    Consider a scenario where user creates two events:
    
      1st event:
        attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
        attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY;
        fd = perf_event_open(attr, 0, 1, -1, 0);
    
      This sets cpuhw->bhrb_filter to 0 and returns valid fd.
    
      2nd event:
        attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
        attr.branch_sample_type = PERF_SAMPLE_BRANCH_CALL;
        fd = perf_event_open(attr, 0, 1, -1, 0);
    
      It overrides cpuhw->bhrb_filter to -1 and returns with error.
    
    Now if power_pmu_enable() gets called by any path other than
    power_pmu_add(), ppmu->config_bhrb(-1) will set MMCRA to -1.
    
    Fixes: 3925f46bb590 ("powerpc/perf: Enable branch stack sampling framework")
    Cc: stable@vger.kernel.org # v3.10+
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55a94d81f5363bcf048ba8c14117dba67e4bea7b
Author: Cédric Le Goater <clg@kaod.org>
Date:   Tue May 28 14:17:15 2019 +0200

    KVM: PPC: Book3S HV: XIVE: Do not clear IRQ data of passthrough interrupts
    
    commit ef9740204051d0e00f5402fe96cf3a43ddd2bbbf upstream.
    
    The passthrough interrupts are defined at the host level and their IRQ
    data should not be cleared unless specifically deconfigured (shutdown)
    by the host. They differ from the IPI interrupts which are allocated
    by the XIVE KVM device and reserved to the guest usage only.
    
    This fixes a host crash when destroying a VM in which a PCI adapter
    was passed-through. In this case, the interrupt is cleared and freed
    by the KVM device and then shutdown by vfio at the host level.
    
    [ 1007.360265] BUG: Kernel NULL pointer dereference at 0x00000d00
    [ 1007.360285] Faulting instruction address: 0xc00000000009da34
    [ 1007.360296] Oops: Kernel access of bad area, sig: 7 [#1]
    [ 1007.360303] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
    [ 1007.360314] Modules linked in: vhost_net vhost iptable_mangle ipt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc kvm_hv kvm xt_tcpudp iptable_filter squashfs fuse binfmt_misc vmx_crypto ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi nfsd ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq multipath mlx5_ib ib_uverbs ib_core crc32c_vpmsum mlx5_core
    [ 1007.360425] CPU: 9 PID: 15576 Comm: CPU 18/KVM Kdump: loaded Not tainted 5.1.0-gad7e7d0ef #4
    [ 1007.360454] NIP:  c00000000009da34 LR: c00000000009e50c CTR: c00000000009e5d0
    [ 1007.360482] REGS: c000007f24ccf330 TRAP: 0300   Not tainted  (5.1.0-gad7e7d0ef)
    [ 1007.360500] MSR:  900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24002484  XER: 00000000
    [ 1007.360532] CFAR: c00000000009da10 DAR: 0000000000000d00 DSISR: 00080000 IRQMASK: 1
    [ 1007.360532] GPR00: c00000000009e62c c000007f24ccf5c0 c000000001510600 c000007fe7f947c0
    [ 1007.360532] GPR04: 0000000000000d00 0000000000000000 0000000000000000 c000005eff02d200
    [ 1007.360532] GPR08: 0000000000400000 0000000000000000 0000000000000000 fffffffffffffffd
    [ 1007.360532] GPR12: c00000000009e5d0 c000007fffff7b00 0000000000000031 000000012c345718
    [ 1007.360532] GPR16: 0000000000000000 0000000000000008 0000000000418004 0000000000040100
    [ 1007.360532] GPR20: 0000000000000000 0000000008430000 00000000003c0000 0000000000000027
    [ 1007.360532] GPR24: 00000000000000ff 0000000000000000 00000000000000ff c000007faa90d98c
    [ 1007.360532] GPR28: c000007faa90da40 00000000000fe040 ffffffffffffffff c000007fe7f947c0
    [ 1007.360689] NIP [c00000000009da34] xive_esb_read+0x34/0x120
    [ 1007.360706] LR [c00000000009e50c] xive_do_source_set_mask.part.0+0x2c/0x50
    [ 1007.360732] Call Trace:
    [ 1007.360738] [c000007f24ccf5c0] [c000000000a6383c] snooze_loop+0x15c/0x270 (unreliable)
    [ 1007.360775] [c000007f24ccf5f0] [c00000000009e62c] xive_irq_shutdown+0x5c/0xe0
    [ 1007.360795] [c000007f24ccf630] [c00000000019e4a0] irq_shutdown+0x60/0xe0
    [ 1007.360813] [c000007f24ccf660] [c000000000198c44] __free_irq+0x3a4/0x420
    [ 1007.360831] [c000007f24ccf700] [c000000000198dc8] free_irq+0x78/0xe0
    [ 1007.360849] [c000007f24ccf730] [c00000000096c5a8] vfio_msi_set_vector_signal+0xa8/0x350
    [ 1007.360878] [c000007f24ccf7f0] [c00000000096c938] vfio_msi_set_block+0xe8/0x1e0
    [ 1007.360899] [c000007f24ccf850] [c00000000096cae0] vfio_msi_disable+0xb0/0x110
    [ 1007.360912] [c000007f24ccf8a0] [c00000000096cd04] vfio_pci_set_msi_trigger+0x1c4/0x3d0
    [ 1007.360922] [c000007f24ccf910] [c00000000096d910] vfio_pci_set_irqs_ioctl+0xa0/0x170
    [ 1007.360941] [c000007f24ccf930] [c00000000096b400] vfio_pci_disable+0x80/0x5e0
    [ 1007.360963] [c000007f24ccfa10] [c00000000096b9bc] vfio_pci_release+0x5c/0x90
    [ 1007.360991] [c000007f24ccfa40] [c000000000963a9c] vfio_device_fops_release+0x3c/0x70
    [ 1007.361012] [c000007f24ccfa70] [c0000000003b5668] __fput+0xc8/0x2b0
    [ 1007.361040] [c000007f24ccfac0] [c0000000001409b0] task_work_run+0x140/0x1b0
    [ 1007.361059] [c000007f24ccfb20] [c000000000118f8c] do_exit+0x3ac/0xd00
    [ 1007.361076] [c000007f24ccfc00] [c0000000001199b0] do_group_exit+0x60/0x100
    [ 1007.361094] [c000007f24ccfc40] [c00000000012b514] get_signal+0x1a4/0x8f0
    [ 1007.361112] [c000007f24ccfd30] [c000000000021cc8] do_notify_resume+0x1a8/0x430
    [ 1007.361141] [c000007f24ccfe20] [c00000000000e444] ret_from_except_lite+0x70/0x74
    [ 1007.361159] Instruction dump:
    [ 1007.361175] 38422c00 e9230000 712a0004 41820010 548a2036 7d442378 78840020 71290020
    [ 1007.361194] 4082004c e9230010 7c892214 7c0004ac <e9240000> 0c090000 4c00012c 792a0022
    
    Cc: stable@vger.kernel.org # v4.12+
    Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
    Signed-off-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Greg Kurz <groug@kaod.org>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit badbe1abbd5985da9cfe1d5910f64c4965407d08
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Mon May 27 15:24:20 2019 +0200

    s390/crypto: fix possible sleep during spinlock aquired
    
    commit 1c2c7029c008922d4d48902cc386250502e73d51 upstream.
    
    This patch fixes a complain about possible sleep during
    spinlock aquired
    "BUG: sleeping function called from invalid context at
    include/crypto/algapi.h:426"
    for the ctr(aes) and ctr(des) s390 specific ciphers.
    
    Instead of using a spinlock this patch introduces a mutex
    which is save to be held in sleeping context. Please note
    a deadlock is not possible as mutex_trylock() is used.
    
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Reported-by: Julian Wiedmann <jwi@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83c874cf6861b880dbb21f59fdb61394033950bd
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Thu May 23 16:18:25 2019 +0200

    s390/crypto: fix gcm-aes-s390 selftest failures
    
    commit bef9f0ba300a55d79a69aa172156072182176515 upstream.
    
    The current kernel uses improved crypto selftests. These
    tests showed that the current implementation of gcm-aes-s390
    is not able to deal with chunks of output buffers which are
    not a multiple of 16 bytes. This patch introduces a rework
    of the gcm aes s390 scatter walk handling which now is able
    to handle any input and output scatter list chunk sizes
    correctly.
    
    Code has been verified by the crypto selftests, the tcrypt
    kernel module and additional tests ran via the af_alg interface.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Julian Wiedmann <jwi@linux.ibm.com>
    Reviewed-by: Patrick Steuer <steuer@linux.ibm.com>
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dede5c9e60503151e3f28c0955e4cb8757cadf2
Author: Sean Nyekjaer <sean@geanix.com>
Date:   Tue May 7 10:23:04 2019 +0200

    iio: adc: ti-ads8688: fix timestamp is not updated in buffer
    
    commit e6d12298310fa1dc11f1d747e05b168016057fdd upstream.
    
    When using the hrtimer iio trigger timestamp isn't updated.
    If we use iio_get_time_ns it is updated correctly.
    
    Fixes: 2a86487786b5c ("iio: adc: ti-ads8688: add trigger and buffer support")
    Signed-off-by: Sean Nyekjaer <sean@geanix.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06c5ec6fd0b17b4c5491c58b47133d21388eec62
Author: Ruslan Babayev <ruslan@babayev.com>
Date:   Sun May 5 12:24:37 2019 -0700

    iio: dac: ds4422/ds4424 fix chip verification
    
    commit 60f2208699ec08ff9fdf1f97639a661a92a18f1c upstream.
    
    The ds4424_get_value function takes channel number as it's 3rd
    argument and translates it internally into I2C address using
    DS4424_DAC_ADDR macro. The caller ds4424_verify_chip was passing an
    already translated I2C address as its last argument.
    
    Signed-off-by: Ruslan Babayev <ruslan@babayev.com>
    Cc: xe-linux-external@cisco.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a652fd142c38d03f6e83a054cff40f2e6878beb
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon May 20 09:55:42 2019 +0100

    Btrfs: incremental send, fix file corruption when no-holes feature is enabled
    
    commit 6b1f72e5b82a5c2a4da4d1ebb8cc01913ddbea21 upstream.
    
    When using the no-holes feature, if we have a file with prealloc extents
    with a start offset beyond the file's eof, doing an incremental send can
    cause corruption of the file due to incorrect hole detection. Such case
    requires that the prealloc extent(s) exist in both the parent and send
    snapshots, and that a hole is punched into the file that covers all its
    extents that do not cross the eof boundary.
    
    Example reproducer:
    
      $ mkfs.btrfs -f -O no-holes /dev/sdb
      $ mount /dev/sdb /mnt/sdb
    
      $ xfs_io -f -c "pwrite -S 0xab 0 500K" /mnt/sdb/foobar
      $ xfs_io -c "falloc -k 1200K 800K" /mnt/sdb/foobar
    
      $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/base
    
      $ btrfs send -f /tmp/base.snap /mnt/sdb/base
    
      $ xfs_io -c "fpunch 0 500K" /mnt/sdb/foobar
    
      $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/incr
    
      $ btrfs send -p /mnt/sdb/base -f /tmp/incr.snap /mnt/sdb/incr
    
      $ md5sum /mnt/sdb/incr/foobar
      816df6f64deba63b029ca19d880ee10a   /mnt/sdb/incr/foobar
    
      $ mkfs.btrfs -f /dev/sdc
      $ mount /dev/sdc /mnt/sdc
    
      $ btrfs receive -f /tmp/base.snap /mnt/sdc
      $ btrfs receive -f /tmp/incr.snap /mnt/sdc
    
      $ md5sum /mnt/sdc/incr/foobar
      cf2ef71f4a9e90c2f6013ba3b2257ed2   /mnt/sdc/incr/foobar
    
        --> Different checksum, because the prealloc extent beyond the
            file's eof confused the hole detection code and it assumed
            a hole starting at offset 0 and ending at the offset of the
            prealloc extent (1200Kb) instead of ending at the offset
            500Kb (the file's size).
    
    Fix this by ensuring we never cross the file's size when issuing the
    write operations for a hole.
    
    Fixes: 16e7549f045d33 ("Btrfs: incompatible format change to remove hole extents")
    CC: stable@vger.kernel.org # 3.14+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a81071110d25a83e749b2f58f0e337ac6782c12c
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu May 16 15:48:55 2019 +0100

    Btrfs: fix fsync not persisting changed attributes of a directory
    
    commit 60d9f50308e5df19bc18c2fefab0eba4a843900a upstream.
    
    While logging an inode we follow its ancestors and for each one we mark
    it as logged in the current transaction, even if we have not logged it.
    As a consequence if we change an attribute of an ancestor, such as the
    UID or GID for example, and then explicitly fsync it, we end up not
    logging the inode at all despite returning success to user space, which
    results in the attribute being lost if a power failure happens after
    the fsync.
    
    Sample reproducer:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount /dev/sdb /mnt
    
      $ mkdir /mnt/dir
      $ chown 6007:6007 /mnt/dir
    
      $ sync
    
      $ chown 9003:9003 /mnt/dir
      $ touch /mnt/dir/file
      $ xfs_io -c fsync /mnt/dir/file
    
      # fsync our directory after fsync'ing the new file, should persist the
      # new values for the uid and gid.
      $ xfs_io -c fsync /mnt/dir
    
      <power failure>
    
      $ mount /dev/sdb /mnt
      $ stat -c %u:%g /mnt/dir
      6007:6007
    
        --> should be 9003:9003, the uid and gid were not persisted, despite
            the explicit fsync on the directory prior to the power failure
    
    Fix this by not updating the logged_trans field of ancestor inodes when
    logging an inode, since we have not logged them. Let only future calls to
    btrfs_log_inode() to mark inodes as logged.
    
    This could be triggered by my recent fsync fuzz tester for fstests, for
    which an fstests patch exists titled "fstests: generic, fsync fuzz tester
    with fsstress".
    
    Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37fe038328a20980f45ba7a37c9fa64708a374e7
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed May 15 16:03:17 2019 +0100

    Btrfs: fix race updating log root item during fsync
    
    commit 06989c799f04810f6876900d4760c0edda369cf7 upstream.
    
    When syncing the log, the final phase of a fsync operation, we need to
    either create a log root's item or update the existing item in the log
    tree of log roots, and that depends on the current value of the log
    root's log_transid - if it's 1 we need to create the log root item,
    otherwise it must exist already and we update it. Since there is no
    synchronization between updating the log_transid and checking it for
    deciding whether the log root's item needs to be created or updated, we
    end up with a tiny race window that results in attempts to update the
    item to fail because the item was not yet created:
    
                  CPU 1                                    CPU 2
    
      btrfs_sync_log()
    
        lock root->log_mutex
    
        set log root's log_transid to 1
    
        unlock root->log_mutex
    
                                                   btrfs_sync_log()
    
                                                     lock root->log_mutex
    
                                                     sets log root's
                                                     log_transid to 2
    
                                                     unlock root->log_mutex
    
        update_log_root()
    
          sees log root's log_transid
          with a value of 2
    
            calls btrfs_update_root(),
            which fails with -EUCLEAN
            and causes transaction abort
    
    Until recently the race lead to a BUG_ON at btrfs_update_root(), but after
    the recent commit 7ac1e464c4d47 ("btrfs: Don't panic when we can't find a
    root key") we just abort the current transaction.
    
    A sample trace of the BUG_ON() on a SLE12 kernel:
    
      ------------[ cut here ]------------
      kernel BUG at ../fs/btrfs/root-tree.c:157!
      Oops: Exception in kernel mode, sig: 5 [#1]
      SMP NR_CPUS=2048 NUMA pSeries
      (...)
      Supported: Yes, External
      CPU: 78 PID: 76303 Comm: rtas_errd Tainted: G                 X 4.4.156-94.57-default #1
      task: c00000ffa906d010 ti: c00000ff42b08000 task.ti: c00000ff42b08000
      NIP: d000000036ae5cdc LR: d000000036ae5cd8 CTR: 0000000000000000
      REGS: c00000ff42b0b860 TRAP: 0700   Tainted: G                 X  (4.4.156-94.57-default)
      MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 22444484  XER: 20000000
      CFAR: d000000036aba66c SOFTE: 1
      GPR00: d000000036ae5cd8 c00000ff42b0bae0 d000000036bda220 0000000000000054
      GPR04: 0000000000000001 0000000000000000 c00007ffff8d37c8 0000000000000000
      GPR08: c000000000e19c00 0000000000000000 0000000000000000 3736343438312079
      GPR12: 3930373337303434 c000000007a3a800 00000000007fffff 0000000000000023
      GPR16: c00000ffa9d26028 c00000ffa9d261f8 0000000000000010 c00000ffa9d2ab28
      GPR20: c00000ff42b0bc48 0000000000000001 c00000ff9f0d9888 0000000000000001
      GPR24: c00000ffa9d26000 c00000ffa9d261e8 c00000ffa9d2a800 c00000ff9f0d9888
      GPR28: c00000ffa9d26028 c00000ffa9d2aa98 0000000000000001 c00000ffa98f5b20
      NIP [d000000036ae5cdc] btrfs_update_root+0x25c/0x4e0 [btrfs]
      LR [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs]
      Call Trace:
      [c00000ff42b0bae0] [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs] (unreliable)
      [c00000ff42b0bba0] [d000000036b53610] btrfs_sync_log+0x2d0/0xc60 [btrfs]
      [c00000ff42b0bce0] [d000000036b1785c] btrfs_sync_file+0x44c/0x4e0 [btrfs]
      [c00000ff42b0bd80] [c00000000032e300] vfs_fsync_range+0x70/0x120
      [c00000ff42b0bdd0] [c00000000032e44c] do_fsync+0x5c/0xb0
      [c00000ff42b0be10] [c00000000032e8dc] SyS_fdatasync+0x2c/0x40
      [c00000ff42b0be30] [c000000000009488] system_call+0x3c/0x100
      Instruction dump:
      7f43d378 4bffebb9 60000000 88d90008 3d220000 e8b90000 3b390009 e87a01f0
      e8898e08 e8f90000 4bfd48e5 60000000 <0fe00000> e95b0060 39200004 394a0ea0
      ---[ end trace 8f2dc8f919cabab8 ]---
    
    So fix this by doing the check of log_transid and updating or creating the
    log root's item while holding the root's log_mutex.
    
    Fixes: 7237f1833601d ("Btrfs: fix tree logs parallel sync")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7301bbeae98f265dbd3ba5571b27bdd39fbf4797
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed May 15 16:02:47 2019 +0100

    Btrfs: fix wrong ctime and mtime of a directory after log replay
    
    commit 5338e43abbab13791144d37fd8846847062351c6 upstream.
    
    When replaying a log that contains a new file or directory name that needs
    to be added to its parent directory, we end up updating the mtime and the
    ctime of the parent directory to the current time after we have set their
    values to the correct ones (set at fsync time), efectivelly losing them.
    
    Sample reproducer:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount /dev/sdb /mnt
    
      $ mkdir /mnt/dir
      $ touch /mnt/dir/file
    
      # fsync of the directory is optional, not needed
      $ xfs_io -c fsync /mnt/dir
      $ xfs_io -c fsync /mnt/dir/file
    
      $ stat -c %Y /mnt/dir
      1557856079
    
      <power failure>
    
      $ sleep 3
      $ mount /dev/sdb /mnt
      $ stat -c %Y /mnt/dir
      1557856082
    
        --> should have been 1557856079, the mtime is updated to the current
            time when replaying the log
    
    Fix this by not updating the mtime and ctime to the current time at
    btrfs_add_link() when we are replaying a log tree.
    
    This could be triggered by my recent fsync fuzz tester for fstests, for
    which an fstests patch exists titled "fstests: generic, fsync fuzz tester
    with fsstress".
    
    Fixes: e02119d5a7b43 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da32e0303d5fc633575c93e12b292a9b9b58b19f
Author: Tomas Bortoli <tomasbortoli@gmail.com>
Date:   Tue May 28 17:43:38 2019 +0200

    tracing: Avoid memory leak in predicate_parse()
    
    commit dfb4a6f2191a80c8b790117d0ff592fd712d3296 upstream.
    
    In case of errors, predicate_parse() goes to the out_free label
    to free memory and to return an error code.
    
    However, predicate_parse() does not free the predicates of the
    temporary prog_stack array, thence leaking them.
    
    Link: http://lkml.kernel.org/r/20190528154338.29976-1-tomasbortoli@gmail.com
    
    Cc: stable@vger.kernel.org
    Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster")
    Reported-by: syzbot+6b8e0fb820e570c59e19@syzkaller.appspotmail.com
    Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
    [ Added protection around freeing prog_stack[i].pred ]
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9756c7e0cdc79d6a193dad06804d6803e1e5e380
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 23 15:23:46 2019 +0200

    scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs)
    
    commit ef4021fe5fd77ced0323cede27979d80a56211ca upstream.
    
    When the user tries to remove a zfcp port via sysfs, we only rejected it if
    there are zfcp unit children under the port. With purely automatically
    scanned LUNs there are no zfcp units but only SCSI devices. In such cases,
    the port_remove erroneously continued. We close the port and this
    implicitly closes all LUNs under the port. The SCSI devices survive with
    their private zfcp_scsi_dev still holding a reference to the "removed"
    zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn
    in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport
    stays blocked. Once (auto) port scan brings back the removed port, we
    unblock its fc_rport again by design.  However, there is no mechanism that
    would recover (open) the LUNs under the port (no "ersfs_3" without
    zfcp_unit [zfcp_erp_strategy_followup_success]).  Any pending or new I/O to
    such LUN leads to repeated:
    
      Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK
    
    See also v4.10 commit 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race
    with LUN recovery"). Even a manual LUN recovery
    (echo 0 > /sys/bus/scsi/devices/H:C:T:L/zfcp_failed)
    does not help, as the LUN links to the old "removed" port which remains
    to lack ZFCP_STATUS_COMMON_RUNNING [zfcp_erp_required_act].
    The only workaround is to first ensure that the fc_rport is blocked
    (e.g. port_remove again in case it was re-discovered by (auto) port scan),
    then delete the SCSI devices, and finally re-discover by (auto) port scan.
    The port scan includes an fc_rport unblock, which in turn triggers
    a new scan on the scsi target to freshly get new pure auto scan LUNs.
    
    Fix this by rejecting port_remove also if there are SCSI devices
    (even without any zfcp_unit) under this port. Re-use mechanics from v3.7
    commit d99b601b6338 ("[SCSI] zfcp: restore refcount check on port_remove").
    However, we have to give up zfcp_sysfs_port_units_mutex earlier in unit_add
    to prevent a deadlock with scsi_host scan taking shost->scan_mutex first
    and then zfcp_sysfs_port_units_mutex now in our zfcp_scsi_slave_alloc().
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: b62a8d9b45b9 ("[SCSI] zfcp: Use SCSI device data zfcp scsi dev instead of zfcp unit")
    Fixes: f8210e34887e ("[SCSI] zfcp: Allow midlayer to scan for LUNs when running in NPIV mode")
    Cc: <stable@vger.kernel.org> #2.6.37+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8bd0dffe816c6226a30df35c3abf7c8ba1feede
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 23 15:23:45 2019 +0200

    scsi: zfcp: fix missing zfcp_port reference put on -EBUSY from port_remove
    
    commit d27e5e07f9c49bf2a6a4ef254ce531c1b4fb5a38 upstream.
    
    With this early return due to zfcp_unit child(ren), we don't use the
    zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and
    need to put it.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: d99b601b6338 ("[SCSI] zfcp: restore refcount check on port_remove")
    Cc: <stable@vger.kernel.org> #3.7+
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c18a0ecc411a48e79cc95c2617efc5adbbeebbc2
Author: Piotr Figiel <p.figiel@camlintechnologies.com>
Date:   Mon Mar 4 15:42:52 2019 +0000

    brcmfmac: fix NULL pointer derefence during USB disconnect
    
    commit 5cdb0ef6144f47440850553579aa923c20a63f23 upstream.
    
    In case USB disconnect happens at the moment transmitting workqueue is in
    progress the underlying interface may be gone causing a NULL pointer
    dereference. Add synchronization of the workqueue destruction with the
    detach implementation in core so that the transmitting workqueue is stopped
    during detach before the interfaces are removed.
    
    Fix following Oops:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000008
    pgd = 9e6a802d
    [00000008] *pgd=00000000
    Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle
    xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
    iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether
    usb_serial_simple usbserial cdc_acm brcmfmac brcmutil smsc95xx usbnet
    ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base
    libcomposite configfs udc_core
    CPU: 0 PID: 7 Comm: kworker/u8:0 Not tainted 4.19.23-00076-g03740aa-dirty #102
    Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    Workqueue: brcmf_fws_wq brcmf_fws_dequeue_worker [brcmfmac]
    PC is at brcmf_txfinalize+0x34/0x90 [brcmfmac]
    LR is at brcmf_fws_dequeue_worker+0x218/0x33c [brcmfmac]
    pc : [<7f0dee64>]    lr : [<7f0e4140>]    psr: 60010093
    sp : ee8abef0  ip : 00000000  fp : edf38000
    r10: ffffffed  r9 : edf38970  r8 : edf38004
    r7 : edf3e970  r6 : 00000000  r5 : ede69000  r4 : 00000000
    r3 : 00000a97  r2 : 00000000  r1 : 0000888e  r0 : ede69000
    Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
    Control: 10c5387d  Table: 7d03c04a  DAC: 00000051
    Process kworker/u8:0 (pid: 7, stack limit = 0x24ec3e04)
    Stack: (0xee8abef0 to 0xee8ac000)
    bee0:                                     ede69000 00000000 ed56c3e0 7f0e4140
    bf00: 00000001 00000000 edf38004 edf3e99c ed56c3e0 80d03d00 edfea43a edf3e970
    bf20: ee809880 ee804200 ee971100 00000000 edf3e974 00000000 ee804200 80135a70
    bf40: 80d03d00 ee804218 ee809880 ee809894 ee804200 80d03d00 ee804218 ee8aa000
    bf60: 00000088 80135d5c 00000000 ee829f00 ee829dc0 00000000 ee809880 80135d30
    bf80: ee829f1c ee873eac 00000000 8013b1a0 ee829dc0 8013b07c 00000000 00000000
    bfa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000
    bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
    [<7f0dee64>] (brcmf_txfinalize [brcmfmac]) from [<7f0e4140>] (brcmf_fws_dequeue_worker+0x218/0x33c [brcmfmac])
    [<7f0e4140>] (brcmf_fws_dequeue_worker [brcmfmac]) from [<80135a70>] (process_one_work+0x138/0x3f8)
    [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554)
    [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154)
    [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
    Exception stack(0xee8abfb0 to 0xee8abff8)
    bfa0:                                     00000000 00000000 00000000 00000000
    bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
    Code: e1530001 0a000007 e3560000 e1a00005 (05942008)
    ---[ end trace 079239dd31c86e90 ]---
    
    Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f64751af1902ee86e7443782704c75b5e822afe
Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Date:   Fri May 24 10:59:43 2019 -0400

    media: smsusb: better handle optional alignment
    
    commit a47686636d84eaec5c9c6e84bd5f96bed34d526d upstream.
    
    Most Siano devices require an alignment for the response.
    
    Changeset f3be52b0056a ("media: usb: siano: Fix general protection fault in smsusb")
    changed the logic with gets such aligment, but it now produces a
    sparce warning:
    
    drivers/media/usb/siano/smsusb.c: In function 'smsusb_init_device':
    drivers/media/usb/siano/smsusb.c:447:37: warning: 'in_maxp' may be used uninitialized in this function [-Wmaybe-uninitialized]
      447 |   dev->response_alignment = in_maxp - sizeof(struct sms_msg_hdr);
          |                             ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The sparse message itself is bogus, but a broken (or fake) USB
    eeprom could produce a negative value for response_alignment.
    
    So, change the code in order to check if the result is not
    negative.
    
    Fixes: 31e0456de5be ("media: usb: siano: Fix general protection fault in smsusb")
    CC: <stable@vger.kernel.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6df98cafc9cf62f1f05c323a807c7e111bd0a30
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 21 11:38:07 2019 -0400

    media: usb: siano: Fix false-positive "uninitialized variable" warning
    
    commit 45457c01171fd1488a7000d1751c06ed8560ee38 upstream.
    
    GCC complains about an apparently uninitialized variable recently
    added to smsusb_init_device().  It's a false positive, but to silence
    the warning this patch adds a trivial initialization.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: kbuild test robot <lkp@intel.com>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35b1044566528b26d48b31a52069f45851d49885
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 7 12:39:47 2019 -0400

    media: usb: siano: Fix general protection fault in smsusb
    
    commit 31e0456de5be379b10fea0fa94a681057114a96e upstream.
    
    The syzkaller USB fuzzer found a general-protection-fault bug in the
    smsusb part of the Siano DVB driver.  The fault occurs during probe
    because the driver assumes without checking that the device has both
    IN and OUT endpoints and the IN endpoint is ep1.
    
    By slightly rearranging the driver's initialization code, we can make
    the appropriate checks early on and thus avoid the problem.  If the
    expected endpoints aren't present, the new code safely returns -ENODEV
    from the probe routine.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+53f029db71c19a47325a@syzkaller.appspotmail.com
    CC: <stable@vger.kernel.org>
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4c1b4a61f78f2f743ccd42244a21add70c6c702
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu May 9 11:30:59 2019 +0200

    USB: rio500: fix memory leak in close after disconnect
    
    commit e0feb73428b69322dd5caae90b0207de369b5575 upstream.
    
    If a disconnected device is closed, rio_close() must free
    the buffers.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2d93077bac37c6895d8c58f564699a3a897c5db
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu May 9 11:30:58 2019 +0200

    USB: rio500: refuse more than one device at a time
    
    commit 3864d33943b4a76c6e64616280e98d2410b1190f upstream.
    
    This driver is using a global variable. It cannot handle more than
    one device at a time. The issue has been existing since the dawn
    of the driver.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reported-by: syzbot+35f04d136fc975a70da4@syzkaller.appspotmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8c1703932bc476609d96f86ea85e46351b66fb9
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Thu May 16 17:08:31 2019 +0200

    USB: Add LPM quirk for Surface Dock GigE adapter
    
    commit ea261113385ac0a71c2838185f39e8452d54b152 upstream.
    
    Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will
    complain with
    
        r8152 <device...>: Stop submitting intr, status -71
    
    Adding the quirk resolves this. As the dock is externally powered, this
    should not have any drawbacks.
    
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d27ea5e9eb4ac45e0e4cf8250a45aa06b0944787
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu May 9 14:41:50 2019 +0200

    USB: sisusbvga: fix oops in error path of sisusb_probe
    
    commit 9a5729f68d3a82786aea110b1bfe610be318f80a upstream.
    
    The pointer used to log a failure of usb_register_dev() must
    be set before the error is logged.
    
    v2: fix that minor is not available before registration
    
    Signed-off-by: oliver Neukum <oneukum@suse.com>
    Reported-by: syzbot+a0cbdbd6d169020c8959@syzkaller.appspotmail.com
    Fixes: 7b5cd5fefbe02 ("USB: SisUSB2VGA: Convert printk to dev_* macros")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a43bb9e83155e0dbf057f8818335cfceae5b075e
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon May 13 13:14:29 2019 -0400

    USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor
    
    commit a03ff54460817c76105f81f3aa8ef655759ccc9a upstream.
    
    The syzkaller USB fuzzer found a slab-out-of-bounds write bug in the
    USB core, caused by a failure to check the actual size of a BOS
    descriptor.  This patch adds a check to make sure the descriptor is at
    least as large as it is supposed to be, so that the code doesn't
    inadvertently access memory beyond the end of the allocated region
    when assigning to dev->bos->desc->bNumDeviceCaps later on.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+71f1e64501a309fcc012@syzkaller.appspotmail.com
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fc485b0008e5aa7e62bed4e61aa240808f95aed
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Wed May 29 13:46:15 2019 -0600

    usbip: usbip_host: fix stub_dev lock context imbalance regression
    
    commit 3ea3091f1bd8586125848c62be295910e9802af0 upstream.
    
    Fix the following sparse context imbalance regression introduced in
    a patch that fixed sleeping function called from invalid context bug.
    
    kbuild test robot reported on:
    
    tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git  usb-linus
    
    Regressions in current branch:
    
    drivers/usb/usbip/stub_dev.c:399:9: sparse: sparse: context imbalance in 'stub_probe' - different lock contexts for basic block
    drivers/usb/usbip/stub_dev.c:418:13: sparse: sparse: context imbalance in 'stub_disconnect' - different lock contexts for basic block
    drivers/usb/usbip/stub_dev.c:464:1-10: second lock on line 476
    
    Error ids grouped by kconfigs:
    
    recent_errors
    ├── i386-allmodconfig
    │   └── drivers-usb-usbip-stub_dev.c:second-lock-on-line
    ├── x86_64-allmodconfig
    │   ├── drivers-usb-usbip-stub_dev.c:sparse:sparse:context-imbalance-in-stub_disconnect-different-lock-contexts-for-basic-block
    │   └── drivers-usb-usbip-stub_dev.c:sparse:sparse:context-imbalance-in-stub_probe-different-lock-contexts-for-basic-block
    └── x86_64-allyesconfig
        └── drivers-usb-usbip-stub_dev.c:second-lock-on-line
    
    This is a real problem in an error leg where spin_lock() is called on an
    already held lock.
    
    Fix the imbalance in stub_probe() and stub_disconnect().
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Fixes: 0c9e8b3cad65 ("usbip: usbip_host: fix BUG: sleeping function called from invalid context")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3724d69b73272f0be34485ac122d938e6aa8c0a
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Thu May 2 13:47:02 2019 -0600

    usbip: usbip_host: fix BUG: sleeping function called from invalid context
    
    commit 0c9e8b3cad654bfc499c10b652fbf8f0b890af8f upstream.
    
    stub_probe() and stub_disconnect() call functions which could call
    sleeping function in invalid context whil holding busid_lock.
    
    Fix the problem by refining the lock holds to short critical sections
    to change the busid_priv fields. This fix restructures the code to
    limit the lock holds in stub_probe() and stub_disconnect().
    
    stub_probe():
    
    [15217.927028] BUG: sleeping function called from invalid context at mm/slab.h:418
    [15217.927038] in_atomic(): 1, irqs_disabled(): 0, pid: 29087, name: usbip
    [15217.927044] 5 locks held by usbip/29087:
    [15217.927047]  #0: 0000000091647f28 (sb_writers#6){....}, at: vfs_write+0x191/0x1c0
    [15217.927062]  #1: 000000008f9ba75b (&of->mutex){....}, at: kernfs_fop_write+0xf7/0x1b0
    [15217.927072]  #2: 00000000872e5b4b (&dev->mutex){....}, at: __device_driver_lock+0x3b/0x50
    [15217.927082]  #3: 00000000e74ececc (&dev->mutex){....}, at: __device_driver_lock+0x46/0x50
    [15217.927090]  #4: 00000000b20abbe0 (&(&busid_table[i].busid_lock)->rlock){....}, at: get_busid_priv+0x48/0x60 [usbip_host]
    [15217.927103] CPU: 3 PID: 29087 Comm: usbip Tainted: G        W         5.1.0-rc6+ #40
    [15217.927106] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013
    [15217.927109] Call Trace:
    [15217.927118]  dump_stack+0x63/0x85
    [15217.927127]  ___might_sleep+0xff/0x120
    [15217.927133]  __might_sleep+0x4a/0x80
    [15217.927143]  kmem_cache_alloc_trace+0x1aa/0x210
    [15217.927156]  stub_probe+0xe8/0x440 [usbip_host]
    [15217.927171]  usb_probe_device+0x34/0x70
    
    stub_disconnect():
    
    [15279.182478] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
    [15279.182487] in_atomic(): 1, irqs_disabled(): 0, pid: 29114, name: usbip
    [15279.182492] 5 locks held by usbip/29114:
    [15279.182494]  #0: 0000000091647f28 (sb_writers#6){....}, at: vfs_write+0x191/0x1c0
    [15279.182506]  #1: 00000000702cf0f3 (&of->mutex){....}, at: kernfs_fop_write+0xf7/0x1b0
    [15279.182514]  #2: 00000000872e5b4b (&dev->mutex){....}, at: __device_driver_lock+0x3b/0x50
    [15279.182522]  #3: 00000000e74ececc (&dev->mutex){....}, at: __device_driver_lock+0x46/0x50
    [15279.182529]  #4: 00000000b20abbe0 (&(&busid_table[i].busid_lock)->rlock){....}, at: get_busid_priv+0x48/0x60 [usbip_host]
    [15279.182541] CPU: 0 PID: 29114 Comm: usbip Tainted: G        W         5.1.0-rc6+ #40
    [15279.182543] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013
    [15279.182546] Call Trace:
    [15279.182554]  dump_stack+0x63/0x85
    [15279.182561]  ___might_sleep+0xff/0x120
    [15279.182566]  __might_sleep+0x4a/0x80
    [15279.182574]  __mutex_lock+0x55/0x950
    [15279.182582]  ? get_busid_priv+0x48/0x60 [usbip_host]
    [15279.182587]  ? reacquire_held_locks+0xec/0x1a0
    [15279.182591]  ? get_busid_priv+0x48/0x60 [usbip_host]
    [15279.182597]  ? find_held_lock+0x94/0xa0
    [15279.182609]  mutex_lock_nested+0x1b/0x20
    [15279.182614]  ? mutex_lock_nested+0x1b/0x20
    [15279.182618]  kernfs_remove_by_name_ns+0x2a/0x90
    [15279.182625]  sysfs_remove_file_ns+0x15/0x20
    [15279.182629]  device_remove_file+0x19/0x20
    [15279.182634]  stub_disconnect+0x6d/0x180 [usbip_host]
    [15279.182643]  usb_unbind_device+0x27/0x60
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9690202da222d2a93f256581e2ce3977fd6b9524
Author: Carsten Schmid <carsten_schmid@mentor.com>
Date:   Wed May 22 14:33:59 2019 +0300

    usb: xhci: avoid null pointer deref when bos field is NULL
    
    commit 7aa1bb2ffd84d6b9b5f546b079bb15cd0ab6e76e upstream.
    
    With defective USB sticks we see the following error happen:
    usb 1-3: new high-speed USB device number 6 using xhci_hcd
    usb 1-3: device descriptor read/64, error -71
    usb 1-3: device descriptor read/64, error -71
    usb 1-3: new high-speed USB device number 7 using xhci_hcd
    usb 1-3: device descriptor read/64, error -71
    usb 1-3: unable to get BOS descriptor set
    usb 1-3: New USB device found, idVendor=0781, idProduct=5581
    usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    ...
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    
    This comes from the following place:
    [ 1660.215380] IP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
    [ 1660.222092] PGD 0 P4D 0
    [ 1660.224918] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [ 1660.425520] CPU: 1 PID: 38 Comm: kworker/1:1 Tainted: P     U  W  O    4.14.67-apl #1
    [ 1660.434277] Workqueue: usb_hub_wq hub_event [usbcore]
    [ 1660.439918] task: ffffa295b6ae4c80 task.stack: ffffad4580150000
    [ 1660.446532] RIP: 0010:xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
    [ 1660.453821] RSP: 0018:ffffad4580153c70 EFLAGS: 00010046
    [ 1660.459655] RAX: 0000000000000000 RBX: ffffa295b4d7c000 RCX: 0000000000000002
    [ 1660.467625] RDX: 0000000000000002 RSI: ffffffff984a55b2 RDI: ffffffff984a55b2
    [ 1660.475586] RBP: ffffad4580153cc8 R08: 0000000000d6520a R09: 0000000000000001
    [ 1660.483556] R10: ffffad4580a004a0 R11: 0000000000000286 R12: ffffa295b4d7c000
    [ 1660.491525] R13: 0000000000010648 R14: ffffa295a84e1800 R15: 0000000000000000
    [ 1660.499494] FS:  0000000000000000(0000) GS:ffffa295bfc80000(0000) knlGS:0000000000000000
    [ 1660.508530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1660.514947] CR2: 0000000000000008 CR3: 000000025a114000 CR4: 00000000003406a0
    [ 1660.522917] Call Trace:
    [ 1660.525657]  usb_set_usb2_hardware_lpm+0x3d/0x70 [usbcore]
    [ 1660.531792]  usb_disable_device+0x242/0x260 [usbcore]
    [ 1660.537439]  usb_disconnect+0xc1/0x2b0 [usbcore]
    [ 1660.542600]  hub_event+0x596/0x18f0 [usbcore]
    [ 1660.547467]  ? trace_preempt_on+0xdf/0x100
    [ 1660.552040]  ? process_one_work+0x1c1/0x410
    [ 1660.556708]  process_one_work+0x1d2/0x410
    [ 1660.561184]  ? preempt_count_add.part.3+0x21/0x60
    [ 1660.566436]  worker_thread+0x2d/0x3f0
    [ 1660.570522]  kthread+0x122/0x140
    [ 1660.574123]  ? process_one_work+0x410/0x410
    [ 1660.578792]  ? kthread_create_on_node+0x60/0x60
    [ 1660.583849]  ret_from_fork+0x3a/0x50
    [ 1660.587839] Code: 00 49 89 c3 49 8b 84 24 50 16 00 00 8d 4a ff 48 8d 04 c8 48 89 ca 4c 8b 10 45 8b 6a 04 48 8b 00 48 89 45 c0 49 8b 86 80 03 00 00 <48> 8b 40 08 8b 40 03 0f 1f 44 00 00 45 85 ff 0f 84 81 01 00 00
    [ 1660.608980] RIP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] RSP: ffffad4580153c70
    [ 1660.617921] CR2: 0000000000000008
    
    Tracking this down shows that udev->bos is NULL in the following code:
    (xhci.c, in xhci_set_usb2_hardware_lpm)
            field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);  <<<<<<< here
    
            xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
                            enable ? "enable" : "disable", port_num + 1);
    
            if (enable) {
                    /* Host supports BESL timeout instead of HIRD */
                    if (udev->usb2_hw_lpm_besl_capable) {
                            /* if device doesn't have a preferred BESL value use a
                             * default one which works with mixed HIRD and BESL
                             * systems. See XHCI_DEFAULT_BESL definition in xhci.h
                             */
                            if ((field & USB_BESL_SUPPORT) &&
                                (field & USB_BESL_BASELINE_VALID))
                                    hird = USB_GET_BESL_BASELINE(field);
                            else
                                    hird = udev->l1_params.besl;
    
    The failing case is when disabling LPM. So it is sufficient to avoid
    access to udev->bos by moving the instruction into the "enable" clause.
    
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Carsten Schmid <carsten_schmid@mentor.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e30ba04a20a26a0f2e2e92088c9bf395660a961
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Wed May 22 14:34:01 2019 +0300

    xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()
    
    commit f7fac17ca925faa03fc5eb854c081a24075f8bad upstream.
    
    Xhci_handshake() implements the algorithm already captured by
    readl_poll_timeout_atomic(). Convert the former to use the latter to
    avoid repetition.
    
    Turned out this patch also fixes a bug on the AMD Stoneyridge platform
    where usleep(1) sometimes takes over 10ms.
    This means a 5 second timeout can easily take over 15 seconds which will
    trigger the watchdog and reboot the system.
    
    [Add info about patch fixing a bug to commit message -Mathias]
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Tested-by: Raul E Rangel <rrangel@chromium.org>
    Reviewed-by: Raul E Rangel <rrangel@chromium.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32adfa3d92e7e910897f236ace9afacabb398cca
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed May 22 10:35:29 2019 -0300

    xhci: Use %zu for printing size_t type
    
    commit c1a145a3ed9a40f3b6145feb97789e8eb49c5566 upstream.
    
    Commit 597c56e372da ("xhci: update bounce buffer with correct sg num")
    caused the following build warnings:
    
    drivers/usb/host/xhci-ring.c:676:19: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
    
    Use %zu for printing size_t type in order to fix the warnings.
    
    Fixes: 597c56e372da ("xhci: update bounce buffer with correct sg num")
    Reported-by: kbuild test robot <lkp@intel.com>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eebcff780603a67c6f52e28b3123d66cc9be4f60
Author: Henry Lin <henryl@nvidia.com>
Date:   Wed May 22 14:33:57 2019 +0300

    xhci: update bounce buffer with correct sg num
    
    commit 597c56e372dab2c7f79b8d700aad3a5deebf9d1b upstream.
    
    This change fixes a data corruption issue occurred on USB hard disk for
    the case that bounce buffer is used during transferring data.
    
    While updating data between sg list and bounce buffer, current
    implementation passes mapped sg number (urb->num_mapped_sgs) to
    sg_pcopy_from_buffer() and sg_pcopy_to_buffer(). This causes data
    not get copied if target buffer is located in the elements after
    mapped sg elements. This change passes sg number for full list to
    fix issue.
    
    Besides, for copying data from bounce buffer, calling dma_unmap_single()
    on the bounce buffer before copying data to sg list can avoid cache issue.
    
    Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
    Cc: <stable@vger.kernel.org> # v4.8+
    Signed-off-by: Henry Lin <henryl@nvidia.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 759766bf2aec0d10ea543135e8d85caadeca69a1
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue May 14 15:43:27 2019 -0700

    include/linux/bitops.h: sanitize rotate primitives
    
    commit ef4d6f6b275c498f8e5626c99dbeefdc5027f843 upstream.
    
    The ror32 implementation (word >> shift) | (word << (32 - shift) has
    undefined behaviour if shift is outside the [1, 31] range.  Similarly
    for the 64 bit variants.  Most callers pass a compile-time constant
    (naturally in that range), but there's an UBSAN report that these may
    actually be called with a shift count of 0.
    
    Instead of special-casing that, we can make them DTRT for all values of
    shift while also avoiding UB.  For some reason, this was already partly
    done for rol32 (which was well-defined for [0, 31]).  gcc 8 recognizes
    these patterns as rotates, so for example
    
      __u32 rol32(__u32 word, unsigned int shift)
      {
            return (word << (shift & 31)) | (word >> ((-shift) & 31));
      }
    
    compiles to
    
    0000000000000020 <rol32>:
      20:   89 f8                   mov    %edi,%eax
      22:   89 f1                   mov    %esi,%ecx
      24:   d3 c0                   rol    %cl,%eax
      26:   c3                      retq
    
    Older compilers unfortunately do not do as well, but this only affects
    the small minority of users that don't pass constants.
    
    Due to integer promotions, ro[lr]8 were already well-defined for shifts
    in [0, 8], and ro[lr]16 were mostly well-defined for shifts in [0, 16]
    (only mostly - u16 gets promoted to _signed_ int, so if bit 15 is set,
    word << 16 is undefined).  For consistency, update those as well.
    
    Link: http://lkml.kernel.org/r/20190410211906.2190-1-linux@rasmusvillemoes.dk
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Reported-by: Ido Schimmel <idosch@mellanox.com>
    Tested-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Cc: Vadim Pasternak <vadimp@mellanox.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
    Cc: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89156c1005d249e803cc6d39158f1ca4050073fb
Author: James Clarke <jrtc27@jrtc27.com>
Date:   Wed May 29 22:31:31 2019 +0100

    sparc64: Fix regression in non-hypervisor TLB flush xcall
    
    commit d3c976c14ad8af421134c428b0a89ff8dd3bd8f8 upstream.
    
    Previously, %g2 would end up with the value PAGE_SIZE, but after the
    commit mentioned below it ends up with the value 1 due to being reused
    for a different purpose. We need it to be PAGE_SIZE as we use it to step
    through pages in our demap loop, otherwise we set different flags in the
    low 12 bits of the address written to, thereby doing things other than a
    nucleus page flush.
    
    Fixes: a74ad5e660a9 ("sparc64: Handle extremely large kernel TLB range flushes more gracefully.")
    Reported-by: Meelis Roos <mroos@linux.ee>
    Tested-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: James Clarke <jrtc27@jrtc27.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>