commit b19ffe6e7205c0b0d26b750673873f3f9f61da35
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 6 19:05:30 2019 +0200

    Linux 4.14.137

commit d4187064959c0df9f3e610de02cb3b822c64b88d
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Sat Aug 3 21:21:54 2019 +0200

    Documentation: Add swapgs description to the Spectre v1 documentation
    
    commit 4c92057661a3412f547ede95715641d7ee16ddac upstream
    
    Add documentation to the Spectre document about the new swapgs variant of
    Spectre v1.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4e6262bde5024b3ce1567e09f6556ffc90ceec0
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jul 17 21:18:59 2019 +0200

    x86/speculation/swapgs: Exclude ATOMs from speculation through SWAPGS
    
    commit f36cf386e3fec258a341d446915862eded3e13d8 upstream
    
    Intel provided the following information:
    
     On all current Atom processors, instructions that use a segment register
     value (e.g. a load or store) will not speculatively execute before the
     last writer of that segment retires. Thus they will not use a
     speculatively written segment value.
    
    That means on ATOMs there is no speculation through SWAPGS, so the SWAPGS
    entry paths can be excluded from the extra LFENCE if PTI is disabled.
    
    Create a separate bug flag for the through SWAPGS speculation and mark all
    out-of-order ATOMs and AMD/HYGON CPUs as not affected. The in-order ATOMs
    are excluded from the whole mitigation mess anyway.
    
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee524c14856d2eab5d3d2202c12c06d2e7190c2a
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Mon Jul 8 11:52:26 2019 -0500

    x86/speculation: Enable Spectre v1 swapgs mitigations
    
    commit a2059825986a1c8143fd6698774fa9d83733bb11 upstream
    
    The previous commit added macro calls in the entry code which mitigate the
    Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
    enabled.  Enable those features where applicable.
    
    The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
    
    There are different features which can affect the risk of attack:
    
    - When FSGSBASE is enabled, unprivileged users are able to place any
      value in GS, using the wrgsbase instruction.  This means they can
      write a GS value which points to any value in kernel space, which can
      be useful with the following gadget in an interrupt/exception/NMI
      handler:
    
            if (coming from user space)
                    swapgs
            mov %gs:<percpu_offset>, %reg1
            // dependent load or store based on the value of %reg
            // for example: mov %(reg1), %reg2
    
      If an interrupt is coming from user space, and the entry code
      speculatively skips the swapgs (due to user branch mistraining), it
      may speculatively execute the GS-based load and a subsequent dependent
      load or store, exposing the kernel data to an L1 side channel leak.
    
      Note that, on Intel, a similar attack exists in the above gadget when
      coming from kernel space, if the swapgs gets speculatively executed to
      switch back to the user GS.  On AMD, this variant isn't possible
      because swapgs is serializing with respect to future GS-based
      accesses.
    
      NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
            doesn't exist quite yet.
    
    - When FSGSBASE is disabled, the issue is mitigated somewhat because
      unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
      restricts GS values to user space addresses only.  That means the
      gadget would need an additional step, since the target kernel address
      needs to be read from user space first.  Something like:
    
            if (coming from user space)
                    swapgs
            mov %gs:<percpu_offset>, %reg1
            mov (%reg1), %reg2
            // dependent load or store based on the value of %reg2
            // for example: mov %(reg2), %reg3
    
      It's difficult to audit for this gadget in all the handlers, so while
      there are no known instances of it, it's entirely possible that it
      exists somewhere (or could be introduced in the future).  Without
      tooling to analyze all such code paths, consider it vulnerable.
    
      Effects of SMAP on the !FSGSBASE case:
    
      - If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
        susceptible to Meltdown), the kernel is prevented from speculatively
        reading user space memory, even L1 cached values.  This effectively
        disables the !FSGSBASE attack vector.
    
      - If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
        still prevents the kernel from speculatively reading user space
        memory.  But it does *not* prevent the kernel from reading the
        user value from L1, if it has already been cached.  This is probably
        only a small hurdle for an attacker to overcome.
    
    Thanks to Dave Hansen for contributing the speculative_smap() function.
    
    Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
    is serializing on AMD.
    
    [ tglx: Fixed the USER fence decision and polished the comment as suggested
            by Dave Hansen ]
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Dave Hansen <dave.hansen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83e6e48e70a133a5ea6167bf152ce2b274008b3d
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Mon Jul 8 11:52:25 2019 -0500

    x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations
    
    commit 18ec54fdd6d18d92025af097cd042a75cf0ea24c upstream
    
    Spectre v1 isn't only about array bounds checks.  It can affect any
    conditional checks.  The kernel entry code interrupt, exception, and NMI
    handlers all have conditional swapgs checks.  Those may be problematic in
    the context of Spectre v1, as kernel code can speculatively run with a user
    GS.
    
    For example:
    
            if (coming from user space)
                    swapgs
            mov %gs:<percpu_offset>, %reg
            mov (%reg), %reg1
    
    When coming from user space, the CPU can speculatively skip the swapgs, and
    then do a speculative percpu load using the user GS value.  So the user can
    speculatively force a read of any kernel value.  If a gadget exists which
    uses the percpu value as an address in another load/store, then the
    contents of the kernel value may become visible via an L1 side channel
    attack.
    
    A similar attack exists when coming from kernel space.  The CPU can
    speculatively do the swapgs, causing the user GS to get used for the rest
    of the speculative window.
    
    The mitigation is similar to a traditional Spectre v1 mitigation, except:
    
      a) index masking isn't possible; because the index (percpu offset)
         isn't user-controlled; and
    
      b) an lfence is needed in both the "from user" swapgs path and the
         "from kernel" non-swapgs path (because of the two attacks described
         above).
    
    The user entry swapgs paths already have SWITCH_TO_KERNEL_CR3, which has a
    CR3 write when PTI is enabled.  Since CR3 writes are serializing, the
    lfences can be skipped in those cases.
    
    On the other hand, the kernel entry swapgs paths don't depend on PTI.
    
    To avoid unnecessary lfences for the user entry case, create two separate
    features for alternative patching:
    
      X86_FEATURE_FENCE_SWAPGS_USER
      X86_FEATURE_FENCE_SWAPGS_KERNEL
    
    Use these features in entry code to patch in lfences where needed.
    
    The features aren't enabled yet, so there's no functional change.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Dave Hansen <dave.hansen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d63c2a99657cae5c0dc2907f90c8911a50f24d57
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Wed Jun 19 18:51:09 2019 +0200

    x86/cpufeatures: Combine word 11 and 12 into a new scattered features word
    
    commit acec0ce081de0c36459eea91647faf99296445a3 upstream
    
    It's a waste for the four X86_FEATURE_CQM_* feature bits to occupy two
    whole feature bits words. To better utilize feature words, re-define
    word 11 to host scattered features and move the four X86_FEATURE_CQM_*
    features into Linux defined word 11. More scattered features can be
    added in word 11 in the future.
    
    Rename leaf 11 in cpuid_leafs to CPUID_LNX_4 to reflect it's a
    Linux-defined leaf.
    
    Rename leaf 12 as CPUID_DUMMY which will be replaced by a meaningful
    name in the next patch when CPUID.7.1:EAX occupies world 12.
    
    Maximum number of RMID and cache occupancy scale are retrieved from
    CPUID.0xf.1 after scattered CQM features are enumerated. Carve out the
    code into a separate function.
    
    KVM doesn't support resctrl now. So it's safe to move the
    X86_FEATURE_CQM_* features to scattered features word 11 for KVM.
    
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Aaron Lewis <aaronlewis@google.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Babu Moger <babu.moger@amd.com>
    Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
    Cc: "Sean J Christopherson" <sean.j.christopherson@intel.com>
    Cc: Frederic Weisbecker <frederic@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: kvm ML <kvm@vger.kernel.org>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Nadav Amit <namit@vmware.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
    Cc: Peter Feiner <pfeiner@google.com>
    Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Cc: "Radim Krčmář" <rkrcmar@redhat.com>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Ravi V Shankar <ravi.v.shankar@intel.com>
    Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
    Cc: x86 <x86@kernel.org>
    Link: https://lkml.kernel.org/r/1560794416-217638-2-git-send-email-fenghua.yu@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 091c0268c2f153ed994fbd2e1bacf65766e02dd4
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Jun 19 17:24:34 2019 +0200

    x86/cpufeatures: Carve out CQM features retrieval
    
    commit 45fc56e629caa451467e7664fbd4c797c434a6c4 upstream
    
    ... into a separate function for better readability. Split out from a
    patch from Fenghua Yu <fenghua.yu@intel.com> to keep the mechanical,
    sole code movement separate for easy review.
    
    No functional changes.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: x86@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

commit f73e82454497200f2b1b60aeea47db81d53e5cbf
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 1 11:20:53 2019 -0700

    gcc-9: properly declare the {pv,hv}clock_page storage
    
    commit 459e3a21535ae3c7a9a123650e54f5c882b8fcbf upstream.
    
    The pvlock_page and hvclock_page variables are (as the name implies)
    addresses to pages, created by the linker script.
    
    But we declared them as just "extern u8" variables, which _works_, but
    now that gcc does some more bounds checking, it causes warnings like
    
        warning: array subscript 1 is outside array bounds of ‘u8[1]’
    
    when we then access more than one byte from those variables.
    
    Fix this by simply making the declaration of the variables match
    reality, which makes the compiler happy too.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a22c63764d09e7e0b22e110e407921daf35cdb8c
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Wed Oct 31 21:57:30 2018 -0500

    objtool: Support GCC 9 cold subfunction naming scheme
    
    commit bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6 upstream.
    
    Starting with GCC 8, a lot of unlikely code was moved out of line to
    "cold" subfunctions in .text.unlikely.
    
    For example, the unlikely bits of:
    
      irq_do_set_affinity()
    
    are moved out to the following subfunction:
    
      irq_do_set_affinity.cold.49()
    
    Starting with GCC 9, the numbered suffix has been removed.  So in the
    above example, the cold subfunction is instead:
    
      irq_do_set_affinity.cold()
    
    Tweak the objtool subfunction detection logic so that it detects both
    GCC 8 and GCC 9 naming schemes.
    
    Reported-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/015e9544b1f188d36a7f02fa31e9e95629aa5f50.1541040800.git.jpoimboe@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 321d6579dc7ba1170e1058c78a57461d4a65aacd
Author: Jean Delvare <jdelvare@suse.de>
Date:   Sun Jul 28 18:41:38 2019 +0200

    eeprom: at24: make spd world-readable again
    
    commit 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 upstream.
    
    The integration of the at24 driver into the nvmem framework broke the
    world-readability of spd EEPROMs. Fix it.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: stable@vger.kernel.org
    Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework")
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Bartosz Golaszewski <brgl@bgdev.pl>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    [Bartosz: backported the patch to older branches]
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ba28ec91434d777be6edf24d495773ad5ca7043
Author: John Fleck <john.fleck@intel.com>
Date:   Mon Jul 15 12:45:21 2019 -0400

    IB/hfi1: Check for error on call to alloc_rsm_map_table
    
    commit cd48a82087231fdba0e77521102386c6ed0168d6 upstream.
    
    The call to alloc_rsm_map_table does not check if the kmalloc fails.
    Check for a NULL on alloc, and bail if it fails.
    
    Fixes: 372cc85a13c9 ("IB/hfi1: Extract RSM map table init from QOS")
    Link: https://lore.kernel.org/r/20190715164521.74174.27047.stgit@awfm-01.aw.intel.com
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: John Fleck <john.fleck@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8bd04e32ff7469a849bdb858c7dc758febc5283
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Tue Jul 23 09:57:29 2019 +0300

    IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification
    
    commit b7165bd0d6cbb93732559be6ea8774653b204480 upstream.
    
    The specification for the Toeplitz function doesn't require to set the key
    explicitly to be symmetric. In case a symmetric functionality is required
    a symmetric key can be simply used.
    
    Wrongly forcing the algorithm to symmetric causes the wrong packet
    distribution and a performance degradation.
    
    Link: https://lore.kernel.org/r/20190723065733.4899-7-leon@kernel.org
    Cc: <stable@vger.kernel.org> # 4.7
    Fixes: 28d6137008b2 ("IB/mlx5: Add RSS QP support")
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Reviewed-by: Alex Vainman <alexv@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcfb397a7fc230a6c67bbb5e4c9b7d584e29e773
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Tue Jul 23 09:57:27 2019 +0300

    IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache
    
    commit 9ec4483a3f0f71a228a5933bc040441322bfb090 upstream.
    
    Fix unreg_umr to move the MR to a kernel owned PD (i.e. the UMR PD) which
    can't be accessed by userspace.
    
    This ensures that nothing can continue to access the MR once it has been
    placed in the kernels cache for reuse.
    
    MRs in the cache continue to have their HW state, including DMA tables,
    present. Even though the MR has been invalidated, changing the PD provides
    an additional layer of protection against use of the MR.
    
    Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
    Cc: <stable@vger.kernel.org> # 3.10
    Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d9a437e1c735349df47012c95a026ceab56a9f7
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Tue Jul 23 09:57:26 2019 +0300

    IB/mlx5: Use direct mkey destroy command upon UMR unreg failure
    
    commit afd1417404fba6dbfa6c0a8e5763bd348da682e4 upstream.
    
    Use a direct firmware command to destroy the mkey in case the unreg UMR
    operation has failed.
    
    This prevents a case that a mkey will leak out from the cache post a
    failure to be destroyed by a UMR WR.
    
    In case the MR cache limit didn't reach a call to add another entry to the
    cache instead of the destroyed one is issued.
    
    In addition, replaced a warn message to WARN_ON() as this flow is fatal
    and can't happen unless some bug around.
    
    Link: https://lore.kernel.org/r/20190723065733.4899-4-leon@kernel.org
    Cc: <stable@vger.kernel.org> # 4.10
    Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib")
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b68fe223f861e54f1bb3a30b104d96cc8ca4ccd
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Tue Jul 23 09:57:25 2019 +0300

    IB/mlx5: Fix unreg_umr to ignore the mkey state
    
    commit 6a053953739d23694474a5f9c81d1a30093da81a upstream.
    
    Fix unreg_umr to ignore the mkey state and do not fail if was freed.  This
    prevents a case that a user space application already changed the mkey
    state to free and then the UMR operation will fail leaving the mkey in an
    inappropriate state.
    
    Link: https://lore.kernel.org/r/20190723065733.4899-3-leon@kernel.org
    Cc: <stable@vger.kernel.org> # 3.19
    Fixes: 968e78dd9644 ("IB/mlx5: Enhance UMR support to allow partial page table update")
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40585ce205739e45116fb46bee50a8155e5f2069
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Jun 14 07:46:02 2019 +0200

    xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
    
    commit 50f6393f9654c561df4cdcf8e6cfba7260143601 upstream.
    
    The condition in xen_swiotlb_free_coherent() for deciding whether to
    call xen_destroy_contiguous_region() is wrong: in case the region to
    be freed is not contiguous calling xen_destroy_contiguous_region() is
    the wrong thing to do: it would result in inconsistent mappings of
    multiple PFNs to the same MFN. This will lead to various strange
    crashes or data corruption.
    
    Instead of calling xen_destroy_contiguous_region() in that case a
    warning should be issued as that situation should never occur.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3938eec04784bd5c300b65764b274ecf8212e58
Author: Munehisa Kamata <kamatam@amazon.com>
Date:   Wed Jul 31 20:13:10 2019 +0800

    nbd: replace kill_bdev() with __invalidate_device() again
    
    commit 2b5c8f0063e4b263cf2de82029798183cf85c320 upstream.
    
    Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()")
    once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere")
    resurrected kill_bdev() and it has been there since then. So buffer_head
    mappings still get killed on a server disconnection, and we can still
    hit the BUG_ON on a filesystem on the top of the nbd device.
    
      EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null)
      block nbd0: Receive control failed (result -32)
      block nbd0: shutting down sockets
      print_req_error: I/O error, dev nbd0, sector 66264 flags 3000
      EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block
      print_req_error: I/O error, dev nbd0, sector 2264 flags 3000
      EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block
      EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure
      ------------[ cut here ]------------
      kernel BUG at fs/buffer.c:3057!
      invalid opcode: 0000 [#1] SMP PTI
      CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4
      Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017
      RIP: 0010:submit_bh_wbc+0x18b/0x190
      ...
      Call Trace:
       jbd2_write_superblock+0xf1/0x230 [jbd2]
       ? account_entity_enqueue+0xc5/0xf0
       jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2]
       jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2]
       ? __switch_to_asm+0x40/0x70
       ...
       ? lock_timer_base+0x67/0x80
       kjournald2+0x121/0x360 [jbd2]
       ? remove_wait_queue+0x60/0x60
       kthread+0xf8/0x130
       ? commit_timeout+0x10/0x10 [jbd2]
       ? kthread_bind+0x10/0x10
       ret_from_fork+0x35/0x40
    
    With __invalidate_device(), I no longer hit the BUG_ON with sync or
    unmount on the disconnected device.
    
    Fixes: 29eaadc03649 ("nbd: stop using the bdev everywhere")
    Cc: linux-block@vger.kernel.org
    Cc: Ratna Manoj Bolla <manoj.br@gmail.com>
    Cc: nbd@other.debian.org
    Cc: stable@vger.kernel.org
    Cc: David Woodhouse <dwmw@amazon.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cc390b313cd07662fb38c79fb3dc16d7fedff31
Author: Will Deacon <will@kernel.org>
Date:   Mon Jul 29 11:43:48 2019 +0100

    drivers/perf: arm_pmu: Fix failure path in PM notifier
    
    commit 0d7fd70f26039bd4b33444ca47f0e69ce3ae0354 upstream.
    
    Handling of the CPU_PM_ENTER_FAILED transition in the Arm PMU PM
    notifier code incorrectly skips restoration of the counters. Fix the
    logic so that CPU_PM_ENTER_FAILED follows the same path as CPU_PM_EXIT.
    
    Cc: <stable@vger.kernel.org>
    Fixes: da4e4f18afe0f372 ("drivers/perf: arm_pmu: implement CPU_PM notifier")
    Reported-by: Anders Roxell <anders.roxell@linaro.org>
    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45842c3b55d7792bec170d9eb950bbcd14cd45cb
Author: Helge Deller <deller@gmx.de>
Date:   Thu Aug 1 13:33:39 2019 +0200

    parisc: Fix build of compressed kernel even with debug enabled
    
    commit 3fe6c873af2f2247544debdbe51ec29f690a2ccf upstream.
    
    With debug info enabled (CONFIG_DEBUG_INFO=y) the resulting vmlinux may get
    that huge that we need to increase the start addresss for the decompression
    text section otherwise one will face a linker error.
    
    Reported-by: Sven Schnelle <svens@stackframe.org>
    Tested-by: Sven Schnelle <svens@stackframe.org>
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b2c701ff2c0db1d4a1bdb8bd745c194df5b49f8
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu Aug 1 13:06:30 2019 +0200

    s390/dasd: fix endless loop after read unit address configuration
    
    commit 41995342b40c418a47603e1321256d2c4a2ed0fb upstream.
    
    After getting a storage server event that causes the DASD device driver
    to update its unit address configuration during a device shutdown there is
    the possibility of an endless loop in the device driver.
    
    In the system log there will be ongoing DASD error messages with RC: -19.
    
    The reason is that the loop starting the ruac request only terminates when
    the retry counter is decreased to 0. But in the sleep_on function there are
    early exit paths that do not decrease the retry counter.
    
    Prevent an endless loop by handling those cases separately.
    
    Remove the unnecessary do..while loop since the sleep_on function takes
    care of retries by itself.
    
    Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
    Cc: stable@vger.kernel.org # 2.6.25+
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e5928f8447053676243c94081842326effb92ea
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Thu Jul 25 12:52:43 2019 +0200

    selinux: fix memory leak in policydb_init()
    
    commit 45385237f65aeee73641f1ef737d7273905a233f upstream.
    
    Since roles_init() adds some entries to the role hash table, we need to
    destroy also its keys/values on error, otherwise we get a memory leak in
    the error path.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 683dbbec107970c93d64e367ac93ee31e19e8081
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Jul 31 12:54:28 2019 -0500

    IB/hfi1: Fix Spectre v1 vulnerability
    
    commit 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e upstream.
    
    sl is controlled by user-space, hence leading to a potential
    exploitation of the Spectre variant 1 vulnerability.
    
    Fix this by sanitizing sl before using it to index ibp->sl_to_sc.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a14a26ee583f4370fdbf973613d1ff8f971d744
Author: Michael Wu <michael.wu@vatics.com>
Date:   Mon Jul 8 13:23:08 2019 +0800

    gpiolib: fix incorrect IRQ requesting of an active-low lineevent
    
    commit 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 upstream.
    
    When a pin is active-low, logical trigger edge should be inverted to match
    the same interrupt opportunity.
    
    For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in
    ACTIVE_LOW case, the button pushed triggers rising edge. For user space the
    IRQ requesting doesn't need to do any modification except to configuring
    GPIOHANDLE_REQUEST_ACTIVE_LOW.
    
    For example, we want to catch the event when the button is pushed. The
    button on the original board drives level to be low when it is pushed, and
    drives level to be high when it is released.
    
    In user space we can do:
    
            req.handleflags = GPIOHANDLE_REQUEST_INPUT;
            req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
    
            while (1) {
                    read(fd, &dat, sizeof(dat));
                    if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE)
                            printf("button pushed\n");
            }
    
    Run the same logic on another board which the polarity of the button is
    inverted; it drives level to be high when pushed, and level to be low when
    released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:
    
            req.handleflags = GPIOHANDLE_REQUEST_INPUT |
                    GPIOHANDLE_REQUEST_ACTIVE_LOW;
            req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
    
    At the result, there are no any events caught when the button is pushed.
    By the way, button releasing will emit a "falling" event. The timing of
    "falling" catching is not expected.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Wu <michael.wu@vatics.com>
    Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdbe5dc2b716c60f266b91a5b126b88102105021
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Jul 8 12:56:13 2019 -0700

    mmc: dw_mmc: Fix occasional hang after tuning on eMMC
    
    commit ba2d139b02ba684c6c101de42fed782d6cd2b997 upstream.
    
    In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
    response errors.") we fixed a tuning-induced hang that I saw when
    stress testing tuning on certain SD cards.  I won't re-hash that whole
    commit, but the summary is that as a normal part of tuning you need to
    deal with transfer errors and there were cases where these transfer
    errors was putting my system into a bad state causing all future
    transfers to fail.  That commit fixed handling of the transfer errors
    for me.
    
    In downstream Chrome OS my fix landed and had the same behavior for
    all SD/MMC commands.  However, it looks like when the commit landed
    upstream we limited it to only SD tuning commands.  Presumably this
    was to try to get around problems that Alim Akhtar reported on exynos
    [1].
    
    Unfortunately while stress testing reboots (and suspend/resume) on
    some rk3288-based Chromebooks I found the same problem on the eMMC on
    some of my Chromebooks (the ones with Hynix eMMC).  Since the eMMC
    tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
    vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
    same situation.
    
    I'm hoping that whatever problems exynos was having in the past are
    somehow magically fixed now and we can make the behavior the same for
    all commands.
    
    [1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com
    
    Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Alim Akhtar <alim.akhtar@gmail.com>
    Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66a25e3da8ce97611d93e169f29b87a90b4d2e70
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jul 25 11:27:04 2019 +0100

    Btrfs: fix race leading to fs corruption after transaction abort
    
    commit cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 upstream.
    
    When one transaction is finishing its commit, it is possible for another
    transaction to start and enter its initial commit phase as well. If the
    first ends up getting aborted, we have a small time window where the second
    transaction commit does not notice that the previous transaction aborted
    and ends up committing, writing a superblock that points to btrees that
    reference extent buffers (nodes and leafs) that were not persisted to disk.
    The consequence is that after mounting the filesystem again, we will be
    unable to load some btree nodes/leafs, either because the content on disk
    is either garbage (or just zeroes) or corresponds to the old content of a
    previouly COWed or deleted node/leaf, resulting in the well known error
    messages "parent transid verify failed on ...".
    The following sequence diagram illustrates how this can happen.
    
            CPU 1                                           CPU 2
    
     <at transaction N>
    
     btrfs_commit_transaction()
       (...)
       --> sets transaction state to
           TRANS_STATE_UNBLOCKED
       --> sets fs_info->running_transaction
           to NULL
    
                                                        (...)
                                                        btrfs_start_transaction()
                                                          start_transaction()
                                                            wait_current_trans()
                                                              --> returns immediately
                                                                  because
                                                                  fs_info->running_transaction
                                                                  is NULL
                                                            join_transaction()
                                                              --> creates transaction N + 1
                                                              --> sets
                                                                  fs_info->running_transaction
                                                                  to transaction N + 1
                                                              --> adds transaction N + 1 to
                                                                  the fs_info->trans_list list
                                                            --> returns transaction handle
                                                                pointing to the new
                                                                transaction N + 1
                                                        (...)
    
                                                        btrfs_sync_file()
                                                          btrfs_start_transaction()
                                                            --> returns handle to
                                                                transaction N + 1
                                                          (...)
    
       btrfs_write_and_wait_transaction()
         --> writeback of some extent
             buffer fails, returns an
             error
       btrfs_handle_fs_error()
         --> sets BTRFS_FS_STATE_ERROR in
             fs_info->fs_state
       --> jumps to label "scrub_continue"
       cleanup_transaction()
         btrfs_abort_transaction(N)
           --> sets BTRFS_FS_STATE_TRANS_ABORTED
               flag in fs_info->fs_state
           --> sets aborted field in the
               transaction and transaction
               handle structures, for
               transaction N only
         --> removes transaction from the
             list fs_info->trans_list
                                                          btrfs_commit_transaction(N + 1)
                                                            --> transaction N + 1 was not
                                                                aborted, so it proceeds
                                                            (...)
                                                            --> sets the transaction's state
                                                                to TRANS_STATE_COMMIT_START
                                                            --> does not find the previous
                                                                transaction (N) in the
                                                                fs_info->trans_list, so it
                                                                doesn't know that transaction
                                                                was aborted, and the commit
                                                                of transaction N + 1 proceeds
                                                            (...)
                                                            --> sets transaction N + 1 state
                                                                to TRANS_STATE_UNBLOCKED
                                                            btrfs_write_and_wait_transaction()
                                                              --> succeeds writing all extent
                                                                  buffers created in the
                                                                  transaction N + 1
                                                            write_all_supers()
                                                               --> succeeds
                                                               --> we now have a superblock on
                                                                   disk that points to trees
                                                                   that refer to at least one
                                                                   extent buffer that was
                                                                   never persisted
    
    So fix this by updating the transaction commit path to check if the flag
    BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting
    the transaction to the TRANS_STATE_COMMIT_START we do not find any previous
    transaction in the fs_info->trans_list. If the flag is set, just fail the
    transaction commit with -EROFS, as we do in other places. The exact error
    code for the previous transaction abort was already logged and reported.
    
    Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd10423ef68e3cd66fc6b180737bb3f0cefe3404
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Jul 17 13:23:39 2019 +0100

    Btrfs: fix incremental send failure after deduplication
    
    commit b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 upstream.
    
    When doing an incremental send operation we can fail if we previously did
    deduplication operations against a file that exists in both snapshots. In
    that case we will fail the send operation with -EIO and print a message
    to dmesg/syslog like the following:
    
      BTRFS error (device sdc): Send: inconsistent snapshot, found updated \
      extent for inode 257 without updated inode item, send root is 258, \
      parent root is 257
    
    This requires that we deduplicate to the same file in both snapshots for
    the same amount of times on each snapshot. The issue happens because a
    deduplication only updates the iversion of an inode and does not update
    any other field of the inode, therefore if we deduplicate the file on
    each snapshot for the same amount of time, the inode will have the same
    iversion value (stored as the "sequence" field on the inode item) on both
    snapshots, therefore it will be seen as unchanged between in the send
    snapshot while there are new/updated/deleted extent items when comparing
    to the parent snapshot. This makes the send operation return -EIO and
    print an error message.
    
    Example reproducer:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount /dev/sdb /mnt
    
      # Create our first file. The first half of the file has several 64Kb
      # extents while the second half as a single 512Kb extent.
      $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo
      $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo
    
      # Create the base snapshot and the parent send stream from it.
      $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1
      $ btrfs send -f /tmp/1.snap /mnt/mysnap1
    
      # Create our second file, that has exactly the same data as the first
      # file.
      $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar
    
      # Create the second snapshot, used for the incremental send, before
      # doing the file deduplication.
      $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2
    
      # Now before creating the incremental send stream:
      #
      # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This
      #    will drop several extent items and add a new one, also updating
      #    the inode's iversion (sequence field in inode item) by 1, but not
      #    any other field of the inode;
      #
      # 2) Deduplicate into a different subrange of file foo in snapshot
      #    mysnap2. This will replace an extent item with a new one, also
      #    updating the inode's iversion by 1 but not any other field of the
      #    inode.
      #
      # After these two deduplication operations, the inode items, for file
      # foo, are identical in both snapshots, but we have different extent
      # items for this inode in both snapshots. We want to check this doesn't
      # cause send to fail with an error or produce an incorrect stream.
    
      $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo
      $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo
    
      # Create the incremental send stream.
      $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2
      ERROR: send ioctl failed with -5: Input/output error
    
    This issue started happening back in 2015 when deduplication was updated
    to not update the inode's ctime and mtime and update only the iversion.
    Back then we would hit a BUG_ON() in send, but later in 2016 send was
    updated to return -EIO and print the error message instead of doing the
    BUG_ON().
    
    A test case for fstests follows soon.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933
    Fixes: 1c919a5e13702c ("btrfs: don't update mtime/ctime on deduped inodes")
    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 3e1332cfb41ccb47134d20e08ce999474d4e1f38
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Mon Jul 29 18:15:17 2019 +0900

    kbuild: initialize CLANG_FLAGS correctly in the top Makefile
    
    commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream.
    
    CLANG_FLAGS is initialized by the following line:
    
      CLANG_FLAGS     := --target=$(notdir $(CROSS_COMPILE:%-=%))
    
    ..., which is run only when CROSS_COMPILE is set.
    
    Some build targets (bindeb-pkg etc.) recurse to the top Makefile.
    
    When you build the kernel with Clang but without CROSS_COMPILE,
    the same compiler flags such as -no-integrated-as are accumulated
    into CLANG_FLAGS.
    
    If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg',
    Kbuild will recompile everything needlessly due to the build command
    change.
    
    Fix this by correctly initializing CLANG_FLAGS.
    
    Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags")
    Cc: <stable@vger.kernel.org> # v5.0+
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Acked-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b92f12c5eef93b32800c4ee8d76a4f26141ece06
Author: Yongxin Liu <yongxin.liu@windriver.com>
Date:   Mon Jul 1 09:46:22 2019 +0800

    drm/nouveau: fix memory leak in nouveau_conn_reset()
    
    [ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ]
    
    In nouveau_conn_reset(), if connector->state is true,
    __drm_atomic_helper_connector_destroy_state() will be called,
    but the memory pointed by asyc isn't freed. Memory leak happens
    in the following function __drm_atomic_helper_connector_reset(),
    where newly allocated asyc->state will be assigned to connector->state.
    
    So using nouveau_conn_atomic_destroy_state() instead of
    __drm_atomic_helper_connector_destroy_state to free the "old" asyc.
    
    Here the is the log showing memory leak.
    
    unreferenced object 0xffff8c5480483c80 (size 192):
      comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
      hex dump (first 32 bytes):
        00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00  ...{T...........
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000005005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0
        [<00000000a122baed>] nouveau_conn_reset+0x25/0xc0 [nouveau]
        [<000000004fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau]
        [<00000000c73343a8>] nv50_display_create+0x343/0x980 [nouveau]
        [<000000002e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau]
        [<00000000c924699b>] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
        [<00000000cc029436>] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
        [<000000007e961c3e>] local_pci_probe+0x47/0xa0
        [<00000000da14d569>] work_for_cpu_fn+0x1a/0x30
        [<0000000028da4805>] process_one_work+0x27c/0x660
        [<000000001d415b04>] worker_thread+0x22b/0x3f0
        [<0000000003b69f1f>] kthread+0x12f/0x150
        [<00000000c94c29b7>] ret_from_fork+0x3a/0x50
    
    Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1567b8a0694ce81124023e499b1c7f29adb622cc
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Tue Jul 16 21:18:12 2019 +0800

    x86, boot: Remove multiple copy of static function sanitize_boot_params()
    
    [ Upstream commit 8c5477e8046ca139bac250386c08453da37ec1ae ]
    
    Kernel build warns:
     'sanitize_boot_params' defined but not used [-Wunused-function]
    
    at below files:
      arch/x86/boot/compressed/cmdline.c
      arch/x86/boot/compressed/error.c
      arch/x86/boot/compressed/early_serial_console.c
      arch/x86/boot/compressed/acpi.c
    
    That's becausethey each include misc.h which includes a definition of
    sanitize_boot_params() via bootparam_utils.h.
    
    Remove the inclusion from misc.h and have the c file including
    bootparam_utils.h directly.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/1563283092-1189-1-git-send-email-zhenzhong.duan@oracle.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c84ee720fd542433b0b864598842da8e66320f33
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Wed Jul 17 20:36:36 2019 -0500

    x86/paravirt: Fix callee-saved function ELF sizes
    
    [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ]
    
    The __raw_callee_save_*() functions have an ELF symbol size of zero,
    which confuses objtool and other tools.
    
    Fixes a bunch of warnings like the following:
    
      arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation
      arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pgd_val() is missing an ELF size annotation
      arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pte() is missing an ELF size annotation
      arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pgd() is missing an ELF size annotation
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/afa6d49bb07497ca62e4fc3b27a2d0cece545b4e.1563413318.git.jpoimboe@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54dcd8ce30bcf7c15f8e463581e129f9c357bea7
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Wed Jul 17 20:36:39 2019 -0500

    x86/kvm: Don't call kvm_spurious_fault() from .fixup
    
    [ Upstream commit 3901336ed9887b075531bffaeef7742ba614058b ]
    
    After making a change to improve objtool's sibling call detection, it
    started showing the following warning:
    
      arch/x86/kvm/vmx/nested.o: warning: objtool: .fixup+0x15: sibling call from callable instruction with modified stack frame
    
    The problem is the ____kvm_handle_fault_on_reboot() macro.  It does a
    fake call by pushing a fake RIP and doing a jump.  That tricks the
    unwinder into printing the function which triggered the exception,
    rather than the .fixup code.
    
    Instead of the hack to make it look like the original function made the
    call, just change the macro so that the original function actually does
    make the call.  This allows removal of the hack, and also makes objtool
    happy.
    
    I triggered a vmx instruction exception and verified that the stack
    trace is still sane:
    
      kernel BUG at arch/x86/kvm/x86.c:358!
      invalid opcode: 0000 [#1] SMP PTI
      CPU: 28 PID: 4096 Comm: qemu-kvm Not tainted 5.2.0+ #16
      Hardware name: Lenovo THINKSYSTEM SD530 -[7X2106Z000]-/-[7X2106Z000]-, BIOS -[TEE113Z-1.00]- 07/17/2017
      RIP: 0010:kvm_spurious_fault+0x5/0x10
      Code: 00 00 00 00 00 8b 44 24 10 89 d2 45 89 c9 48 89 44 24 10 8b 44 24 08 48 89 44 24 08 e9 d4 40 22 00 0f 1f 40 00 0f 1f 44 00 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41
      RSP: 0018:ffffbf91c683bd00 EFLAGS: 00010246
      RAX: 000061f040000000 RBX: ffff9e159c77bba0 RCX: ffff9e15a5c87000
      RDX: 0000000665c87000 RSI: ffff9e15a5c87000 RDI: ffff9e159c77bba0
      RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9e15a5c87000
      R10: 0000000000000000 R11: fffff8f2d99721c0 R12: ffff9e159c77bba0
      R13: ffffbf91c671d960 R14: ffff9e159c778000 R15: 0000000000000000
      FS:  00007fa341cbe700(0000) GS:ffff9e15b7400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fdd38356804 CR3: 00000006759de003 CR4: 00000000007606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       loaded_vmcs_init+0x4f/0xe0
       alloc_loaded_vmcs+0x38/0xd0
       vmx_create_vcpu+0xf7/0x600
       kvm_vm_ioctl+0x5e9/0x980
       ? __switch_to_asm+0x40/0x70
       ? __switch_to_asm+0x34/0x70
       ? __switch_to_asm+0x40/0x70
       ? __switch_to_asm+0x34/0x70
       ? free_one_page+0x13f/0x4e0
       do_vfs_ioctl+0xa4/0x630
       ksys_ioctl+0x60/0x90
       __x64_sys_ioctl+0x16/0x20
       do_syscall_64+0x55/0x1c0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fa349b1ee5b
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/64a9b64d127e87b6920a97afde8e96ea76f6524e.1563413318.git.jpoimboe@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cb3e16466fc1f9cb5724da048d0e13613bb84a2
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Sun Jul 14 17:15:32 2019 +0800

    xen/pv: Fix a boot up hang revealed by int3 self test
    
    [ Upstream commit b23e5844dfe78a80ba672793187d3f52e4b528d7 ]
    
    Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
    selftest") is used to ensure there is a gap setup in int3 exception stack
    which could be used for inserting call return address.
    
    This gap is missed in XEN PV int3 exception entry path, then below panic
    triggered:
    
    [    0.772876] general protection fault: 0000 [#1] SMP NOPTI
    [    0.772886] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0+ #11
    [    0.772893] RIP: e030:int3_magic+0x0/0x7
    [    0.772905] RSP: 3507:ffffffff82203e98 EFLAGS: 00000246
    [    0.773334] Call Trace:
    [    0.773334]  alternative_instructions+0x3d/0x12e
    [    0.773334]  check_bugs+0x7c9/0x887
    [    0.773334]  ? __get_locked_pte+0x178/0x1f0
    [    0.773334]  start_kernel+0x4ff/0x535
    [    0.773334]  ? set_init_arg+0x55/0x55
    [    0.773334]  xen_start_kernel+0x571/0x57a
    
    For 64bit PV guests, Xen's ABI enters the kernel with using SYSRET, with
    %rcx/%r11 on the stack. To convert back to "normal" looking exceptions,
    the xen thunks do 'xen_*: pop %rcx; pop %r11; jmp *'.
    
    E.g. Extracting 'xen_pv_trap xenint3' we have:
    xen_xenint3:
     pop %rcx;
     pop %r11;
     jmp xenint3
    
    As xenint3 and int3 entry code are same except xenint3 doesn't generate
    a gap, we can fix it by using int3 and drop useless xenint3.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Stefano Stabellini <sstabellini@kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e993f711dbdac072aea679a73a86ebd1867aff7
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jul 16 16:30:21 2019 -0700

    ipc/mqueue.c: only perform resource calculation if user valid
    
    [ Upstream commit a318f12ed8843cfac53198390c74a565c632f417 ]
    
    Andreas Christoforou reported:
    
      UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow:
      9 * 2305843009213693951 cannot be represented in type 'long int'
      ...
      Call Trace:
        mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414
        evict+0x472/0x8c0 fs/inode.c:558
        iput_final fs/inode.c:1547 [inline]
        iput+0x51d/0x8c0 fs/inode.c:1573
        mqueue_get_inode+0x8eb/0x1070 ipc/mqueue.c:320
        mqueue_create_attr+0x198/0x440 ipc/mqueue.c:459
        vfs_mkobj+0x39e/0x580 fs/namei.c:2892
        prepare_open ipc/mqueue.c:731 [inline]
        do_mq_open+0x6da/0x8e0 ipc/mqueue.c:771
    
    Which could be triggered by:
    
            struct mq_attr attr = {
                    .mq_flags = 0,
                    .mq_maxmsg = 9,
                    .mq_msgsize = 0x1fffffffffffffff,
                    .mq_curmsgs = 0,
            };
    
            if (mq_open("/testing", 0x40, 3, &attr) == (mqd_t) -1)
                    perror("mq_open");
    
    mqueue_get_inode() was correctly rejecting the giant mq_msgsize, and
    preparing to return -EINVAL.  During the cleanup, it calls
    mqueue_evict_inode() which performed resource usage tracking math for
    updating "user", before checking if there was a valid "user" at all
    (which would indicate that the calculations would be sane).  Instead,
    delay this check to after seeing a valid "user".
    
    The overflow was real, but the results went unused, so while the flaw is
    harmless, it's noisy for kernel fuzzers, so just fix it by moving the
    calculation under the non-NULL "user" where it actually gets used.
    
    Link: http://lkml.kernel.org/r/201906072207.ECB65450@keescook
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Andreas Christoforou <andreaschristofo@gmail.com>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29d2ceabec858dff2a596a68e5482646f408e955
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jul 16 16:30:03 2019 -0700

    drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings
    
    [ Upstream commit 156e0b1a8112b76e351684ac948c59757037ac36 ]
    
    The dev_info.name[] array has space for RIO_MAX_DEVNAME_SZ + 1
    characters.  But the problem here is that we don't ensure that the user
    put a NUL terminator on the end of the string.  It could lead to an out
    of bounds read.
    
    Link: http://lkml.kernel.org/r/20190529110601.GB19119@mwanda
    Fixes: e8de370188d0 ("rapidio: add mport char device driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e24aea6c00ed9f8aa03b18769564321d6a1a2c02
Author: Mikko Rapeli <mikko.rapeli@iki.fi>
Date:   Tue Jul 16 16:28:10 2019 -0700

    uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers
    
    [ Upstream commit f90fb3c7e2c13ae829db2274b88b845a75038b8a ]
    
    Only users of upc_req in kernel side fs/coda/psdev.c and
    fs/coda/upcall.c already include linux/coda_psdev.h.
    
    Suggested by Jan Harkes <jaharkes@cs.cmu.edu> in
      https://lore.kernel.org/lkml/20150531111913.GA23377@cs.cmu.edu/
    
    Fixes these include/uapi/linux/coda_psdev.h compilation errors in userspace:
    
      linux/coda_psdev.h:12:19: error: field `uc_chain' has incomplete type
      struct list_head    uc_chain;
                       ^
      linux/coda_psdev.h:13:2: error: unknown type name `caddr_t'
      caddr_t             uc_data;
      ^
      linux/coda_psdev.h:14:2: error: unknown type name `u_short'
      u_short             uc_flags;
      ^
      linux/coda_psdev.h:15:2: error: unknown type name `u_short'
      u_short             uc_inSize;  /* Size is at most 5000 bytes */
      ^
      linux/coda_psdev.h:16:2: error: unknown type name `u_short'
      u_short             uc_outSize;
      ^
      linux/coda_psdev.h:17:2: error: unknown type name `u_short'
      u_short             uc_opcode;  /* copied from data to save lookup */
      ^
      linux/coda_psdev.h:19:2: error: unknown type name `wait_queue_head_t'
      wait_queue_head_t   uc_sleep;   /* process' wait queue */
      ^
    
    Link: http://lkml.kernel.org/r/9f99f5ce6a0563d5266e6cf7aa9585aac2cae971.1558117389.git.jaharkes@cs.cmu.edu
    Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
    Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Fabian Frederick <fabf@skynet.be>
    Cc: Sam Protsenko <semen.protsenko@linaro.org>
    Cc: Yann Droneaud <ydroneaud@opteya.com>
    Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49df626d3915dd11447ad1e0facfdd47d55d5b8a
Author: Sam Protsenko <semen.protsenko@linaro.org>
Date:   Tue Jul 16 16:28:20 2019 -0700

    coda: fix build using bare-metal toolchain
    
    [ Upstream commit b2a57e334086602be56b74958d9f29b955cd157f ]
    
    The kernel is self-contained project and can be built with bare-metal
    toolchain.  But bare-metal toolchain doesn't define __linux__.  Because
    of this u_quad_t type is not defined when using bare-metal toolchain and
    codafs build fails.  This patch fixes it by defining u_quad_t type
    unconditionally.
    
    Link: http://lkml.kernel.org/r/3cbb40b0a57b6f9923a9d67b53473c0b691a3eaa.1558117389.git.jaharkes@cs.cmu.edu
    Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
    Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Fabian Frederick <fabf@skynet.be>
    Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
    Cc: Yann Droneaud <ydroneaud@opteya.com>
    Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc9b9b516441836e365205306eebdcf6cb70bd68
Author: Zhouyang Jia <jiazhouyang09@gmail.com>
Date:   Tue Jul 16 16:28:13 2019 -0700

    coda: add error handling for fget
    
    [ Upstream commit 02551c23bcd85f0c68a8259c7b953d49d44f86af ]
    
    When fget fails, the lack of error-handling code may cause unexpected
    results.
    
    This patch adds error-handling code after calling fget.
    
    Link: http://lkml.kernel.org/r/2514ec03df9c33b86e56748513267a80dd8004d9.1558117389.git.jaharkes@cs.cmu.edu
    Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
    Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Fabian Frederick <fabf@skynet.be>
    Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
    Cc: Sam Protsenko <semen.protsenko@linaro.org>
    Cc: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2aca945f096d0701b0f7e15482fdba5d4c5eedbf
Author: Doug Berger <opendmb@gmail.com>
Date:   Tue Jul 16 16:26:24 2019 -0700

    mm/cma.c: fail if fixed declaration can't be honored
    
    [ Upstream commit c633324e311243586675e732249339685e5d6faa ]
    
    The description of cma_declare_contiguous() indicates that if the
    'fixed' argument is true the reserved contiguous area must be exactly at
    the address of the 'base' argument.
    
    However, the function currently allows the 'base', 'size', and 'limit'
    arguments to be silently adjusted to meet alignment constraints.  This
    commit enforces the documented behavior through explicit checks that
    return an error if the region does not fit within a specified region.
    
    Link: http://lkml.kernel.org/r/1561422051-16142-1-git-send-email-opendmb@gmail.com
    Fixes: 5ea3b1b2f8ad ("cma: add placement specifier for "cma=" kernel parameter")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Cc: Yue Hu <huyue2@yulong.com>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Peng Fan <peng.fan@nxp.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca5732b311eba9cca9dfb7acdf17e0ea3c1b842e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 12 11:08:05 2019 +0200

    x86: math-emu: Hide clang warnings for 16-bit overflow
    
    [ Upstream commit 29e7e9664aec17b94a9c8c5a75f8d216a206aa3a ]
    
    clang warns about a few parts of the math-emu implementation
    where a 16-bit integer becomes negative during assignment:
    
    arch/x86/math-emu/poly_tan.c:88:35: error: implicit conversion from 'int' to 'short' changes value from 49216 to -16320 [-Werror,-Wconstant-conversion]
                                          (0x41 + EXTENDED_Ebias) | SIGN_Negative);
                                          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
    arch/x86/math-emu/fpu_emu.h:180:58: note: expanded from macro 'setexponent16'
     #define setexponent16(x,y)  { (*(short *)&((x)->exp)) = (y); }
                                                          ~  ^
    arch/x86/math-emu/reg_constant.c:37:32: error: implicit conversion from 'int' to 'short' changes value from 49085 to -16451 [-Werror,-Wconstant-conversion]
    FPU_REG const CONST_PI2extra = MAKE_REG(NEG, -66,
                                   ^~~~~~~~~~~~~~~~~~
    arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG'
                    ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    arch/x86/math-emu/reg_constant.c:48:28: error: implicit conversion from 'int' to 'short' changes value from 65535 to -1 [-Werror,-Wconstant-conversion]
    FPU_REG const CONST_QNaN = MAKE_REG(NEG, EXP_OVER, 0x00000000, 0xC0000000);
                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG'
                    ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
                     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The code is correct as is, so add a typecast to shut up the warnings.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/20190712090816.350668-1-arnd@arndb.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc22ec80d5c0ada2db931ac37ff70b3dcc010ff8
Author: Qian Cai <cai@lca.pw>
Date:   Mon Jul 8 17:36:45 2019 -0400

    x86/apic: Silence -Wtype-limits compiler warnings
    
    [ Upstream commit ec6335586953b0df32f83ef696002063090c7aef ]
    
    There are many compiler warnings like this,
    
    In file included from ./arch/x86/include/asm/smp.h:13,
                     from ./arch/x86/include/asm/mmzone_64.h:11,
                     from ./arch/x86/include/asm/mmzone.h:5,
                     from ./include/linux/mmzone.h:969,
                     from ./include/linux/gfp.h:6,
                     from ./include/linux/mm.h:10,
                     from arch/x86/kernel/apic/io_apic.c:34:
    arch/x86/kernel/apic/io_apic.c: In function 'check_timer':
    ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
    expression >= 0 is always true [-Wtype-limits]
       if ((v) <= apic_verbosity) \
               ^~
    arch/x86/kernel/apic/io_apic.c:2160:2: note: in expansion of macro
    'apic_printk'
      apic_printk(APIC_QUIET, KERN_INFO "..TIMER: vector=0x%02X "
      ^~~~~~~~~~~
    ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned
    expression >= 0 is always true [-Wtype-limits]
       if ((v) <= apic_verbosity) \
               ^~
    arch/x86/kernel/apic/io_apic.c:2207:4: note: in expansion of macro
    'apic_printk'
        apic_printk(APIC_QUIET, KERN_ERR "..MP-BIOS bug: "
        ^~~~~~~~~~~
    
    APIC_QUIET is 0, so silence them by making apic_verbosity type int.
    
    Signed-off-by: Qian Cai <cai@lca.pw>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/1562621805-24789-1-git-send-email-cai@lca.pw
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f46c7e629d30fb92d276c32cec37293bd866d931
Author: Benjamin Poirier <bpoirier@suse.com>
Date:   Tue Jul 16 17:16:55 2019 +0900

    be2net: Signal that the device cannot transmit during reconfiguration
    
    [ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ]
    
    While changing the number of interrupt channels, be2net stops adapter
    operation (including netif_tx_disable()) but it doesn't signal that it
    cannot transmit. This may lead dev_watchdog() to falsely trigger during
    that time.
    
    Add the missing call to netif_carrier_off(), following the pattern used in
    many other drivers. netif_carrier_on() is already taken care of in
    be_open().
    
    Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a281bcaea8923cdba95686a7f35da4cdc74c847b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 12 11:01:21 2019 +0200

    ACPI: fix false-positive -Wuninitialized warning
    
    [ Upstream commit dfd6f9ad36368b8dbd5f5a2b2f0a4705ae69a323 ]
    
    clang gets confused by an uninitialized variable in what looks
    to it like a never executed code path:
    
    arch/x86/kernel/acpi/boot.c:618:13: error: variable 'polarity' is uninitialized when used here [-Werror,-Wuninitialized]
            polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
                       ^~~~~~~~
    arch/x86/kernel/acpi/boot.c:606:32: note: initialize the variable 'polarity' to silence this warning
            int rc, irq, trigger, polarity;
                                          ^
                                           = 0
    arch/x86/kernel/acpi/boot.c:617:12: error: variable 'trigger' is uninitialized when used here [-Werror,-Wuninitialized]
            trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                      ^~~~~~~
    arch/x86/kernel/acpi/boot.c:606:22: note: initialize the variable 'trigger' to silence this warning
            int rc, irq, trigger, polarity;
                                ^
                                 = 0
    
    This is unfortunately a design decision in clang and won't be fixed.
    
    Changing the acpi_get_override_irq() macro to an inline function
    reliably avoids the issue.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e5ba38934b51b82e1c49092a0f9ccba5b3e7fd7
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 12 11:12:30 2019 +0200

    x86: kvm: avoid constant-conversion warning
    
    [ Upstream commit a6a6d3b1f867d34ba5bd61aa7bb056b48ca67cff ]
    
    clang finds a contruct suspicious that converts an unsigned
    character to a signed integer and back, causing an overflow:
    
    arch/x86/kvm/mmu.c:4605:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -205 to 51 [-Werror,-Wconstant-conversion]
                    u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0;
                       ~~                               ^~
    arch/x86/kvm/mmu.c:4607:38: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -241 to 15 [-Werror,-Wconstant-conversion]
                    u8 uf = (pfec & PFERR_USER_MASK) ? ~u : 0;
                       ~~                              ^~
    arch/x86/kvm/mmu.c:4609:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -171 to 85 [-Werror,-Wconstant-conversion]
                    u8 ff = (pfec & PFERR_FETCH_MASK) ? ~x : 0;
                       ~~                               ^~
    
    Add an explicit cast to tell clang that everything works as
    intended here.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://github.com/ClangBuiltLinux/linux/issues/95
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 120704bef9cc32cceab7e1afb7b8d7fb4c44292a
Author: Benjamin Block <bblock@linux.ibm.com>
Date:   Tue Jul 2 23:02:02 2019 +0200

    scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized
    
    [ Upstream commit 484647088826f2f651acbda6bcf9536b8a466703 ]
    
    GCC v9 emits this warning:
          CC      drivers/s390/scsi/zfcp_erp.o
        drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_action_enqueue':
        drivers/s390/scsi/zfcp_erp.c:217:26: warning: 'erp_action' may be used uninitialized in this function [-Wmaybe-uninitialized]
          217 |  struct zfcp_erp_action *erp_action;
              |                          ^~~~~~~~~~
    
    This is a possible false positive case, as also documented in the GCC
    documentations:
        https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized
    
    The actual code-sequence is like this:
        Various callers can invoke the function below with the argument "want"
        being one of:
        ZFCP_ERP_ACTION_REOPEN_ADAPTER,
        ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
        ZFCP_ERP_ACTION_REOPEN_PORT, or
        ZFCP_ERP_ACTION_REOPEN_LUN.
    
        zfcp_erp_action_enqueue(want, ...)
            ...
            need = zfcp_erp_required_act(want, ...)
                need = want
                ...
                maybe: need = ZFCP_ERP_ACTION_REOPEN_PORT
                maybe: need = ZFCP_ERP_ACTION_REOPEN_ADAPTER
                ...
                return need
            ...
            zfcp_erp_setup_act(need, ...)
                struct zfcp_erp_action *erp_action; // <== line 217
                ...
                switch(need) {
                case ZFCP_ERP_ACTION_REOPEN_LUN:
                        ...
                        erp_action = &zfcp_sdev->erp_action;
                        WARN_ON_ONCE(erp_action->port != port); // <== access
                        ...
                        break;
                case ZFCP_ERP_ACTION_REOPEN_PORT:
                case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
                        ...
                        erp_action = &port->erp_action;
                        WARN_ON_ONCE(erp_action->port != port); // <== access
                        ...
                        break;
                case ZFCP_ERP_ACTION_REOPEN_ADAPTER:
                        ...
                        erp_action = &adapter->erp_action;
                        WARN_ON_ONCE(erp_action->port != NULL); // <== access
                        ...
                        break;
                }
                ...
                WARN_ON_ONCE(erp_action->adapter != adapter); // <== access
    
    When zfcp_erp_setup_act() is called, 'need' will never be anything else
    than one of the 4 possible enumeration-names that are used in the
    switch-case, and 'erp_action' is initialized for every one of them, before
    it is used. Thus the warning is a false positive, as documented.
    
    We introduce the extra if{} in the beginning to create an extra code-flow,
    so the compiler can be convinced that the switch-case will never see any
    other value.
    
    BUG_ON()/BUG() is intentionally not used to not crash anything, should
    this ever happen anyway - right now it's impossible, as argued above; and
    it doesn't introduce a 'default:' switch-case to retain warnings should
    'enum zfcp_erp_act_type' ever be extended and no explicit case be
    introduced. See also v5.0 commit 399b6c8bc9f7 ("scsi: zfcp: drop old
    default switch case which might paper over missing case").
    
    Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Reviewed-by: Steffen Maier <maier@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bba80b1e83a136940536596f260750bbade0eec
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 10 15:05:43 2019 +0200

    ACPI: blacklist: fix clang warning for unused DMI table
    
    [ Upstream commit b80d6a42bdc97bdb6139107d6034222e9843c6e2 ]
    
    When CONFIG_DMI is disabled, we only have a tentative declaration,
    which causes a warning from clang:
    
    drivers/acpi/blacklist.c:20:35: error: tentative array definition assumed to have one element [-Werror]
    static const struct dmi_system_id acpi_rev_dmi_table[] __initconst;
    
    As the variable is not actually used here, hide it entirely
    in an #ifdef to shut up the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a065f662da7fadc8cc775b10aa21222b6692c9c0
Author: Jeff Layton <jlayton@kernel.org>
Date:   Thu Jun 13 15:17:00 2019 -0400

    ceph: return -ERANGE if virtual xattr value didn't fit in buffer
    
    [ Upstream commit 3b421018f48c482bdc9650f894aa1747cf90e51d ]
    
    The getxattr manpage states that we should return ERANGE if the
    destination buffer size is too small to hold the value.
    ceph_vxattrcb_layout does this internally, but we should be doing
    this for all vxattrs.
    
    Fix the only caller of getxattr_cb to check the returned size
    against the buffer length and return -ERANGE if it doesn't fit.
    Drop the same check in ceph_vxattrcb_layout and just rely on the
    caller to handle it.
    
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
    Acked-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64672c1f2cfe2ad9be4dddf7d7f8838cf80e1e62
Author: Andrea Parri <andrea.parri@amarulasolutions.com>
Date:   Mon May 20 19:23:58 2019 +0200

    ceph: fix improper use of smp_mb__before_atomic()
    
    [ Upstream commit 749607731e26dfb2558118038c40e9c0c80d23b5 ]
    
    This barrier only applies to the read-modify-write operations; in
    particular, it does not apply to the atomic64_set() primitive.
    
    Replace the barrier with an smp_mb().
    
    Fixes: fdd4e15838e59 ("ceph: rework dcache readdir")
    Reported-by: "Paul E. McKenney" <paulmck@linux.ibm.com>
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
    Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 443aeb74811e827e7632dd3bc5e90e7c5caf17c9
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Sat Jul 6 06:52:46 2019 +1000

    cifs: Fix a race condition with cifs_echo_request
    
    [ Upstream commit f2caf901c1b7ce65f9e6aef4217e3241039db768 ]
    
    There is a race condition with how we send (or supress and don't send)
    smb echos that will cause the client to incorrectly think the
    server is unresponsive and thus needs to be reconnected.
    
    Summary of the race condition:
     1) Daisy chaining scheduling creates a gap.
     2) If traffic comes unfortunate shortly after
        the last echo, the planned echo is suppressed.
     3) Due to the gap, the next echo transmission is delayed
        until after the timeout, which is set hard to twice
        the echo interval.
    
    This is fixed by changing the timeouts from 2 to three times the echo interval.
    
    Detailed description of the bug: https://lutz.donnerhacke.de/eng/Blog/Groundhog-Day-with-SMB-remount
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff35fc5969dce1beb994f50c3cf8ba17c9a85a8e
Author: David Sterba <dsterba@suse.com>
Date:   Fri May 17 11:43:13 2019 +0200

    btrfs: fix minimum number of chunk errors for DUP
    
    [ Upstream commit 0ee5f8ae082e1f675a2fb6db601c31ac9958a134 ]
    
    The list of profiles in btrfs_chunk_max_errors lists DUP as a profile
    DUP able to tolerate 1 device missing. Though this profile is special
    with 2 copies, it still needs the device, unlike the others.
    
    Looking at the history of changes, thre's no clear reason why DUP is
    there, functions were refactored and blocks of code merged to one
    helper.
    
    d20983b40e828 Btrfs: fix writing data into the seed filesystem
      - factor code to a helper
    
    de11cc12df173 Btrfs: don't pre-allocate btrfs bio
      - unrelated change, DUP still in the list with max errors 1
    
    a236aed14ccb0 Btrfs: Deal with failed writes in mirrored configurations
      - introduced the max errors, leaves DUP and RAID1 in the same group
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72d9c8901520fbe456057a348f371f540c7525a7
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Jun 4 14:50:14 2019 +0100

    fs/adfs: super: fix use-after-free bug
    
    [ Upstream commit 5808b14a1f52554de612fee85ef517199855e310 ]
    
    Fix a use-after-free bug during filesystem initialisation, where we
    access the disc record (which is stored in a buffer) after we have
    released the buffer.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0144ce7c04a36249f34590c78acc93fb544e73b
Author: JC Kuo <jckuo@nvidia.com>
Date:   Wed Jun 12 11:14:34 2019 +0800

    clk: tegra210: fix PLLU and PLLU_OUT1
    
    [ Upstream commit 0d34dfbf3023cf119b83f6470692c0b10c832495 ]
    
    Full-speed and low-speed USB devices do not work with Tegra210
    platforms because of incorrect PLLU/PLLU_OUT1 clock settings.
    
    When full-speed device is connected:
    [   14.059886] usb 1-3: new full-speed USB device number 2 using tegra-xusb
    [   14.196295] usb 1-3: device descriptor read/64, error -71
    [   14.436311] usb 1-3: device descriptor read/64, error -71
    [   14.675749] usb 1-3: new full-speed USB device number 3 using tegra-xusb
    [   14.812335] usb 1-3: device descriptor read/64, error -71
    [   15.052316] usb 1-3: device descriptor read/64, error -71
    [   15.164799] usb usb1-port3: attempt power cycle
    
    When low-speed device is connected:
    [   37.610949] usb usb1-port3: Cannot enable. Maybe the USB cable is bad?
    [   38.557376] usb usb1-port3: Cannot enable. Maybe the USB cable is bad?
    [   38.564977] usb usb1-port3: attempt power cycle
    
    This commit fixes the issue by:
     1. initializing PLLU_OUT1 before initializing XUSB_FS_SRC clock
        because PLLU_OUT1 is parent of XUSB_FS_SRC.
     2. changing PLLU post-divider to /2 (DIVP=1) according to Technical
        Reference Manual.
    
    Fixes: e745f992cf4b ("clk: tegra: Rework pll_u")
    Signed-off-by: JC Kuo <jckuo@nvidia.com>
    Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 641b87ab129ac97577b3d25c19c8e677f6183907
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Jun 24 14:38:18 2019 +0200

    dmaengine: rcar-dmac: Reject zero-length slave DMA requests
    
    [ Upstream commit 78efb76ab4dfb8f74f290ae743f34162cd627f19 ]
    
    While the .device_prep_slave_sg() callback rejects empty scatterlists,
    it still accepts single-entry scatterlists with a zero-length segment.
    These may happen if a driver calls dmaengine_prep_slave_single() with a
    zero len parameter.  The corresponding DMA request will never complete,
    leading to messages like:
    
        rcar-dmac e7300000.dma-controller: Channel Address Error happen
    
    and DMA timeouts.
    
    Although requesting a zero-length DMA request is a driver bug, rejecting
    it early eases debugging.  Note that the .device_prep_dma_memcpy()
    callback already rejects requests to copy zero bytes.
    
    Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Analyzed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6debf98d7702158532705bc698b1d8fb6b9612a6
Author: Petr Cvek <petrcvekcz@gmail.com>
Date:   Thu Jun 20 23:39:37 2019 +0200

    MIPS: lantiq: Fix bitfield masking
    
    [ Upstream commit ba1bc0fcdeaf3bf583c1517bd2e3e29cf223c969 ]
    
    The modification of EXIN register doesn't clean the bitfield before
    the writing of a new value. After a few modifications the bitfield would
    accumulate only '1's.
    
    Signed-off-by: Petr Cvek <petrcvekcz@gmail.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: hauke@hauke-m.de
    Cc: john@phrozen.org
    Cc: linux-mips@vger.kernel.org
    Cc: openwrt-devel@lists.openwrt.org
    Cc: pakahmar@hotmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 902d0ba7f76cd07e1705e277aca65b3cafdb3e22
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Wed May 29 07:26:25 2019 -0400

    kernel/module.c: Only return -EEXIST for modules that have finished loading
    
    [ Upstream commit 6e6de3dee51a439f76eb73c22ae2ffd2c9384712 ]
    
    Microsoft HyperV disables the X86_FEATURE_SMCA bit on AMD systems, and
    linux guests boot with repeated errors:
    
    amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
    amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2)
    amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2)
    amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
    amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2)
    amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2)
    
    The warnings occur because the module code erroneously returns -EEXIST
    for modules that have failed to load and are in the process of being
    removed from the module list.
    
    module amd64_edac_mod has a dependency on module edac_mce_amd.  Using
    modules.dep, systemd will load edac_mce_amd for every request of
    amd64_edac_mod.  When the edac_mce_amd module loads, the module has
    state MODULE_STATE_UNFORMED and once the module load fails and the state
    becomes MODULE_STATE_GOING.  Another request for edac_mce_amd module
    executes and add_unformed_module() will erroneously return -EEXIST even
    though the previous instance of edac_mce_amd has MODULE_STATE_GOING.
    Upon receiving -EEXIST, systemd attempts to load amd64_edac_mod, which
    fails because of unknown symbols from edac_mce_amd.
    
    add_unformed_module() must wait to return for any case other than
    MODULE_STATE_LIVE to prevent a race between multiple loads of
    dependent modules.
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Barret Rhoden <brho@google.com>
    Cc: David Arcari <darcari@redhat.com>
    Cc: Jessica Yu <jeyu@kernel.org>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b0e895af8cedac11e5e9938073920b00332861f
Author: Cheng Jian <cj.chengjian@huawei.com>
Date:   Sat May 4 19:39:39 2019 +0800

    ftrace: Enable trampoline when rec count returns back to one
    
    [ Upstream commit a124692b698b00026a58d89831ceda2331b2e1d0 ]
    
    Custom trampolines can only be enabled if there is only a single ops
    attached to it. If there's only a single callback registered to a function,
    and the ops has a trampoline registered for it, then we can call the
    trampoline directly. This is very useful for improving the performance of
    ftrace and livepatch.
    
    If more than one callback is registered to a function, the general
    trampoline is used, and the custom trampoline is not restored back to the
    direct call even if all the other callbacks were unregistered and we are
    back to one callback for the function.
    
    To fix this, set FTRACE_FL_TRAMP flag if rec count is decremented
    to one, and the ops that left has a trampoline.
    
    Testing After this patch :
    
    insmod livepatch_unshare_files.ko
    cat /sys/kernel/debug/tracing/enabled_functions
    
            unshare_files (1) R I   tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0
    
    echo unshare_files > /sys/kernel/debug/tracing/set_ftrace_filter
    echo function > /sys/kernel/debug/tracing/current_tracer
    cat /sys/kernel/debug/tracing/enabled_functions
    
            unshare_files (2) R I ->ftrace_ops_list_func+0x0/0x150
    
    echo nop > /sys/kernel/debug/tracing/current_tracer
    cat /sys/kernel/debug/tracing/enabled_functions
    
            unshare_files (1) R I   tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0
    
    Link: http://lkml.kernel.org/r/1556969979-111047-1-git-send-email-cj.chengjian@huawei.com
    
    Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce9adca361d4decda6b4e1b4f4470251dc7ceab2
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue May 21 16:49:33 2019 -0700

    ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend
    
    [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
    
    This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
    counter doesn't tick in system suspend").  Specifically on the rk3288
    it can be seen that the timer stops ticking in suspend if we end up
    running through the "osc_disable" path in rk3288_slp_mode_set().  In
    that path the 24 MHz clock will turn off and the timer stops.
    
    To test this, I ran this on a Chrome OS filesystem:
      before=$(date); \
      suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
      echo ${before}; date
    
    ...and I found that unless I plug in a device that requests USB wakeup
    to be active that the two calls to "date" would show that fewer than
    30 seconds passed.
    
    NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
    supported yet on upstream Linux so this was tested on a downstream
    kernel.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbaf72c8b7d49f5d4b6543561e1708066612c21c
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri May 3 16:45:37 2019 -0700

    ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work again
    
    [ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ]
    
    When I try to boot rk3288-veyron-mickey I totally fail to make the
    eMMC work.  Specifically my logs (on Chrome OS 4.19):
    
      mmc_host mmc1: card is non-removable.
      mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
      mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
      mmc1: switch to bus width 8 failed
      mmc1: switch to bus width 4 failed
      mmc1: new high speed MMC card at address 0001
      mmcblk1: mmc1:0001 HAG2e 14.7 GiB
      mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB
      mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB
      mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0)
      mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
      mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
      mmc1: switch to bus width 8 failed
      mmc1: switch to bus width 4 failed
      mmc1: tried to HW reset card, got error -110
      mmcblk1: error -110 requesting status
      mmcblk1: recovery failed!
      print_req_error: I/O error, dev mmcblk1, sector 0
      ...
    
    When I remove the '/delete-property/mmc-hs200-1_8v' then everything is
    hunky dory.
    
    That line comes from the original submission of the mickey dts
    upstream, so presumably at the time the HS200 was failing and just
    enumerating things as a high speed device was fine.  ...or maybe it's
    just that some mickey devices work when enumerating at "high speed",
    just not mine?
    
    In any case, hs200 seems good now.  Let's turn it on.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f60f99b41312d58bbbd0a438d5397095d1c8b8a
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri May 3 16:41:42 2019 -0700

    ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200
    
    [ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ]
    
    As some point hs200 was failing on rk3288-veyron-minnie.  See commit
    984926781122 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
    from rk3288 minnie").  Although I didn't track down exactly when it
    started working, it seems to work OK now, so let's turn it back on.
    
    To test this, I booted from SD card and then used this script to
    stress the enumeration process after fixing a memory leak [1]:
      cd /sys/bus/platform/drivers/dwmmc_rockchip
      for i in $(seq 1 3000); do
        echo "========================" $i
        echo ff0f0000.dwmmc > unbind
        sleep .5
        echo ff0f0000.dwmmc > bind
        while true; do
          if [ -e /dev/mmcblk2 ]; then
            break;
          fi
          sleep .1
        done
      done
    
    It worked fine.
    
    [1] https://lkml.kernel.org/r/20190503233526.226272-1-dianders@chromium.org
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff1b2beb5f0042cbfa99c82ea44a0b64b16b097a
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Thu May 2 17:19:18 2019 +0100

    ARM: riscpc: fix DMA
    
    [ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
    
    DMA got broken a while back in two different ways:
    1) a change in the behaviour of disable_irq() to wait for the interrupt
       to finish executing causes us to deadlock at the end of DMA.
    2) a change to avoid modifying the scatterlist left the first transfer
       uninitialised.
    
    DMA is only used with expansion cards, so has gone unnoticed.
    
    Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>