commit 45b83c1819d408f46ef4ac3d07b92ba61c86d1e9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jun 20 10:24:22 2020 +0200

    Linux 4.9.228

commit 74c9406e6c1041b9c0e6658b8b4b601fcc581f71
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue May 26 18:52:07 2020 +0300

    perf symbols: Fix debuginfo search for Ubuntu
    
    commit 85afd35575a3c1a3a905722dde5ee70b49282e70 upstream.
    
    Reportedly, from 19.10 Ubuntu has begun mixing up the location of some
    debug symbol files, putting files expected to be in
    /usr/lib/debug/usr/lib into /usr/lib/debug/lib instead. Fix by adding
    another dso_binary_type.
    
    Example on Ubuntu 20.04
    
      Before:
    
        $ perf record -e intel_pt//u uname
        Linux
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.030 MB perf.data ]
        $ perf script --call-trace | head -5
               uname 14003 [005] 15321.764958566:  cbr: 42 freq: 4219 MHz (156%)
               uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )          7f1e71cc4100
               uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )              7f1e71cc4df0
               uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )              7f1e71cc4e18
               uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )              7f1e71cc5128
    
      After:
    
        $ perf script --call-trace | head -5
               uname 14003 [005] 15321.764958566:  cbr: 42 freq: 4219 MHz (156%)
               uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )      _start
               uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )          _dl_start
               uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )          _dl_start
               uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so              )          _dl_start
    
    Reported-by: Travis Downs <travis.downs@gmail.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20200526155207.9172-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1d8696eff0619f2a36adbc62260fa8330a0f165
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Apr 23 20:01:22 2020 +0900

    perf probe: Do not show the skipped events
    
    commit f41ebe9defacddeae96a872a33f0f22ced0bfcef upstream.
    
    When a probe point is expanded to several places (like inlined) and if
    some of them are skipped because of blacklisted or __init function,
    those trace_events has no event name. It must be skipped while showing
    results.
    
    Without this fix, you can see "(null):(null)" on the list,
    
      # ./perf probe request_resource
      reserve_setup is out of .text, skip it.
      Added new events:
        (null):(null)        (on request_resource)
        probe:request_resource (on request_resource)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:request_resource -aR sleep 1
    
      #
    
    With this fix, it is ignored:
    
      # ./perf probe request_resource
      reserve_setup is out of .text, skip it.
      Added new events:
        probe:request_resource (on request_resource)
    
      You can now use it in all perf tools, such as:
    
            perf record -e probe:request_resource -aR sleep 1
    
      #
    
    Fixes: 5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of .text")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/158763968263.30755.12800484151476026340.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05f3752fd72a975f5568db0631cb102b9a9f5dde
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Sat May 23 19:32:54 2020 +0200

    w1: omap-hdq: cleanup to add missing newline for some dev_dbg
    
    commit 5e02f3b31704e24537697bce54f8156bdb72b7a6 upstream.
    
    Otherwise it will corrupt the console log during debugging.
    
    Fixes: 7b5362a603a1 ("w1: omap_hdq: Fix some error/debug handling.")
    Cc: stable@vger.kernel.org
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Link: https://lore.kernel.org/r/cd0d55749a091214106575f6e1d363c6db56622f.1590255176.git.hns@goldelico.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07725316c9a4003781973c2e8937f01c86cdd601
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue May 19 15:00:13 2020 +0200

    mtd: rawnand: pasemi: Fix the probe error path
    
    commit f51466901c07e6930435d30b02a21f0841174f61 upstream.
    
    nand_cleanup() is supposed to be called on error after a successful
    call to nand_scan() to free all NAND resources.
    
    There is no real Fixes tag applying here as the use of nand_release()
    in this driver predates by far the introduction of nand_cleanup() in
    commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
    which makes this change possible, hence pointing it as the commit to
    fix for backporting purposes, even if this commit is not introducing
    any bug.
    
    Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-41-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b5e5d10a422033c2eddb80c9c0e63d872709da5
Author: Álvaro Fernández Rojas <noltari@gmail.com>
Date:   Tue May 12 09:57:32 2020 +0200

    mtd: rawnand: brcmnand: fix hamming oob layout
    
    commit 130bbde4809b011faf64f99dddc14b4b01f440c3 upstream.
    
    First 2 bytes are used in large-page nand.
    
    Fixes: ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops")
    Cc: stable@vger.kernel.org
    Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20200512075733.745374-2-noltari@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d32887e72c6a51c60f4f10b22c6c5c227814d091
Author: NeilBrown <neilb@suse.de>
Date:   Fri May 22 12:01:33 2020 +1000

    sunrpc: clean up properly in gss_mech_unregister()
    
    commit 24c5efe41c29ee3e55bcf5a1c9f61ca8709622e8 upstream.
    
    gss_mech_register() calls svcauth_gss_register_pseudoflavor() for each
    flavour, but gss_mech_unregister() does not call auth_domain_put().
    This is unbalanced and makes it impossible to reload the module.
    
    Change svcauth_gss_register_pseudoflavor() to return the registered
    auth_domain, and save it for later release.
    
    Cc: stable@vger.kernel.org (v2.6.12+)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59b68cab2edd319095dede47acf349855a7176c6
Author: NeilBrown <neilb@suse.de>
Date:   Fri May 22 12:01:33 2020 +1000

    sunrpc: svcauth_gss_register_pseudoflavor must reject duplicate registrations.
    
    commit d47a5dc2888fd1b94adf1553068b8dad76cec96c upstream.
    
    There is no valid case for supporting duplicate pseudoflavor
    registrations.
    Currently the silent acceptance of such registrations is hiding a bug.
    The rpcsec_gss_krb5 module registers 2 flavours but does not unregister
    them, so if you load, unload, reload the module, it will happily
    continue to use the old registration which now has pointers to the
    memory were the module was originally loaded.  This could lead to
    unexpected results.
    
    So disallow duplicate registrations.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
    Cc: stable@vger.kernel.org (v2.6.12+)
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5295e74327da34f6925036675ee85ffac654f1f9
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun May 31 17:47:06 2020 +0900

    kbuild: force to build vmlinux if CONFIG_MODVERSION=y
    
    commit 4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream.
    
    This code does not work as stated in the comment.
    
    $(CONFIG_MODVERSIONS) is always empty because it is expanded before
    include/config/auto.conf is included. Hence, 'make modules' with
    CONFIG_MODVERSION=y cannot record the version CRCs.
    
    This has been broken since 2003, commit ("kbuild: Enable modules to be
    build using the "make dir/" syntax"). [1]
    
    [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7
    Cc: linux-stable <stable@vger.kernel.org> # v2.5.71+
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3255c2685239b9c165935f5d72562777631c735a
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Apr 23 16:00:38 2020 +1000

    drivers/macintosh: Fix memleak in windfarm_pm112 driver
    
    commit 93900337b9ac2f4eca427eff6d187be2dc3b5551 upstream.
    
    create_cpu_loop() calls smu_sat_get_sdb_partition() which does
    kmalloc() and returns the allocated buffer. In fact it's called twice,
    and neither buffer is freed.
    
    This results in a memory leak as reported by Erhard:
      unreferenced object 0xc00000047081f840 (size 32):
        comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s)
        hex dump (first 32 bytes):
          c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00  ...........A. ..
          00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00  ...7............
        backtrace:
          [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
          [<000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112]
          [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
          [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
          [<00000000131d8149>] .wf_thread_func+0x114/0x1a0
          [<000000000d54838d>] .kthread+0x13c/0x190
          [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
      unreferenced object 0xc0000004737089f0 (size 16):
        comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s)
        hex dump (first 16 bytes):
          c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00  ...."....U{.....
        backtrace:
          [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
          [<00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112]
          [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
          [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
          [<00000000131d8149>] .wf_thread_func+0x114/0x1a0
          [<000000000d54838d>] .kthread+0x13c/0x190
          [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
    
    Fix it by rearranging the logic so we deal with each buffer
    separately, which then makes it easy to free the buffer once we're
    done with it.
    
    Fixes: ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s")
    Cc: stable@vger.kernel.org # v2.6.16+
    Reported-by: Erhard F. <erhard_f@mailbox.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Tested-by: Erhard F. <erhard_f@mailbox.org>
    Link: https://lore.kernel.org/r/20200423060038.3308530-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7dda6ebb5b30899da6eee8d1d0f554e64e2c2ac2
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Fri Mar 13 12:01:04 2020 +0300

    ARM: tegra: Correct PL310 Auxiliary Control Register initialization
    
    commit 35509737c8f958944e059d501255a0bf18361ba0 upstream.
    
    The PL310 Auxiliary Control Register shouldn't have the "Full line of
    zero" optimization bit being set before L2 cache is enabled. The L2X0
    driver takes care of enabling the optimization by itself.
    
    This patch fixes a noisy error message on Tegra20 and Tegra30 telling
    that cache optimization is erroneously enabled without enabling it for
    the CPU:
    
            L2C-310: enabling full line of zeros but not enabled in Cortex-A9
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Tested-by: Nicolas Chauvet <kwizart@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7827de2fd7f9ee6d55c29aed23cc5a138338354
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon May 4 10:50:17 2020 -0700

    kernel/cpu_pm: Fix uninitted local in cpu_pm
    
    commit b5945214b76a1f22929481724ffd448000ede914 upstream.
    
    cpu_pm_notify() is basically a wrapper of notifier_call_chain().
    notifier_call_chain() doesn't initialize *nr_calls to 0 before it
    starts incrementing it--presumably it's up to the callers to do this.
    
    Unfortunately the callers of cpu_pm_notify() don't init *nr_calls.
    This potentially means you could get too many or two few calls to
    CPU_PM_ENTER_FAILED or CPU_CLUSTER_PM_ENTER_FAILED depending on the
    luck of the stack.
    
    Let's fix this.
    
    Fixes: ab10023e0088 ("cpu_pm: Add cpu power management notifiers")
    Cc: stable@vger.kernel.org
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20200504104917.v6.3.I2d44fc0053d019f239527a4e5829416714b7e299@changeid
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f948036c7f39e08f8c7170e000e466e85579b7c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun May 17 15:37:50 2020 -0400

    sparc64: fix misuses of access_process_vm() in genregs32_[sg]et()
    
    commit 142cd25293f6a7ecbdff4fb0af17de6438d46433 upstream.
    
    We do need access_process_vm() to access the target's reg_window.
    However, access to caller's memory (storing the result in
    genregs32_get(), fetching the new values in case of genregs32_set())
    should be done by normal uaccess primitives.
    
    Fixes: ad4f95764040 ([SPARC64]: Fix user accesses in regset code.)
    Cc: stable@kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c90a2d5693eeecbbb80e328e802a27ef65da42e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun May 17 12:20:40 2020 -0400

    sparc32: fix register window handling in genregs32_[gs]et()
    
    commit cf51e129b96847f969bfb8af1ee1516a01a70b39 upstream.
    
    It needs access_process_vm() if the traced process does not share
    mm with the caller.  Solution is similar to what sparc64 does.
    Note that genregs32_set() is only ever called with pos being 0
    or 32 * sizeof(u32) (the latter - as part of PTRACE_SETREGS
    handling).
    
    Cc: stable@kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c346341a3dc5a6d5ee0174605d664976e4097393
Author: Jonathan Bakker <xc-racer2@live.ca>
Date:   Sat Apr 25 16:10:46 2020 -0700

    pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs
    
    commit f354157a7d184db430c1a564c506434e33b1bec5 upstream.
    
    Currently, for EINT_TYPE GPIOs, the CON and FLTCON registers
    are saved and restored over a suspend/resume cycle.  However, the
    EINT_MASK registers are not.
    
    On S5PV210 at the very least, these registers are not retained over
    suspend, leading to the interrupts remaining masked upon resume and
    therefore no interrupts being triggered for the device.  There should
    be no effect on any SoCs that do retain these registers as theoretically
    we would just be re-writing what was already there.
    
    Fixes: 7ccbc60cd9c2 ("pinctrl: exynos: Handle suspend/resume of GPIO EINT registers")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efb8d8753feb6180d0f845b1cacdf2f587ccf7f1
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Wed May 27 13:26:04 2020 +0200

    power: vexpress: add suppress_bind_attrs to true
    
    commit 73174acc9c75960af2daa7dcbdb9781fc0d135cb upstream.
    
    Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind
    attributes available via the sysfs, so lets be explicit here and use
    ".suppress_bind_attrs = true" to prevent userspace from doing something
    silly.
    
    Link: https://lore.kernel.org/r/20200527112608.3886105-2-anders.roxell@linaro.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc46fcf2ddff780cfb5c923e902bd1116ac00cd5
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue May 5 12:01:54 2020 +0800

    igb: Report speed and duplex as unknown when device is runtime suspended
    
    commit 165ae7a8feb53dc47fb041357e4b253bfc927cf9 upstream.
    
    igb device gets runtime suspended when there's no link partner. We can't
    get correct speed under that state:
    $ cat /sys/class/net/enp3s0/speed
    1000
    
    In addition to that, an error can also be spotted in dmesg:
    [  385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost
    
    Since device can only be runtime suspended when there's no link partner,
    we can skip reading register and let the following logic set speed and
    duplex with correct status.
    
    The more generic approach will be wrap get_link_ksettings() with begin()
    and complete() callbacks. However, for this particular issue, begin()
    calls igb_runtime_resume() , which tries to rtnl_lock() while the lock
    is already hold by upper ethtool layer.
    
    So let's take this approach until the igb_runtime_resume() no longer
    needs to hold rtnl_lock.
    
    CC: stable <stable@vger.kernel.org>
    Suggested-by: Alexander Duyck <alexander.duyck@gmail.com>
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f67f751870f11b4b2b394c4c50840279b07e80c4
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue May 26 10:59:09 2020 -0500

    b43_legacy: Fix connection problem with WPA3
    
    commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
    
    Since the driver was first introduced into the kernel, it has only
    handled the ciphers associated with WEP, WPA, and WPA2. It fails with
    WPA3 even though mac80211 can handle those additional ciphers in software,
    b43legacy did not report that it could handle them. By setting MFP_CAPABLE using
    ieee80211_set_hw(), the problem is fixed.
    
    With this change, b43legacy will handle the ciphers it knows in hardware,
    and let mac80211 handle the others in software. It is not necessary to
    use the module parameter NOHWCRYPT to turn hardware encryption off.
    Although this change essentially eliminates that module parameter,
    I am choosing to keep it for cases where the hardware is broken,
    and software encryption is required for all ciphers.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4646d0032969575499c374bd2fe7798227385fcd
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue May 26 10:59:08 2020 -0500

    b43: Fix connection problem with WPA3
    
    commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
    
    Since the driver was first introduced into the kernel, it has only
    handled the ciphers associated with WEP, WPA, and WPA2. It fails with
    WPA3 even though mac80211 can handle those additional ciphers in software,
    b43 did not report that it could handle them. By setting MFP_CAPABLE using
    ieee80211_set_hw(), the problem is fixed.
    
    With this change, b43 will handle the ciphers it knows in hardware,
    and let mac80211 handle the others in software. It is not necessary to
    use the module parameter NOHWCRYPT to turn hardware encryption off.
    Although this change essentially eliminates that module parameter,
    I am choosing to keep it for cases where the hardware is broken,
    and software encryption is required for all ciphers.
    
    Reported-and-tested-by: Rui Salvaterra <rsalvaterra@gmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7581e7d31ebdc911f7fa76ddf99c89a97e06f88d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Apr 7 14:00:43 2020 -0500

    b43legacy: Fix case where channel status is corrupted
    
    commit ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 upstream.
    
    This patch fixes commit 75388acd0cd8 ("add mac80211-based driver for
    legacy BCM43xx devices")
    
    In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in
    b43legacy is reported. Upon testing, thus problem exists on PPC and
    X86 platforms, is present in the oldest kernel tested (3.2), and
    has been present in the driver since it was first added to the kernel.
    
    The problem is a corrupted channel status received from the device.
    Both the internal card in a PowerBook G4 and the PCMCIA version
    (Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2
    (revision 4 of the 802.11 core) of the chip has been tested. No other
    devices using b43legacy are available for testing.
    
    Various sources of the problem were considered. Buffer overrun and
    other sources of corruption within the driver were rejected because
    the faulty channel status is always the same, not a random value.
    It was concluded that the faulty data is coming from the device, probably
    due to a firmware bug. As that source is not available, the driver
    must take appropriate action to recover.
    
    At present, the driver reports the error, and them continues to process
    the bad packet. This is believed that to be a mistake, and the correct
    action is to drop the correpted packet.
    
    Fixes: 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices")
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Reported-and-tested by: F. Erhard <erhard_f@mailbox.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e70f204f62f2198f3b88932c71e5ac29a5fbb10
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Tue Dec 10 04:15:48 2019 +0100

    media: go7007: fix a miss of snd_card_free
    
    commit 9453264ef58638ce8976121ac44c07a3ef375983 upstream.
    
    go7007_snd_init() misses a snd_card_free() in an error path.
    Add the missed call to fix it.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    [Salvatore Bonaccorso: Adjust context for backport to versions which do
    not contain c0decac19da3 ("media: use strscpy() instead of strlcpy()")
    and ba78170ef153 ("media: go7007: Fix misuse of strscpy")]
    Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd16f8d4869552b8224c03393370ef1ccb6a12c5
Author: Christian Lamparter <chunkeey@gmail.com>
Date:   Tue May 5 10:42:09 2020 +0300

    carl9170: remove P2P_GO support
    
    commit b14fba7ebd04082f7767a11daea7f12f3593de22 upstream.
    
    This patch follows up on a bug-report by Frank Schäfer that
    discovered P2P GO wasn't working with wpa_supplicant.
    This patch removes part of the broken P2P GO support but
    keeps the vif switchover code in place.
    
    Cc: <stable@vger.kernel.org>
    Link: <https://lkml.kernel.org/r/3a9d86b6-744f-e670-8792-9167257edef8@googlemail.com>
    Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com>
    Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200425092811.9494-1-chunkeey@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 831e063654bca5b43245505de3e140d97e7b8e7e
Author: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Date:   Fri May 15 13:31:27 2020 +0900

    e1000e: Relax condition to trigger reset for ME workaround
    
    commit d601afcae2febc49665008e9a79e701248d56c50 upstream.
    
    It's an error if the value of the RX/TX tail descriptor does not match
    what was written. The error condition is true regardless the duration
    of the interference from ME. But the driver only performs the reset if
    E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have
    transpired. The extra condition can lead to inconsistency between the
    state of hardware as expected by the driver.
    
    Fix this by dropping the check for number of delay iterations.
    
    While at it, also make __ew32_prepare() static as it's not used
    anywhere else.
    
    CC: stable <stable@vger.kernel.org>
    Signed-off-by: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
    Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08727720bb441e83a5117d25744d5ca2156c7553
Author: Ashok Raj <ashok.raj@intel.com>
Date:   Fri Mar 27 14:16:15 2020 -0700

    PCI: Program MPS for RCiEP devices
    
    commit aa0ce96d72dd2e1b0dfd0fb868f82876e7790878 upstream.
    
    Root Complex Integrated Endpoints (RCiEPs) do not have an upstream bridge,
    so pci_configure_mps() previously ignored them, which may result in reduced
    performance.
    
    Instead, program the Max_Payload_Size of RCiEPs to the maximum supported
    value (unless it is limited for the PCIE_BUS_PEER2PEER case).  This also
    affects the subsequent programming of Max_Read_Request_Size because Linux
    programs MRRS based on the MPS value.
    
    Fixes: 9dae3a97297f ("PCI: Move MPS configuration check to pci_configure_device()")
    Link: https://lore.kernel.org/r/1585343775-4019-1-git-send-email-ashok.raj@intel.com
    Tested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Ashok Raj <ashok.raj@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6754baabb890eed09f30c84016242c52a6c2d2d4
Author: Giuliano Procida <gprocida@google.com>
Date:   Thu Jun 18 19:30:22 2020 +0100

    blk-mq: move blk_mq_update_nr_hw_queues synchronize_rcu call
    
    This fixes the
    4.9 backport commit f530afb974c2e82047bd6220303a2dbe30eff304
    which was
    upstream commit f5bbbbe4d63577026f908a809f22f5fd5a90ea1f.
    
    The upstream commit added a call to synchronize_rcu to
    _blk_mq_update_nr_hw_queues, just after freezing queues.
    
    In the backport this landed (in blk_mq_update_nr_hw_queues instead),
    just after unfreezeing queues.
    
    This commit moves the call to its intended place.
    
    Fixes: f530afb974c2 ("blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter")
    Signed-off-by: Giuliano Procida <gprocida@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed80f400f6dd6a9228ef297a00803ede191e3007
Author: Omar Sandoval <osandov@fb.com>
Date:   Thu Apr 16 14:46:12 2020 -0700

    btrfs: fix error handling when submitting direct I/O bio
    
    [ Upstream commit 6d3113a193e3385c72240096fe397618ecab6e43 ]
    
    In btrfs_submit_direct_hook(), if a direct I/O write doesn't span a RAID
    stripe or chunk, we submit orig_bio without cloning it. In this case, we
    don't increment pending_bios. Then, if btrfs_submit_dio_bio() fails, we
    decrement pending_bios to -1, and we never complete orig_bio. Fix it by
    initializing pending_bios to 1 instead of incrementing later.
    
    Fixing this exposes another bug: we put orig_bio prematurely and then
    put it again from end_io. Fix it by not putting orig_bio.
    
    After this change, pending_bios is really more of a reference count, but
    I'll leave that cleanup separate to keep the fix small.
    
    Fixes: e65e15355429 ("btrfs: fix panic caused by direct IO")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86498641bfff80f65ce848db03bd3cd462db844c
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed May 6 11:31:40 2020 -0700

    ext4: fix race between ext4_sync_parent() and rename()
    
    commit 08adf452e628b0e2ce9a01048cfbec52353703d7 upstream.
    
    'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is
    broken because without d_lock, d_parent can be concurrently changed due
    to a rename().  Then if the old directory is immediately deleted, old
    d_parent->inode can be NULL.  That causes a NULL dereference in igrab().
    
    To fix this, use dget_parent() to safely grab a reference to the parent
    dentry, which pins the inode.  This also eliminates the need to use
    d_find_any_alias() other than for the initial inode, as we no longer
    throw away the dentry at each step.
    
    This is an extremely hard race to hit, but it is possible.  Adding a
    udelay() in between the reads of ->d_parent and its ->d_inode makes it
    reproducible on a no-journal filesystem using the following program:
    
        #include <fcntl.h>
        #include <unistd.h>
    
        int main()
        {
            if (fork()) {
                for (;;) {
                    mkdir("dir1", 0700);
                    int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC);
                    write(fd, "X", 1);
                    close(fd);
                }
            } else {
                mkdir("dir2", 0700);
                for (;;) {
                    rename("dir1/file", "dir2/file");
                    rmdir("dir1");
                }
            }
        }
    
    Fixes: d59729f4e794 ("ext4: fix races in ext4_sync_parent()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20200506183140.541194-1-ebiggers@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b61a98f7173bff9ed2cf982619222d3608fac2d1
Author: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Date:   Mon Apr 20 19:39:59 2020 -0700

    ext4: fix EXT_MAX_EXTENT/INDEX to check for zeroed eh_max
    
    commit c36a71b4e35ab35340facdd6964a00956b9fef0a upstream.
    
    If eh->eh_max is 0, EXT_MAX_EXTENT/INDEX would evaluate to unsigned
    (-1) resulting in illegal memory accesses. Although there is no
    consistent repro, we see that generic/019 sometimes crashes because of
    this bug.
    
    Ran gce-xfstests smoke and verified that there were no regressions.
    
    Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
    Link: https://lore.kernel.org/r/20200421023959.20879-2-harshadshirwadkar@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b9d238c8a534a0374a56c771c7791cb18f3fbed
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Tue Apr 14 10:01:31 2020 +0200

    evm: Fix possible memory leak in evm_calc_hmac_or_hash()
    
    commit 0c4395fb2aa77341269ea619c5419ea48171883f upstream.
    
    Don't immediately return if the signature is portable and security.ima is
    not present. Just set error so that memory allocated is freed before
    returning from evm_calc_hmac_or_hash().
    
    Fixes: 50b977481fce9 ("EVM: Add support for portable signature format")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63125a4a45284122064495ac4a3336b17735b252
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Wed Jun 3 17:08:20 2020 +0200

    ima: Directly assign the ima_default_policy pointer to ima_rules
    
    commit 067a436b1b0aafa593344fddd711a755a58afb3b upstream.
    
    This patch prevents the following oops:
    
    [   10.771813] BUG: kernel NULL pointer dereference, address: 0000000000000
    [...]
    [   10.779790] RIP: 0010:ima_match_policy+0xf7/0xb80
    [...]
    [   10.798576] Call Trace:
    [   10.798993]  ? ima_lsm_policy_change+0x2b0/0x2b0
    [   10.799753]  ? inode_init_owner+0x1a0/0x1a0
    [   10.800484]  ? _raw_spin_lock+0x7a/0xd0
    [   10.801592]  ima_must_appraise.part.0+0xb6/0xf0
    [   10.802313]  ? ima_fix_xattr.isra.0+0xd0/0xd0
    [   10.803167]  ima_must_appraise+0x4f/0x70
    [   10.804004]  ima_post_path_mknod+0x2e/0x80
    [   10.804800]  do_mknodat+0x396/0x3c0
    
    It occurs when there is a failure during IMA initialization, and
    ima_init_policy() is not called. IMA hooks still call ima_match_policy()
    but ima_rules is NULL. This patch prevents the crash by directly assigning
    the ima_default_policy pointer to ima_rules when ima_rules is defined. This
    wouldn't alter the existing behavior, as ima_rules is always set at the end
    of ima_init_policy().
    
    Cc: stable@vger.kernel.org # 3.7.x
    Fixes: 07f6a79415d7d ("ima: add appraise action keywords and default rules")
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 446e3919b51043f722f7c5b196798997ce900ae0
Author: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
Date:   Tue Apr 28 09:30:10 2020 +0200

    ima: Fix ima digest hash table key calculation
    
    commit 1129d31b55d509f15e72dc68e4b5c3a4d7b4da8d upstream.
    
    Function hash_long() accepts unsigned long, while currently only one byte
    is passed from ima_hash_key(), which calculates a key for ima_htable.
    
    Given that hashing the digest does not give clear benefits compared to
    using the digest itself, remove hash_long() and return the modulus
    calculated on the first two bytes of the digest with the number of slots.
    Also reduce the depth of the hash table by doubling the number of slots.
    
    Cc: stable@vger.kernel.org
    Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
    Co-developed-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
    Acked-by: David.Laight@aculab.com (big endian system concerns)
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d93d7bd61072a03dde173d36ae5815488a585fc0
Author: Andrea Arcangeli <aarcange@redhat.com>
Date:   Wed May 27 19:06:24 2020 -0400

    mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()
    
    commit c444eb564fb16645c172d550359cb3d75fe8a040 upstream.
    
    Write protect anon page faults require an accurate mapcount to decide
    if to break the COW or not. This is implemented in the THP path with
    reuse_swap_page() ->
    page_trans_huge_map_swapcount()/page_trans_huge_mapcount().
    
    If the COW triggers while the other processes sharing the page are
    under a huge pmd split, to do an accurate reading, we must ensure the
    mapcount isn't computed while it's being transferred from the head
    page to the tail pages.
    
    reuse_swap_cache() already runs serialized by the page lock, so it's
    enough to add the page lock around __split_huge_pmd_locked too, in
    order to add the missing serialization.
    
    Note: the commit in "Fixes" is just to facilitate the backporting,
    because the code before such commit didn't try to do an accurate THP
    mapcount calculation and it instead used the page_count() to decide if
    to COW or not. Both the page_count and the pin_count are THP-wide
    refcounts, so they're inaccurate if used in
    reuse_swap_page(). Reverting such commit (besides the unrelated fix to
    the local anon_vma assignment) would have also opened the window for
    memory corruption side effects to certain workloads as documented in
    such commit header.
    
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Suggested-by: Jann Horn <jannh@google.com>
    Reported-by: Jann Horn <jannh@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Fixes: 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults")
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e36fae9ac971377e9c640d684192e816a953bb8
Author: Marcos Paulo de Souza <mpdesouza@suse.com>
Date:   Sun May 10 23:15:07 2020 -0300

    btrfs: send: emit file capabilities after chown
    
    commit 89efda52e6b6930f80f5adda9c3c9edfb1397191 upstream.
    
    Whenever a chown is executed, all capabilities of the file being touched
    are lost.  When doing incremental send with a file with capabilities,
    there is a situation where the capability can be lost on the receiving
    side. The sequence of actions bellow shows the problem:
    
      $ mount /dev/sda fs1
      $ mount /dev/sdb fs2
    
      $ touch fs1/foo.bar
      $ setcap cap_sys_nice+ep fs1/foo.bar
      $ btrfs subvolume snapshot -r fs1 fs1/snap_init
      $ btrfs send fs1/snap_init | btrfs receive fs2
    
      $ chgrp adm fs1/foo.bar
      $ setcap cap_sys_nice+ep fs1/foo.bar
    
      $ btrfs subvolume snapshot -r fs1 fs1/snap_complete
      $ btrfs subvolume snapshot -r fs1 fs1/snap_incremental
    
      $ btrfs send fs1/snap_complete | btrfs receive fs2
      $ btrfs send -p fs1/snap_init fs1/snap_incremental | btrfs receive fs2
    
    At this point, only a chown was emitted by "btrfs send" since only the
    group was changed. This makes the cap_sys_nice capability to be dropped
    from fs2/snap_incremental/foo.bar
    
    To fix that, only emit capabilities after chown is emitted. The current
    code first checks for xattrs that are new/changed, emits them, and later
    emit the chown. Now, __process_new_xattr skips capabilities, letting
    only finish_inode_if_needed to emit them, if they exist, for the inode
    being processed.
    
    This behavior was being worked around in "btrfs receive" side by caching
    the capability and only applying it after chown. Now, xattrs are only
    emmited _after_ chown, making that workaround not needed anymore.
    
    Link: https://github.com/kdave/btrfs-progs/issues/202
    CC: stable@vger.kernel.org # 4.4+
    Suggested-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42b548b9e9248ffd2f378bd4cbcb31d692ef3280
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Thu May 28 13:20:46 2020 -0500

    cpuidle: Fix three reference count leaks
    
    [ Upstream commit c343bf1ba5efcbf2266a1fe3baefec9cc82f867f ]
    
    kobject_init_and_add() takes reference even when it fails.
    If this function returns an error, kobject_put() must be called to
    properly clean up the memory associated with the object.
    
    Previous commit "b8eb718348b8" fixed a similar problem.
    
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    [ rjw: Subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6043872c76058256b0ee80511076f00ba9f9020
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri May 29 16:11:51 2020 +0300

    spi: dw: Return any value retrieved from the dma_transfer callback
    
    [ Upstream commit f0410bbf7d0fb80149e3b17d11d31f5b5197873e ]
    
    DW APB SSI DMA-part of the driver may need to perform the requested
    SPI-transfer synchronously. In that case the dma_transfer() callback
    will return 0 as a marker of the SPI transfer being finished so the
    SPI core doesn't need to wait and may proceed with the SPI message
    trasnfers pumping procedure. This will be needed to fix the problem
    when DMA transactions are finished, but there is still data left in
    the SPI Tx/Rx FIFOs being sent/received. But for now make dma_transfer
    to return 1 as the normal dw_spi_transfer_one() method.
    
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
    Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
    Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Feng Tang <feng.tang@intel.com>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Cc: devicetree@vger.kernel.org
    Link: https://lore.kernel.org/r/20200529131205.31838-3-Sergey.Semin@baikalelectronics.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 109f1be271d6b5eaa46cdb7cd355ea14d5187068
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Tue May 26 18:22:01 2020 +0800

    mmc: sdhci-esdhc-imx: fix the mask for tuning start point
    
    [ Upstream commit 1194be8c949b8190b2882ad8335a5d98aa50c735 ]
    
    According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
    TUNING_START_TAP, bit[7] of this register is to disable the command
    CRC check for standard tuning. So fix it here.
    
    Fixes: d87fc9663688 ("mmc: sdhci-esdhc-imx: support setting tuning start point")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Link: https://lore.kernel.org/r/1590488522-9292-1-git-send-email-haibo.chen@nxp.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74b775b3ba34879cc24e081bda9e8395eaf27156
Author: Xie XiuQi <xiexiuqi@huawei.com>
Date:   Tue May 5 10:45:21 2020 +0800

    ixgbe: fix signed-integer-overflow warning
    
    [ Upstream commit 3b70683fc4d68f5d915d9dc7e5ba72c732c7315c ]
    
    ubsan report this warning, fix it by adding a unsigned suffix.
    
    UBSAN: signed-integer-overflow in
    drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:2246:26
    65535 * 65537 cannot be represented in type 'int'
    CPU: 21 PID: 7 Comm: kworker/u256:0 Not tainted 5.7.0-rc3-debug+ #39
    Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 03/27/2020
    Workqueue: ixgbe ixgbe_service_task [ixgbe]
    Call trace:
     dump_backtrace+0x0/0x3f0
     show_stack+0x28/0x38
     dump_stack+0x154/0x1e4
     ubsan_epilogue+0x18/0x60
     handle_overflow+0xf8/0x148
     __ubsan_handle_mul_overflow+0x34/0x48
     ixgbe_fc_enable_generic+0x4d0/0x590 [ixgbe]
     ixgbe_service_task+0xc20/0x1f78 [ixgbe]
     process_one_work+0x8f0/0xf18
     worker_thread+0x430/0x6d0
     kthread+0x218/0x238
     ret_from_fork+0x10/0x18
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf14387351b94c376b6c55ee87b00b3dd3bb7300
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Apr 14 18:14:13 2020 +0200

    staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core
    
    [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ]
    
    Using a fixed 1s timeout for all commands is a bit problematic.
    
    For some commands it means waiting longer than needed for the timeout to
    expire, which may not a big issue, but still. For other commands, like for
    an erase (CMD38) that uses a R1B response, may require longer timeouts than
    1s. In these cases, we may end up treating the command as it failed, while
    it just needed some more time to complete successfully.
    
    Fix the problem by respecting the cmd->busy_timeout, which is provided by
    the mmc core.
    
    Cc: Rui Miguel Silva <rmfrfs@gmail.com>
    Cc: Johan Hovold <johan@kernel.org>
    Cc: Alex Elder <elder@kernel.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: greybus-dev@lists.linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf4c788ecebbe11edf59f09e62893e49d1037874
Author: YuanJunQing <yuanjunqing66@163.com>
Date:   Wed May 27 14:11:30 2020 +0800

    MIPS: Fix IRQ tracing when call handle_fpe() and handle_msa_fpe()
    
    [ Upstream commit 31e1b3efa802f97a17628dde280006c4cee4ce5e ]
    
    Register "a1" is unsaved in this function,
     when CONFIG_TRACE_IRQFLAGS is enabled,
     the TRACE_IRQS_OFF macro will call trace_hardirqs_off(),
     and this may change register "a1".
     The changed register "a1" as argument will be send
     to do_fpe() and do_msa_fpe().
    
    Signed-off-by: YuanJunQing <yuanjunqing66@163.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97aad0ad757b65300870b2ac7974fb761445ff44
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Tue May 26 17:21:12 2020 +0800

    PCI: Don't disable decoding when mmio_always_on is set
    
    [ Upstream commit b6caa1d8c80cb71b6162cb1f1ec13aa655026c9f ]
    
    Don't disable MEM/IO decoding when a device have both non_compliant_bars
    and mmio_always_on.
    
    That would allow us quirk devices with junk in BARs but can't disable
    their decoding.
    
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Acked-by: Bjorn Helgaas <helgaas@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c8ca9eeeedac951e41f0e6ed2174a95ba141430
Author: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date:   Tue May 26 14:27:51 2020 +0200

    macvlan: Skip loopback packets in RX handler
    
    [ Upstream commit 81f3dc9349ce0bf7b8447f147f45e70f0a5b36a6 ]
    
    Ignore loopback-originatig packets soon enough and don't try to process L2
    header where it doesn't exist. The very similar br_handle_frame() in bridge
    code performs exactly the same check.
    
    This is an example of such ICMPv6 packet:
    
    skb len=96 headroom=40 headlen=96 tailroom=56
    mac=(40,0) net=(40,40) trans=80
    shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
    csum(0xae2e9a2f ip_summed=1 complete_sw=0 valid=0 level=0)
    hash(0xc97ebd88 sw=1 l4=1) proto=0x86dd pkttype=5 iif=24
    dev name=etha01.212 feat=0x0x0000000040005000
    skb headroom: 00000000: 00 7c 86 52 84 88 ff ff 00 00 00 00 00 00 08 00
    skb headroom: 00000010: 45 00 00 9e 5d 5c 40 00 40 11 33 33 00 00 00 01
    skb headroom: 00000020: 02 40 43 80 00 00 86 dd
    skb linear:   00000000: 60 09 88 bd 00 38 3a ff fe 80 00 00 00 00 00 00
    skb linear:   00000010: 00 40 43 ff fe 80 00 00 ff 02 00 00 00 00 00 00
    skb linear:   00000020: 00 00 00 00 00 00 00 01 86 00 61 00 40 00 00 2d
    skb linear:   00000030: 00 00 00 00 00 00 00 00 03 04 40 e0 00 00 01 2c
    skb linear:   00000040: 00 00 00 78 00 00 00 00 fd 5f 42 68 23 87 a8 81
    skb linear:   00000050: 00 00 00 00 00 00 00 00 01 01 02 40 43 80 00 00
    skb tailroom: 00000000: ...
    skb tailroom: 00000010: ...
    skb tailroom: 00000020: ...
    skb tailroom: 00000030: ...
    
    Call Trace, how it happens exactly:
     ...
     macvlan_handle_frame+0x321/0x425 [macvlan]
     ? macvlan_forward_source+0x110/0x110 [macvlan]
     __netif_receive_skb_core+0x545/0xda0
     ? enqueue_task_fair+0xe5/0x8e0
     ? __netif_receive_skb_one_core+0x36/0x70
     __netif_receive_skb_one_core+0x36/0x70
     process_backlog+0x97/0x140
     net_rx_action+0x1eb/0x350
     ? __hrtimer_run_queues+0x136/0x2e0
     __do_softirq+0xe3/0x383
     do_softirq_own_stack+0x2a/0x40
     </IRQ>
     do_softirq.part.4+0x4e/0x50
     netif_rx_ni+0x60/0xd0
     dev_loopback_xmit+0x83/0xf0
     ip6_finish_output2+0x575/0x590 [ipv6]
     ? ip6_cork_release.isra.1+0x64/0x90 [ipv6]
     ? __ip6_make_skb+0x38d/0x680 [ipv6]
     ? ip6_output+0x6c/0x140 [ipv6]
     ip6_output+0x6c/0x140 [ipv6]
     ip6_send_skb+0x1e/0x60 [ipv6]
     rawv6_sendmsg+0xc4b/0xe10 [ipv6]
     ? proc_put_long+0xd0/0xd0
     ? rw_copy_check_uvector+0x4e/0x110
     ? sock_sendmsg+0x36/0x40
     sock_sendmsg+0x36/0x40
     ___sys_sendmsg+0x2b6/0x2d0
     ? proc_dointvec+0x23/0x30
     ? addrconf_sysctl_forward+0x8d/0x250 [ipv6]
     ? dev_forward_change+0x130/0x130 [ipv6]
     ? _raw_spin_unlock+0x12/0x30
     ? proc_sys_call_handler.isra.14+0x9f/0x110
     ? __call_rcu+0x213/0x510
     ? get_max_files+0x10/0x10
     ? trace_hardirqs_on+0x2c/0xe0
     ? __sys_sendmsg+0x63/0xa0
     __sys_sendmsg+0x63/0xa0
     do_syscall_64+0x6c/0x1e0
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04c01ac27d08fdf8933ecdf3e74fed9737e6fb55
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Wed May 20 14:32:02 2020 +1000

    m68k: mac: Don't call via_flush_cache() on Mac IIfx
    
    [ Upstream commit bcc44f6b74106b31f0b0408b70305a40360d63b7 ]
    
    There is no VIA2 chip on the Mac IIfx, so don't call via_flush_cache().
    This avoids a boot crash which appeared in v5.4.
    
    printk: console [ttyS0] enabled
    printk: bootconsole [debug0] disabled
    printk: bootconsole [debug0] disabled
    Calibrating delay loop... 9.61 BogoMIPS (lpj=48064)
    pid_max: default: 32768 minimum: 301
    Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
    Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
    devtmpfs: initialized
    random: get_random_u32 called from bucket_table_alloc.isra.27+0x68/0x194 with crng_init=0
    clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
    futex hash table entries: 256 (order: -1, 3072 bytes, linear)
    NET: Registered protocol family 16
    Data read fault at 0x00000000 in Super Data (pc=0x8a6a)
    BAD KERNEL BUSERR
    Oops: 00000000
    Modules linked in:
    PC: [<00008a6a>] via_flush_cache+0x12/0x2c
    SR: 2700  SP: 01c1fe3c  a2: 01c24000
    d0: 00001119    d1: 0000000c    d2: 00012000    d3: 0000000f
    d4: 01c06840    d5: 00033b92    a0: 00000000    a1: 00000000
    Process swapper (pid: 1, task=01c24000)
    Frame format=B ssw=0755 isc=0200 isb=fff7 daddr=00000000 dobuf=01c1fed0
    baddr=00008a6e dibuf=0000004e ver=f
    Stack from 01c1fec4:
            01c1fed0 00007d7e 00010080 01c1fedc 0000792e 00000001 01c1fef4 00006b40
            01c80000 00040000 00000006 00000003 01c1ff1c 004a545e 004ff200 00040000
            00000000 00000003 01c06840 00033b92 004a5410 004b6c88 01c1ff84 000021e2
            00000073 00000003 01c06840 00033b92 0038507a 004bb094 004b6ca8 004b6c88
            004b6ca4 004b6c88 000021ae 00020002 00000000 01c0685d 00000000 01c1ffb4
            0049f938 00409c85 01c06840 0045bd40 00000073 00000002 00000002 00000000
    Call Trace: [<00007d7e>] mac_cache_card_flush+0x12/0x1c
     [<00010080>] fix_dnrm+0x2/0x18
     [<0000792e>] cache_push+0x46/0x5a
     [<00006b40>] arch_dma_prep_coherent+0x60/0x6e
     [<00040000>] switched_to_dl+0x76/0xd0
     [<004a545e>] dma_atomic_pool_init+0x4e/0x188
     [<00040000>] switched_to_dl+0x76/0xd0
     [<00033b92>] parse_args+0x0/0x370
     [<004a5410>] dma_atomic_pool_init+0x0/0x188
     [<000021e2>] do_one_initcall+0x34/0x1be
     [<00033b92>] parse_args+0x0/0x370
     [<0038507a>] strcpy+0x0/0x1e
     [<000021ae>] do_one_initcall+0x0/0x1be
     [<00020002>] do_proc_dointvec_conv+0x54/0x74
     [<0049f938>] kernel_init_freeable+0x126/0x190
     [<0049f94c>] kernel_init_freeable+0x13a/0x190
     [<004a5410>] dma_atomic_pool_init+0x0/0x188
     [<00041798>] complete+0x0/0x3c
     [<000b9b0c>] kfree+0x0/0x20a
     [<0038df98>] schedule+0x0/0xd0
     [<0038d604>] kernel_init+0x0/0xda
     [<0038d610>] kernel_init+0xc/0xda
     [<0038d604>] kernel_init+0x0/0xda
     [<00002d38>] ret_from_kernel_thread+0xc/0x14
    Code: 0000 2079 0048 10da 2279 0048 10c8 d3c8 <1011> 0200 fff7 1280 d1f9 0048 10c8 1010 0000 0008 1080 4e5e 4e75 4e56 0000 2039
    Disabling lock debugging due to kernel taint
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    
    Thanks to Stan Johnson for capturing the console log and running git
    bisect.
    
    Git bisect said commit 8e3a68fb55e0 ("dma-mapping: make
    dma_atomic_pool_init self-contained") is the first "bad" commit. I don't
    know why. Perhaps mach_l2_flush first became reachable with that commit.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Cc: Joshua Thompson <funaho@jurai.org>
    Link: https://lore.kernel.org/r/b8bbeef197d6b3898e82ed0d231ad08f575a4b34.1589949122.git.fthain@telegraphics.com.au
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eeb233a0f5e48fde8f2ac3f9347daadc7563d480
Author: Arvind Sankar <nivedita@alum.mit.edu>
Date:   Sat Feb 29 18:11:20 2020 -0500

    x86/mm: Stop printing BRK addresses
    
    [ Upstream commit 67d631b7c05eff955ccff4139327f0f92a5117e5 ]
    
    This currently leaks kernel physical addresses into userspace.
    
    Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Kees Cook <keescook@chromium.org>
    Acked-by: Dave Hansen <dave.hansen@intel.com>
    Link: https://lkml.kernel.org/r/20200229231120.1147527-1-nivedita@alum.mit.edu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b935463db5ed883eeaff0c01b775e8f10e544982
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Thu May 21 17:07:22 2020 +0300

    mips: Add udelay lpj numbers adjustment
    
    [ Upstream commit ed26aacfb5f71eecb20a51c4467da440cb719d66 ]
    
    Loops-per-jiffies is a special number which represents a number of
    noop-loop cycles per CPU-scheduler quantum - jiffies. As you
    understand aside from CPU-specific implementation it depends on
    the CPU frequency. So when a platform has the CPU frequency fixed,
    we have no problem and the current udelay interface will work
    just fine. But as soon as CPU-freq driver is enabled and the cores
    frequency changes, we'll end up with distorted udelay's. In order
    to fix this we have to accordinly adjust the per-CPU udelay_val
    (the same as the global loops_per_jiffy) number. This can be done
    in the CPU-freq transition event handler. We subscribe to that event
    in the MIPS arch time-inititalization method.
    
    Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
    Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Paul Burton <paulburton@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: devicetree@vger.kernel.org
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93b6bebee07976327189940a17ecfd626ba57f09
Author: Arvind Sankar <nivedita@alum.mit.edu>
Date:   Fri Feb 7 16:49:26 2020 -0500

    x86/boot: Correct relocation destination on old linkers
    
    [ Upstream commit 5214028dd89e49ba27007c3ee475279e584261f0 ]
    
    For the 32-bit kernel, as described in
    
      6d92bc9d483a ("x86/build: Build compressed x86 kernels as PIE"),
    
    pre-2.26 binutils generates R_386_32 relocations in PIE mode. Since the
    startup code does not perform relocation, any reloc entry with R_386_32
    will remain as 0 in the executing code.
    
    Commit
    
      974f221c84b0 ("x86/boot: Move compressed kernel to the end of the
                     decompression buffer")
    
    added a new symbol _end but did not mark it hidden, which doesn't give
    the correct offset on older linkers. This causes the compressed kernel
    to be copied beyond the end of the decompression buffer, rather than
    flush against it. This region of memory may be reserved or already
    allocated for other purposes by the bootloader.
    
    Mark _end as hidden to fix. This changes the relocation from R_386_32 to
    R_386_RELATIVE even on the pre-2.26 binutils.
    
    For 64-bit, this is not strictly necessary, as the 64-bit kernel is only
    built as PIE if the linker supports -z noreloc-overflow, which implies
    binutils-2.27+, but for consistency, mark _end as hidden here too.
    
    The below illustrates the before/after impact of the patch using
    binutils-2.25 and gcc-4.6.4 (locally compiled from source) and QEMU.
    
      Disassembly before patch:
        48:   8b 86 60 02 00 00       mov    0x260(%esi),%eax
        4e:   2d 00 00 00 00          sub    $0x0,%eax
                              4f: R_386_32    _end
      Disassembly after patch:
        48:   8b 86 60 02 00 00       mov    0x260(%esi),%eax
        4e:   2d 00 f0 76 00          sub    $0x76f000,%eax
                              4f: R_386_RELATIVE      *ABS*
    
    Dump from extract_kernel before patch:
            early console in extract_kernel
            input_data: 0x0207c098 <--- this is at output + init_size
            input_len: 0x0074fef1
            output: 0x01000000
            output_len: 0x00fa63d0
            kernel_total_size: 0x0107c000
            needed_size: 0x0107c000
    
    Dump from extract_kernel after patch:
            early console in extract_kernel
            input_data: 0x0190d098 <--- this is at output + init_size - _end
            input_len: 0x0074fef1
            output: 0x01000000
            output_len: 0x00fa63d0
            kernel_total_size: 0x0107c000
            needed_size: 0x0107c000
    
    Fixes: 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the decompression buffer")
    Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20200207214926.3564079-1-nivedita@alum.mit.edu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33c2268e8ccd4351a95e434cf52b46594b58dbb1
Author: Pali Rohár <pali@kernel.org>
Date:   Fri May 15 09:59:24 2020 +0200

    mwifiex: Fix memory corruption in dump_station
    
    [ Upstream commit 3aa42bae9c4d1641aeb36f1a8585cd1d506cf471 ]
    
    The mwifiex_cfg80211_dump_station() uses static variable for iterating
    over a linked list of all associated stations (when the driver is in UAP
    role). This has a race condition if .dump_station is called in parallel
    for multiple interfaces. This corruption can be triggered by registering
    multiple SSIDs and calling, in parallel for multiple interfaces
        iw dev <iface> station dump
    
    [16750.719775] Unable to handle kernel paging request at virtual address dead000000000110
    ...
    [16750.899173] Call trace:
    [16750.901696]  mwifiex_cfg80211_dump_station+0x94/0x100 [mwifiex]
    [16750.907824]  nl80211_dump_station+0xbc/0x278 [cfg80211]
    [16750.913160]  netlink_dump+0xe8/0x320
    [16750.916827]  netlink_recvmsg+0x1b4/0x338
    [16750.920861]  ____sys_recvmsg+0x7c/0x2b0
    [16750.924801]  ___sys_recvmsg+0x70/0x98
    [16750.928564]  __sys_recvmsg+0x58/0xa0
    [16750.932238]  __arm64_sys_recvmsg+0x28/0x30
    [16750.936453]  el0_svc_common.constprop.3+0x90/0x158
    [16750.941378]  do_el0_svc+0x74/0x90
    [16750.944784]  el0_sync_handler+0x12c/0x1a8
    [16750.948903]  el0_sync+0x114/0x140
    [16750.952312] Code: f9400003 f907f423 eb02007f 54fffd60 (b9401060)
    [16750.958583] ---[ end trace c8ad181c2f4b8576 ]---
    
    This patch drops the use of the static iterator, and instead every time
    the function is called iterates to the idx-th position of the
    linked-list.
    
    It would be better to convert the code not to use linked list for
    associated stations storage (since the chip has a limited number of
    associated stations anyway - it could just be an array). Such a change
    may be proposed in the future. In the meantime this patch can backported
    into stable kernels in this simple form.
    
    Fixes: 8baca1a34d4c ("mwifiex: dump station support in uap mode")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200515075924.13841-1-pali@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f78833e82a6de3e629a6b2100663ca0d451e172
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 13 12:39:51 2020 +0300

    rtlwifi: Fix a double free in _rtl_usb_tx_urb_setup()
    
    [ Upstream commit beb12813bc75d4a23de43b85ad1c7cb28d27631e ]
    
    Seven years ago we tried to fix a leak but actually introduced a double
    free instead.  It was an understandable mistake because the code was a
    bit confusing and the free was done in the wrong place.  The "skb"
    pointer is freed in both _rtl_usb_tx_urb_setup() and _rtl_usb_transmit().
    The free belongs _rtl_usb_transmit() instead of _rtl_usb_tx_urb_setup()
    and I've cleaned the code up a bit to hopefully make it more clear.
    
    Fixes: 36ef0b473fbf ("rtlwifi: usb: add missing freeing of skbuff")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200513093951.GD347693@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e9b57c4a2445f1174306a26e4ebe732c1ef2fae
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Sat Apr 4 23:57:09 2020 +0200

    md: don't flush workqueue unconditionally in md_open
    
    [ Upstream commit f6766ff6afff70e2aaf39e1511e16d471de7c3ae ]
    
    We need to check mddev->del_work before flush workqueu since the purpose
    of flush is to ensure the previous md is disappeared. Otherwise the similar
    deadlock appeared if LOCKDEP is enabled, it is due to md_open holds the
    bdev->bd_mutex before flush workqueue.
    
    kernel: [  154.522645] ======================================================
    kernel: [  154.522647] WARNING: possible circular locking dependency detected
    kernel: [  154.522650] 5.6.0-rc7-lp151.27-default #25 Tainted: G           O
    kernel: [  154.522651] ------------------------------------------------------
    kernel: [  154.522653] mdadm/2482 is trying to acquire lock:
    kernel: [  154.522655] ffff888078529128 ((wq_completion)md_misc){+.+.}, at: flush_workqueue+0x84/0x4b0
    kernel: [  154.522673]
    kernel: [  154.522673] but task is already holding lock:
    kernel: [  154.522675] ffff88804efa9338 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x79/0x590
    kernel: [  154.522691]
    kernel: [  154.522691] which lock already depends on the new lock.
    kernel: [  154.522691]
    kernel: [  154.522694]
    kernel: [  154.522694] the existing dependency chain (in reverse order) is:
    kernel: [  154.522696]
    kernel: [  154.522696] -> #4 (&bdev->bd_mutex){+.+.}:
    kernel: [  154.522704]        __mutex_lock+0x87/0x950
    kernel: [  154.522706]        __blkdev_get+0x79/0x590
    kernel: [  154.522708]        blkdev_get+0x65/0x140
    kernel: [  154.522709]        blkdev_get_by_dev+0x2f/0x40
    kernel: [  154.522716]        lock_rdev+0x3d/0x90 [md_mod]
    kernel: [  154.522719]        md_import_device+0xd6/0x1b0 [md_mod]
    kernel: [  154.522723]        new_dev_store+0x15e/0x210 [md_mod]
    kernel: [  154.522728]        md_attr_store+0x7a/0xc0 [md_mod]
    kernel: [  154.522732]        kernfs_fop_write+0x117/0x1b0
    kernel: [  154.522735]        vfs_write+0xad/0x1a0
    kernel: [  154.522737]        ksys_write+0xa4/0xe0
    kernel: [  154.522745]        do_syscall_64+0x64/0x2b0
    kernel: [  154.522748]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    kernel: [  154.522749]
    kernel: [  154.522749] -> #3 (&mddev->reconfig_mutex){+.+.}:
    kernel: [  154.522752]        __mutex_lock+0x87/0x950
    kernel: [  154.522756]        new_dev_store+0xc9/0x210 [md_mod]
    kernel: [  154.522759]        md_attr_store+0x7a/0xc0 [md_mod]
    kernel: [  154.522761]        kernfs_fop_write+0x117/0x1b0
    kernel: [  154.522763]        vfs_write+0xad/0x1a0
    kernel: [  154.522765]        ksys_write+0xa4/0xe0
    kernel: [  154.522767]        do_syscall_64+0x64/0x2b0
    kernel: [  154.522769]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    kernel: [  154.522770]
    kernel: [  154.522770] -> #2 (kn->count#253){++++}:
    kernel: [  154.522775]        __kernfs_remove+0x253/0x2c0
    kernel: [  154.522778]        kernfs_remove+0x1f/0x30
    kernel: [  154.522780]        kobject_del+0x28/0x60
    kernel: [  154.522783]        mddev_delayed_delete+0x24/0x30 [md_mod]
    kernel: [  154.522786]        process_one_work+0x2a7/0x5f0
    kernel: [  154.522788]        worker_thread+0x2d/0x3d0
    kernel: [  154.522793]        kthread+0x117/0x130
    kernel: [  154.522795]        ret_from_fork+0x3a/0x50
    kernel: [  154.522796]
    kernel: [  154.522796] -> #1 ((work_completion)(&mddev->del_work)){+.+.}:
    kernel: [  154.522800]        process_one_work+0x27e/0x5f0
    kernel: [  154.522802]        worker_thread+0x2d/0x3d0
    kernel: [  154.522804]        kthread+0x117/0x130
    kernel: [  154.522806]        ret_from_fork+0x3a/0x50
    kernel: [  154.522807]
    kernel: [  154.522807] -> #0 ((wq_completion)md_misc){+.+.}:
    kernel: [  154.522813]        __lock_acquire+0x1392/0x1690
    kernel: [  154.522816]        lock_acquire+0xb4/0x1a0
    kernel: [  154.522818]        flush_workqueue+0xab/0x4b0
    kernel: [  154.522821]        md_open+0xb6/0xc0 [md_mod]
    kernel: [  154.522823]        __blkdev_get+0xea/0x590
    kernel: [  154.522825]        blkdev_get+0x65/0x140
    kernel: [  154.522828]        do_dentry_open+0x1d1/0x380
    kernel: [  154.522831]        path_openat+0x567/0xcc0
    kernel: [  154.522834]        do_filp_open+0x9b/0x110
    kernel: [  154.522836]        do_sys_openat2+0x201/0x2a0
    kernel: [  154.522838]        do_sys_open+0x57/0x80
    kernel: [  154.522840]        do_syscall_64+0x64/0x2b0
    kernel: [  154.522842]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    kernel: [  154.522844]
    kernel: [  154.522844] other info that might help us debug this:
    kernel: [  154.522844]
    kernel: [  154.522846] Chain exists of:
    kernel: [  154.522846]   (wq_completion)md_misc --> &mddev->reconfig_mutex --> &bdev->bd_mutex
    kernel: [  154.522846]
    kernel: [  154.522850]  Possible unsafe locking scenario:
    kernel: [  154.522850]
    kernel: [  154.522852]        CPU0                    CPU1
    kernel: [  154.522853]        ----                    ----
    kernel: [  154.522854]   lock(&bdev->bd_mutex);
    kernel: [  154.522856]                                lock(&mddev->reconfig_mutex);
    kernel: [  154.522858]                                lock(&bdev->bd_mutex);
    kernel: [  154.522860]   lock((wq_completion)md_misc);
    kernel: [  154.522861]
    kernel: [  154.522861]  *** DEADLOCK ***
    kernel: [  154.522861]
    kernel: [  154.522864] 1 lock held by mdadm/2482:
    kernel: [  154.522865]  #0: ffff88804efa9338 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x79/0x590
    kernel: [  154.522868]
    kernel: [  154.522868] stack backtrace:
    kernel: [  154.522873] CPU: 1 PID: 2482 Comm: mdadm Tainted: G           O      5.6.0-rc7-lp151.27-default #25
    kernel: [  154.522875] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    kernel: [  154.522878] Call Trace:
    kernel: [  154.522881]  dump_stack+0x8f/0xcb
    kernel: [  154.522884]  check_noncircular+0x194/0x1b0
    kernel: [  154.522888]  ? __lock_acquire+0x1392/0x1690
    kernel: [  154.522890]  __lock_acquire+0x1392/0x1690
    kernel: [  154.522893]  lock_acquire+0xb4/0x1a0
    kernel: [  154.522895]  ? flush_workqueue+0x84/0x4b0
    kernel: [  154.522898]  flush_workqueue+0xab/0x4b0
    kernel: [  154.522900]  ? flush_workqueue+0x84/0x4b0
    kernel: [  154.522905]  ? md_open+0xb6/0xc0 [md_mod]
    kernel: [  154.522908]  md_open+0xb6/0xc0 [md_mod]
    kernel: [  154.522910]  __blkdev_get+0xea/0x590
    kernel: [  154.522912]  ? bd_acquire+0xc0/0xc0
    kernel: [  154.522914]  blkdev_get+0x65/0x140
    kernel: [  154.522916]  ? bd_acquire+0xc0/0xc0
    kernel: [  154.522918]  do_dentry_open+0x1d1/0x380
    kernel: [  154.522921]  path_openat+0x567/0xcc0
    kernel: [  154.522923]  ? __lock_acquire+0x380/0x1690
    kernel: [  154.522926]  do_filp_open+0x9b/0x110
    kernel: [  154.522929]  ? __alloc_fd+0xe5/0x1f0
    kernel: [  154.522935]  ? kmem_cache_alloc+0x28c/0x630
    kernel: [  154.522939]  ? do_sys_openat2+0x201/0x2a0
    kernel: [  154.522941]  do_sys_openat2+0x201/0x2a0
    kernel: [  154.522944]  do_sys_open+0x57/0x80
    kernel: [  154.522946]  do_syscall_64+0x64/0x2b0
    kernel: [  154.522948]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    kernel: [  154.522951] RIP: 0033:0x7f98d279d9ae
    
    And md_alloc also flushed the same workqueue, but the thing is different
    here. Because all the paths call md_alloc don't hold bdev->bd_mutex, and
    the flush is necessary to avoid race condition, so leave it as it is.
    
    Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb228bf21e21a594d68eba1ff3b3236a0fef9cb4
Author: Daniel Thompson <daniel.thompson@linaro.org>
Date:   Wed May 6 17:42:23 2020 +0100

    kgdb: Fix spurious true from in_dbg_master()
    
    [ Upstream commit 3fec4aecb311995189217e64d725cfe84a568de3 ]
    
    Currently there is a small window where a badly timed migration could
    cause in_dbg_master() to spuriously return true. Specifically if we
    migrate to a new core after reading the processor id and the previous
    core takes a breakpoint then we will evaluate true if we read
    kgdb_active before we get the IPI to bring us to halt.
    
    Fix this by checking irqs_disabled() first. Interrupts are always
    disabled when we are executing the kgdb trap so this is an acceptable
    prerequisite. This also allows us to replace raw_smp_processor_id()
    with smp_processor_id() since the short circuit logic will prevent
    warnings from PREEMPT_DEBUG.
    
    Fixes: dcc7871128e9 ("kgdb: core changes to support kdb")
    Suggested-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20200506164223.2875760-1-daniel.thompson@linaro.org
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb3bcde17baaf703b43646519c85f47cf343766e
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Wed May 6 20:42:22 2020 +0300

    mips: cm: Fix an invalid error code of INTVN_*_ERR
    
    [ Upstream commit 8a0efb8b101665a843205eab3d67ab09cb2d9a8d ]
    
    Commit 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache
    errors") adds cm2_causes[] array with map of error type ID and
    pointers to the short description string. There is a mistake in
    the table, since according to MIPS32 manual CM2_ERROR_TYPE = {17,18}
    correspond to INTVN_WR_ERR and INTVN_RD_ERR, while the table
    claims they have {0x17,0x18} codes. This is obviously hex-dec
    copy-paste bug. Moreover codes {0x18 - 0x1a} indicate L2 ECC errors.
    
    Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors")
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Paul Burton <paulburton@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: linux-pm@vger.kernel.org
    Cc: devicetree@vger.kernel.org
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b01fb175d6bdaa0ca963bfb8f18c79b04ab36c4
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Wed May 6 13:52:45 2020 +0800

    MIPS: Truncate link address into 32bit for 32bit kernel
    
    [ Upstream commit ff487d41036035376e47972c7c522490b839ab37 ]
    
    LLD failed to link vmlinux with 64bit load address for 32bit ELF
    while bfd will strip 64bit address into 32bit silently.
    To fix LLD build, we should truncate load address provided by platform
    into 32bit for 32bit kernel.
    
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Link: https://github.com/ClangBuiltLinux/linux/issues/786
    Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
    Reviewed-by: Fangrui Song <maskray@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Cc: Maciej W. Rozycki <macro@linux-mips.org>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 123a8d0b68ac0159e5ab4ecf61701bd9fb42c7f9
Author: Jeremy Kerr <jk@ozlabs.org>
Date:   Tue May 5 12:12:50 2020 +0200

    powerpc/spufs: fix copy_to_user while atomic
    
    [ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
    
    Currently, we may perform a copy_to_user (through
    simple_read_from_buffer()) while holding a context's register_lock,
    while accessing the context save area.
    
    This change uses a temporary buffer for the context save area data,
    which we then pass to simple_read_from_buffer.
    
    Includes changes from Christoph Hellwig <hch@lst.de>.
    
    Fixes: bf1ab978be23 ("[POWERPC] coredump: Add SPU elf notes to coredump.")
    Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    [hch: renamed to function to avoid ___-prefixes]
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 720b4f27b187e50df1217a35d686ed09cbe06c75
Author: Yunjian Wang <wangyunjian@huawei.com>
Date:   Tue May 5 10:49:20 2020 +0800

    net: allwinner: Fix use correct return type for ndo_start_xmit()
    
    [ Upstream commit 09f6c44aaae0f1bdb8b983d7762676d5018c53bc ]
    
    The method ndo_start_xmit() returns a value of type netdev_tx_t. Fix
    the ndo function to use the correct type. And emac_start_xmit() can
    leak one skb if 'channel' == 3.
    
    Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6eadb140096cffc51e3111fa2f6fcae6d2df77e
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Mon Apr 27 12:15:07 2020 +0000

    net: lpc-enet: fix error return code in lpc_mii_init()
    
    [ Upstream commit 88ec7cb22ddde725ed4ce15991f0bd9dd817fd85 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Acked-by: Vladimir Zapolskiy <vz@mleia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e587ce792e3803f42a8ef19bdcd3ae2cec2892f
Author: Jann Horn <jannh@google.com>
Date:   Thu Mar 5 23:06:57 2020 +0100

    exit: Move preemption fixup up, move blocking operations down
    
    [ Upstream commit 586b58cac8b4683eb58a1446fbc399de18974e40 ]
    
    With CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_CGROUPS=y, kernel oopses in
    non-preemptible context look untidy; after the main oops, the kernel prints
    a "sleeping function called from invalid context" report because
    exit_signals() -> cgroup_threadgroup_change_begin() -> percpu_down_read()
    can sleep, and that happens before the preempt_count_set(PREEMPT_ENABLED)
    fixup.
    
    It looks like the same thing applies to profile_task_exit() and
    kcov_task_exit().
    
    Fix it by moving the preemption fixup up and the calls to
    profile_task_exit() and kcov_task_exit() down.
    
    Fixes: 1dc0fffc48af ("sched/core: Robustify preemption leak checks")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20200305220657.46800-1-jannh@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed3cbbfeba8dd13aefb5e89b6ef40f5342723b9b
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Apr 21 14:47:04 2020 -0700

    lib/mpi: Fix 64-bit MIPS build with Clang
    
    [ Upstream commit 18f1ca46858eac22437819937ae44aa9a8f9f2fa ]
    
    When building 64r6_defconfig with CONFIG_MIPS32_O32 disabled and
    CONFIG_CRYPTO_RSA enabled:
    
    lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a
    inline asm context requiring an l-value: remove the cast
    or build with -fheinous-gnu-extensions
                    umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
                    ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    lib/mpi/longlong.h:664:22: note: expanded from macro 'umul_ppmm'
                     : "=d" ((UDItype)(w0))
                             ~~~~~~~~~~^~~
    lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
    inline asm context requiring an l-value: remove the cast
    or build with -fheinous-gnu-extensions
                    umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
                    ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    lib/mpi/longlong.h:668:22: note: expanded from macro 'umul_ppmm'
                     : "=d" ((UDItype)(w1))
                             ~~~~~~~~~~^~~
    2 errors generated.
    
    This special case for umul_ppmm for MIPS64r6 was added in
    commit bbc25bee37d2b ("lib/mpi: Fix umul_ppmm() for MIPS64r6"), due to
    GCC being inefficient and emitting a __multi3 intrinsic.
    
    There is no such issue with clang; with this patch applied, I can build
    this configuration without any problems and there are no link errors
    like mentioned in the commit above (which I can still reproduce with
    GCC 9.3.0 when that commit is reverted). Only use this definition when
    GCC is being used.
    
    This really should have been caught by commit b0c091ae04f67 ("lib/mpi:
    Eliminate unused umul_ppmm definitions for MIPS") when I was messing
    around in this area but I was not testing 64-bit MIPS at the time.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/885
    Reported-by: Dmitry Golovin <dima@golovin.in>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbe0bd6f77e0331e5491d1c65cd0d4b224f07761
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Apr 24 21:55:34 2020 +0200

    netfilter: nft_nat: return EOPNOTSUPP if type or flags are not supported
    
    [ Upstream commit 0d7c83463fdf7841350f37960a7abadd3e650b41 ]
    
    Instead of EINVAL which should be used for malformed netlink messages.
    
    Fixes: eb31628e37a0 ("netfilter: nf_tables: Add support for IPv6 NAT")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ff43399c7cacff321a0c7331894c574c8323a6b
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Apr 21 19:59:46 2020 +0800

    MIPS: Make sparse_init() using top-down allocation
    
    [ Upstream commit 269b3a9ac538c4ae87f84be640b9fa89914a2489 ]
    
    In the current code, if CONFIG_SWIOTLB is set, when failed to get IO TLB
    memory from the low pages by plat_swiotlb_setup(), it may lead to the boot
    process failed with kernel panic.
    
    (1) On the Loongson and SiByte platform
    arch/mips/loongson64/dma.c
    arch/mips/sibyte/common/dma.c
    void __init plat_swiotlb_setup(void)
    {
            swiotlb_init(1);
    }
    
    kernel/dma/swiotlb.c
    void  __init
    swiotlb_init(int verbose)
    {
    ...
            vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
            if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
                    return;
    ...
            pr_warn("Cannot allocate buffer");
            no_iotlb_memory = true;
    }
    
    phys_addr_t swiotlb_tbl_map_single()
    {
    ...
            if (no_iotlb_memory)
                    panic("Can not allocate SWIOTLB buffer earlier ...");
    ...
    }
    
    (2) On the Cavium OCTEON platform
    arch/mips/cavium-octeon/dma-octeon.c
    void __init plat_swiotlb_setup(void)
    {
    ...
            octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
            if (!octeon_swiotlb)
                    panic("%s: Failed to allocate %zu bytes align=%lx\n",
                          __func__, swiotlbsize, PAGE_SIZE);
    ...
    }
    
    Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is less
    than 64M when call plat_swiotlb_setup(), we can easily reproduce the panic
    case.
    
    In order to reduce the possibility of kernel panic when failed to get IO
    TLB memory under CONFIG_SWIOTLB, it is better to allocate low memory as
    small as possible before plat_swiotlb_setup(), so make sparse_init() using
    top-down allocation.
    
    Reported-by: Juxin Gao <gaojuxin@loongson.cn>
    Co-developed-by: Juxin Gao <gaojuxin@loongson.cn>
    Signed-off-by: Juxin Gao <gaojuxin@loongson.cn>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ac24bdb294e6e51d967c38e31fccd2059437b53
Author: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Date:   Tue Apr 7 17:44:17 2020 +0200

    media: platform: fcp: Set appropriate DMA parameters
    
    [ Upstream commit dd844fb8e50b12e65bbdc5746c9876c6735500df ]
    
    Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will
    enable extra validation on DMA operations ensuring that the size
    restraints are met.
    
    When using the FCP in conjunction with the VSP1/DU, and display frames,
    the size of the DMA operations is larger than the default maximum
    segment size reported by the DMA core (64K). With the DMA debug enabled,
    this produces a warning such as the following:
    
    "DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device
    claims to support [len=3145728] [max=65536]"
    
    We have no specific limitation on the segment size which isn't already
    handled by the VSP1/DU which actually handles the DMA allcoations and
    buffer management, so define a maximum segment size of up to 4GB (a 32
    bit mask).
    
    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver")
    Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cef66945b620e7e96c71d075c0cc58b2dd30d277
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Feb 10 18:51:33 2020 +0100

    media: dvb: return -EREMOTEIO on i2c transfer failure.
    
    [ Upstream commit 96f3a9392799dd0f6472648a7366622ffd0989f3 ]
    
    Currently when i2c transfers fail the error return -EREMOTEIO
    is assigned to err but then later overwritten when the tuner
    attach call is made.  Fix this by returning early with the
    error return code -EREMOTEIO on i2c transfer failure errors.
    
    If the transfer fails, an uninitialized value will be read from b2.
    
    Addresses-Coverity: ("Unused value")
    
    Fixes: fbfee8684ff2 ("V4L/DVB (5651): Dibusb-mb: convert pll handling to properly use dvb-pll")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c76a7a4af64cd64936898d5b90af58f8f82e0221
Author: Jitao Shi <jitao.shi@mediatek.com>
Date:   Wed Apr 15 09:13:17 2020 +0800

    dt-bindings: display: mediatek: control dpi pins mode to avoid leakage
    
    [ Upstream commit b0ff9b590733079f7f9453e5976a9dd2630949e3 ]
    
    Add property "pinctrl-names" to swap pin mode between gpio and dpi mode.
    Set the dpi pins to gpio mode and output-low to avoid leakage current
    when dpi disabled.
    
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ede1f11ae5228f7248946485f9146c3f6274a421
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Feb 19 22:23:02 2020 -0800

    e1000: Distribute switch variables for initialization
    
    [ Upstream commit a34c7f5156654ebaf7eaace102938be7ff7036cb ]
    
    Variables declared in a switch statement before any case statements
    cannot be automatically initialized with compiler instrumentation (as
    they are not part of any execution flow). With GCC's proposed automatic
    stack variable initialization feature, this triggers a warning (and they
    don't get initialized). Clang's automatic stack variable initialization
    (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
    doesn't initialize such variables[1]. Note that these warnings (or silent
    skipping) happen before the dead-store elimination optimization phase,
    so even when the automatic initializations are later elided in favor of
    direct initializations, the warnings remain.
    
    To avoid these problems, move such variables into the "case" where
    they're used or lift them up into the main function body.
    
    drivers/net/ethernet/intel/e1000/e1000_main.c: In function ‘e1000_xmit_frame’:
    drivers/net/ethernet/intel/e1000/e1000_main.c:3143:18: warning: statement will never be executed [-Wswitch-unreachable]
     3143 |     unsigned int pull_size;
          |                  ^~~~~~~~~
    
    [1] https://bugs.llvm.org/show_bug.cgi?id=44916
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40e12d9a15a6575f6dccae621cb85eb7eb910c02
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 1 21:50:23 2020 -0700

    staging: android: ion: use vmap instead of vm_map_ram
    
    [ Upstream commit 5bf9917452112694b2c774465ee4dbe441c84b77 ]
    
    vm_map_ram can keep mappings around after the vm_unmap_ram.  Using that
    with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Christophe Leroy <christophe.leroy@c-s.fr>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Gao Xiang <xiang@kernel.org>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Michael Kelley <mikelley@microsoft.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Nitin Gupta <ngupta@vflare.org>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: Sumit Semwal <sumit.semwal@linaro.org>
    Cc: Wei Liu <wei.liu@kernel.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Paul Mackerras <paulus@ozlabs.org>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: http://lkml.kernel.org/r/20200414131348.444715-4-hch@lst.de
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1e015f7aeccd7dadf209a4e32bbc13f3ce3636d
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Sat May 30 10:41:50 2020 +0800

    net: vmxnet3: fix possible buffer overflow caused by bad DMA value in vmxnet3_get_rss()
    
    [ Upstream commit 3e1c6846b9e108740ef8a37be80314053f5dd52a ]
    
    The value adapter->rss_conf is stored in DMA memory, and it is assigned
    to rssConf, so rssConf->indTableSize can be modified at anytime by
    malicious hardware. Because rssConf->indTableSize is assigned to n,
    buffer overflow may occur when the code "rssConf->indTable[n]" is
    executed.
    
    To fix this possible bug, n is checked after being used.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64a3108d20ab12b8387edcc2f18d07ccededdf53
Author: Jon Doron <arilou@gmail.com>
Date:   Fri Apr 24 14:37:40 2020 +0300

    x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit
    
    [ Upstream commit f7d31e65368aeef973fab788aa22c4f1d5a6af66 ]
    
    The problem the patch is trying to address is the fact that 'struct
    kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit
    modes.
    
    In 64-bit mode the default alignment boundary is 64 bits thus
    forcing extra gaps after 'type' and 'msr' but in 32-bit mode the
    boundary is at 32 bits thus no extra gaps.
    
    This is an issue as even when the kernel is 64 bit, the userspace using
    the interface can be both 32 and 64 bit but the same 32 bit userspace has
    to work with 32 bit kernel.
    
    The issue is fixed by forcing the 64 bit layout, this leads to ABI
    change for 32 bit builds and while we are obviously breaking '32 bit
    userspace with 32 bit kernel' case, we're fixing the '32 bit userspace
    with 64 bit kernel' one.
    
    As the interface has no (known) users and 32 bit KVM is rather baroque
    nowadays, this seems like a reasonable decision.
    
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Jon Doron <arilou@gmail.com>
    Message-Id: <20200424113746.3473563-2-arilou@gmail.com>
    Reviewed-by: Roman Kagan <rvkagan@yandex-team.ru>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58708a2ff7d31356bdbefa14232f0dd47fb0a218
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue May 19 12:59:12 2020 +0100

    ARM: 8978/1: mm: make act_mm() respect THREAD_SIZE
    
    [ Upstream commit e1de94380af588bdf6ad6f0cc1f75004c35bc096 ]
    
    Recent work with KASan exposed the folling hard-coded bitmask
    in arch/arm/mm/proc-macros.S:
    
      bic     rd, sp, #8128
      bic     rd, rd, #63
    
    This forms the bitmask 0x1FFF that is coinciding with
    (PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming
    that THREAD_SIZE is always 8K (8192).
    
    As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into
    this bug.
    
    Fix it by this little oneline suggested by Ard:
    
      bic     rd, sp, #(THREAD_SIZE - 1) & ~63
    
    Where THREAD_SIZE is defined using THREAD_SIZE_ORDER.
    
    We have to also include <linux/const.h> since the THREAD_SIZE
    expands to use the _AC() macro.
    
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Suggested-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 814d5b6f5758bded017b4b544cfddcef99ee853f
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon May 18 12:15:09 2020 +0100

    btrfs: do not ignore error from btrfs_next_leaf() when inserting checksums
    
    [ Upstream commit 7e4a3f7ed5d54926ec671bbb13e171cfe179cc50 ]
    
    We are currently treating any non-zero return value from btrfs_next_leaf()
    the same way, by going to the code that inserts a new checksum item in the
    tree. However if btrfs_next_leaf() returns an error (a value < 0), we
    should just stop and return the error, and not behave as if nothing has
    happened, since in that case we do not have a way to know if there is a
    next leaf or we are currently at the last leaf already.
    
    So fix that by returning the error from btrfs_next_leaf().
    
    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: Sasha Levin <sashal@kernel.org>

commit ec718fc8acdbba62351c2988dfb4355e73df8b3e
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Thu May 21 23:48:15 2020 +0300

    clocksource: dw_apb_timer_of: Fix missing clockevent timers
    
    [ Upstream commit 6d2e16a3181bafb77b535095c39ad1c8b9558c8c ]
    
    Commit 100214889973 ("clocksource: dw_apb_timer_of: use
    clocksource_of_init") replaced a publicly available driver
    initialization method with one called by the timer_probe() method
    available after CLKSRC_OF. In current implementation it traverses
    all the timers available in the system and calls their initialization
    methods if corresponding devices were either in dtb or in acpi. But
    if before the commit any number of available timers would be installed
    as clockevent and clocksource devices, after that there would be at most
    two. The rest are just ignored since default case branch doesn't do
    anything. I don't see a reason of such behaviour, neither the commit
    message explains it. Moreover this might be wrong if on some platforms
    these timers might be used for different purpose, as virtually CPU-local
    clockevent timers and as an independent broadcast timer. So in order
    to keep the compatibility with the platforms where the order of the
    timers detection has some meaning, lets add the secondly discovered
    timer to be of clocksource/sched_clock type, while the very first and
    the others would provide the clockevents service.
    
    Fixes: 100214889973 ("clocksource: dw_apb_timer_of: use clocksource_of_init")
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Paul Burton <paulburton@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-rtc@vger.kernel.org
    Cc: devicetree@vger.kernel.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20200521204818.25436-7-Sergey.Semin@baikalelectronics.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3824e01d361ddfa9955c3db7e54543d930452cdb
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri May 22 03:07:51 2020 +0300

    spi: dw: Enable interrupts in accordance with DMA xfer mode
    
    [ Upstream commit 43dba9f3f98c2b184a19f856f06fe22817bfd9e0 ]
    
    It's pointless to track the Tx overrun interrupts if Rx-only SPI
    transfer is issued. Similarly there is no need in handling the Rx
    overrun/underrun interrupts if Tx-only SPI transfer is executed.
    So lets unmask the interrupts only if corresponding SPI
    transactions are implied.
    
    Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
    Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
    Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Paul Burton <paulburton@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Cc: devicetree@vger.kernel.org
    Link: https://lore.kernel.org/r/20200522000806.7381-3-Sergey.Semin@baikalelectronics.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d39bb8ee76a0ccfd1086b6e76e2a0b247ecaa5fd
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu May 7 13:08:44 2020 -0700

    kgdb: Prevent infinite recursive entries to the debugger
    
    [ Upstream commit 3ca676e4ca60d1834bb77535dafe24169cadacef ]
    
    If we detect that we recursively entered the debugger we should hack
    our I/O ops to NULL so that the panic() in the next line won't
    actually cause another recursion into the debugger.  The first line of
    kgdb_panic() will check this and return.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Link: https://lore.kernel.org/r/20200507130644.v4.6.I89de39f68736c9de610e6f241e68d8dbc44bc266@changeid
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b0660c7e1cf070d31e17319ce5b3bd30b310955
Author: Hsin-Yu Chao <hychao@chromium.org>
Date:   Fri May 15 17:27:04 2020 +0800

    Bluetooth: Add SCO fallback for invalid LMP parameters error
    
    [ Upstream commit 56b5453a86203a44726f523b4133c1feca49ce7c ]
    
    Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection
    with invalid parameter at the first SCO request expecting AG to
    attempt another SCO request with the use of "safe settings" for
    given codec, base on section 5.7.1.2 of HFP 1.7 specification.
    
    This patch addresses it by adding "Invalid LMP Parameters" (0x1e)
    to the SCO fallback case. Verified with below log:
    
    < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
            Handle: 256
            Transmit bandwidth: 8000
            Receive bandwidth: 8000
            Max latency: 13
            Setting: 0x0003
              Input Coding: Linear
              Input Data Format: 1's complement
              Input Sample Size: 8-bit
              # of bits padding at MSB: 0
              Air Coding Format: Transparent Data
            Retransmission effort: Optimize for link quality (0x02)
            Packet type: 0x0380
              3-EV3 may not be used
              2-EV5 may not be used
              3-EV5 may not be used
    > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) ncmd 1
            Status: Success (0x00)
    > HCI Event: Number of Completed Packets (0x13) plen 5
            Num handles: 1
            Handle: 256
            Count: 1
    > HCI Event: Max Slots Change (0x1b) plen 3
            Handle: 256
            Max slots: 1
    > HCI Event: Synchronous Connect Complete (0x2c) plen 17
            Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
            Handle: 0
            Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
            Link type: eSCO (0x02)
            Transmission interval: 0x00
            Retransmission window: 0x02
            RX packet length: 0
            TX packet length: 0
            Air mode: Transparent (0x03)
    < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
            Handle: 256
            Transmit bandwidth: 8000
            Receive bandwidth: 8000
            Max latency: 8
            Setting: 0x0003
              Input Coding: Linear
              Input Data Format: 1's complement
              Input Sample Size: 8-bit
              # of bits padding at MSB: 0
              Air Coding Format: Transparent Data
            Retransmission effort: Optimize for link quality (0x02)
            Packet type: 0x03c8
              EV3 may be used
              2-EV3 may not be used
              3-EV3 may not be used
              2-EV5 may not be used
              3-EV5 may not be used
    > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) ncmd 1
            Status: Success (0x00)
    > HCI Event: Max Slots Change (0x1b) plen 3
            Handle: 256
            Max slots: 5
    > HCI Event: Max Slots Change (0x1b) plen 3
            Handle: 256
            Max slots: 1
    > HCI Event: Synchronous Connect Complete (0x2c) plen 17
            Status: Success (0x00)
            Handle: 257
            Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
            Link type: eSCO (0x02)
            Transmission interval: 0x06
            Retransmission window: 0x04
            RX packet length: 30
            TX packet length: 30
            Air mode: Transparent (0x03)
    
    Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3801effa5fe3a51f907170f932362d07fbfc8d2d
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed May 6 18:30:18 2020 +0300

    spi: dw: Zero DMA Tx and Rx configurations on stack
    
    [ Upstream commit 3cb97e223d277f84171cc4ccecab31e08b2ee7b5 ]
    
    Some DMA controller drivers do not tolerate non-zero values in
    the DMA configuration structures. Zero them to avoid issues with
    such DMA controller drivers. Even despite above this is a good
    practice per se.
    
    Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Feng Tang <feng.tang@intel.com>
    Cc: Feng Tang <feng.tang@intel.com>
    Link: https://lore.kernel.org/r/20200506153025.21441-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 966de7bdeff501395b630c6503a17caaf8295d41
Author: Arthur Kiyanovski <akiyano@amazon.com>
Date:   Sun May 3 09:52:11 2020 +0000

    net: ena: fix error returning in ena_com_get_hash_function()
    
    [ Upstream commit e9a1de378dd46375f9abfd8de1e6f59ee114a793 ]
    
    In case the "func" parameter is NULL we now return "-EINVAL".
    This shouldn't happen in general, but when it does happen, this is the
    proper way to handle it.
    
    We also check func for NULL in the beginning of the function, as there
    is no reason to do all the work and realize in the end of the function
    it was useless.
    
    Signed-off-by: Sameeh Jubran <sameehj@amazon.com>
    Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1f3bcd5494f920ab7a365b2bb5a195be54e25df
Author: Julien Thierry <jthierry@redhat.com>
Date:   Fri Mar 27 15:28:41 2020 +0000

    objtool: Ignore empty alternatives
    
    [ Upstream commit 7170cf47d16f1ba29eca07fd818870b7af0a93a5 ]
    
    The .alternatives section can contain entries with no original
    instructions. Objtool will currently crash when handling such an entry.
    
    Just skip that entry, but still give a warning to discourage useless
    entries.
    
    Signed-off-by: Julien Thierry <jthierry@redhat.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4688ba5b53400215889151f34fee51de7b483f71
Author: Brad Love <brad@nextdimension.cc>
Date:   Thu Nov 14 21:03:57 2019 +0100

    media: si2157: Better check for running tuner in init
    
    [ Upstream commit e955f959ac52e145f27ff2be9078b646d0352af0 ]
    
    Getting the Xtal trim property to check if running is less error prone.
    Reset if_frequency if state is unknown.
    
    Replaces the previous "garbage check".
    
    Signed-off-by: Brad Love <brad@nextdimension.cc>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cfcf05c86f8143935e8c6983abcb57265890474
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Wed May 27 13:37:00 2020 +0200

    ACPI: GED: use correct trigger type field in _Exx / _Lxx handling
    
    commit e5c399b0bd6490c12c0af2a9eaa9d7cd805d52c9 upstream.
    
    Commit ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler
    methods") added a reference to the 'triggering' field of either the
    normal or the extended ACPI IRQ resource struct, but inadvertently used
    the wrong pointer in the latter case. Note that both pointers refer to the
    same union, and the 'triggering' field appears at the same offset in both
    struct types, so it currently happens to work by accident. But let's fix
    it nonetheless
    
    Fixes: ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler methods")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77d5f7fe23e92dfdeefcc9a225ee97eee2667d95
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jul 20 18:12:07 2017 -0400

    media: dvb_frontend: ensure that inital front end status initialized
    
    commit a9e4998073d49a762a154a6b48a332ec6cb8e6b1 upstream.
    
    The fe_status variable s is not initialized meaning it can have any
    random garbage status.  This could be problematic if fe->ops.tune is
    false as s is not updated by the call to fe->ops.tune() and a
    subsequent check on the change status will using a garbage value.
    Fix this by adding FE_NONE to the enum fe_status and initializing
    s to this.
    
    Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8ed03b9c541e9ac25085d4c2c74b775161c1654
Author: Xiaolong Huang <butterflyhuangxx@gmail.com>
Date:   Sat Dec 7 22:40:24 2019 +0800

    can: kvaser_usb: kvaser_usb_leaf: Fix some info-leaks to USB devices
    
    commit da2311a6385c3b499da2ed5d9be59ce331fa93e9 upstream.
    
    Uninitialized Kernel memory can leak to USB devices.
    
    Fix this by using kzalloc() instead of kmalloc().
    
    Signed-off-by: Xiaolong Huang <butterflyhuangxx@gmail.com>
    Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c")
    Cc: linux-stable <stable@vger.kernel.org> # >= v4.19
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 4.9: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35de820ec802dac28bc37f757723847e7ecd70d2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Apr 10 09:35:35 2020 +0100

    agp/intel: Reinforce the barrier after GTT updates
    
    commit f30d3ced9fafa03e4855508929b5b6334907f45e upstream.
    
    After changing the timing between GTT updates and execution on the GPU,
    we started seeing sporadic failures on Ironlake. These were narrowed
    down to being an insufficiently strong enough barrier/delay after
    updating the GTT and scheduling execution on the GPU. By forcing the
    uncached read, and adding the missing barrier for the singular
    insert_page (relocation paths), the sporadic failures go away.
    
    Fixes: 983d308cb8f6 ("agp/intel: Serialise after GTT updates")
    Fixes: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Andi Shyti <andi.shyti@intel.com>
    Cc: stable@vger.kernel.org # v4.0+
    Link: https://patchwork.freedesktop.org/patch/msgid/20200410083535.25464-1-chris@chris-wilson.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bf3b3649d37a1bd9fe9f4f04707c14934298795
Author: Barret Rhoden <brho@google.com>
Date:   Tue Apr 14 18:29:20 2020 -0400

    perf: Add cond_resched() to task_function_call()
    
    commit 2ed6edd33a214bca02bd2b45e3fc3038a059436b upstream.
    
    Under rare circumstances, task_function_call() can repeatedly fail and
    cause a soft lockup.
    
    There is a slight race where the process is no longer running on the cpu
    we targeted by the time remote_function() runs.  The code will simply
    try again.  If we are very unlucky, this will continue to fail, until a
    watchdog fires.  This can happen in a heavily loaded, multi-core virtual
    machine.
    
    Reported-by: syzbot+bb4935a5c09b5ff79940@syzkaller.appspotmail.com
    Signed-off-by: Barret Rhoden <brho@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20200414222920.121401-1-brho@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cadb31d19d02dfe239223f0c753cdcdb0a02aba9
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Thu Jun 4 16:50:56 2020 -0700

    fat: don't allow to mount if the FAT length == 0
    
    commit b1b65750b8db67834482f758fc385bfa7560d228 upstream.
    
    If FAT length == 0, the image doesn't have any data. And it can be the
    cause of overlapping the root dir and FAT entries.
    
    Also Windows treats it as invalid format.
    
    Reported-by: syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Marco Elver <elver@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Link: http://lkml.kernel.org/r/87r1wz8mrd.fsf@mail.parknet.co.jp
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 248bd0506b58fd62c0fd1c8fd4a0d5a48b12ff43
Author: Wang Hai <wanghai38@huawei.com>
Date:   Wed Jun 3 15:56:21 2020 -0700

    mm/slub: fix a memory leak in sysfs_slab_add()
    
    commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2 upstream.
    
    syzkaller reports for memory leak when kobject_init_and_add() returns an
    error in the function sysfs_slab_add() [1]
    
    When this happened, the function kobject_put() is not called for the
    corresponding kobject, which potentially leads to memory leak.
    
    This patch fixes the issue by calling kobject_put() even if
    kobject_init_and_add() fails.
    
    [1]
      BUG: memory leak
      unreferenced object 0xffff8880a6d4be88 (size 8):
      comm "syz-executor.3", pid 946, jiffies 4295772514 (age 18.396s)
      hex dump (first 8 bytes):
        70 69 64 5f 33 00 ff ff                          pid_3...
      backtrace:
         kstrdup+0x35/0x70 mm/util.c:60
         kstrdup_const+0x3d/0x50 mm/util.c:82
         kvasprintf_const+0x112/0x170 lib/kasprintf.c:48
         kobject_set_name_vargs+0x55/0x130 lib/kobject.c:289
         kobject_add_varg lib/kobject.c:384 [inline]
         kobject_init_and_add+0xd8/0x170 lib/kobject.c:473
         sysfs_slab_add+0x1d8/0x290 mm/slub.c:5811
         __kmem_cache_create+0x50a/0x570 mm/slub.c:4384
         create_cache+0x113/0x1e0 mm/slab_common.c:407
         kmem_cache_create_usercopy+0x1a1/0x260 mm/slab_common.c:505
         kmem_cache_create+0xd/0x10 mm/slab_common.c:564
         create_pid_cachep kernel/pid_namespace.c:54 [inline]
         create_pid_namespace kernel/pid_namespace.c:96 [inline]
         copy_pid_ns+0x77c/0x8f0 kernel/pid_namespace.c:148
         create_new_namespaces+0x26b/0xa30 kernel/nsproxy.c:95
         unshare_nsproxy_namespaces+0xa7/0x1e0 kernel/nsproxy.c:229
         ksys_unshare+0x3d2/0x770 kernel/fork.c:2969
         __do_sys_unshare kernel/fork.c:3037 [inline]
         __se_sys_unshare kernel/fork.c:3035 [inline]
         __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3035
         do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:295
    
    Fixes: 80da026a8e5d ("mm/slub: fix slab double-free in case of duplicate sysfs filename")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Link: http://lkml.kernel.org/r/20200602115033.1054-1-wanghai38@huawei.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9010023962a37eeaf1c75bdc5fcb15e235a5d1a
Author: Casey Schaufler <casey@schaufler-ca.com>
Date:   Thu Apr 9 16:35:28 2020 -0700

    Smack: slab-out-of-bounds in vsscanf
    
    commit 84e99e58e8d1e26f04c097f4266e431a33987f36 upstream.
    
    Add barrier to soob. Return -EOVERFLOW if the buffer
    is exceeded.
    
    Suggested-by: Hillf Danton <hdanton@sina.com>
    Reported-by: syzbot+bfdd4a2f07be52351350@syzkaller.appspotmail.com
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5317abc46279d900c7e63cc122682d819da658bd
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Sat Apr 4 12:18:38 2020 +0800

    ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
    
    commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
    
    In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
    usb_ifnum_to_if(urb->dev, 0)
    But it isn't always true.
    
    The case reported by syzbot:
    https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com
    usb 2-1: new high-speed USB device number 2 using dummy_hcd
    usb 2-1: config 1 has an invalid interface number: 2 but max is 0
    usb 2-1: config 1 has no interface number 0
    usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
    1.08
    usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    general protection fault, probably for non-canonical address
    0xdffffc0000000015: 0000 [#1] SMP KASAN
    KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0
    
    Call Trace
    __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
    usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
    dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
    call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
    expire_timers kernel/time/timer.c:1449 [inline]
    __run_timers kernel/time/timer.c:1773 [inline]
    __run_timers kernel/time/timer.c:1740 [inline]
    run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
    __do_softirq+0x21e/0x950 kernel/softirq.c:292
    invoke_softirq kernel/softirq.c:373 [inline]
    irq_exit+0x178/0x1a0 kernel/softirq.c:413
    exiting_irq arch/x86/include/asm/apic.h:546 [inline]
    smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
    apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
    
    Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c87598dbcafb489c6eeee794c7e40eb939c1eca
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Sat Apr 4 12:18:37 2020 +0800

    ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
    
    commit 19d6c375d671ce9949a864fb9a03e19f5487b4d3 upstream.
    
    Add barrier to accessing the stack array skb_pool.
    
    The case reported by syzbot:
    https://lore.kernel.org/linux-usb/0000000000003d7c1505a2168418@google.com
    BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_stream
    drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline]
    BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_cb+0xdf6/0xf70
    drivers/net/wireless/ath/ath9k/hif_usb.c:666
    Write of size 8 at addr ffff8881db309a28 by task swapper/1/0
    
    Call Trace:
    ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626
    [inline]
    ath9k_hif_usb_rx_cb+0xdf6/0xf70
    drivers/net/wireless/ath/ath9k/hif_usb.c:666
    __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648
    usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713
    dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
    call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
    expire_timers kernel/time/timer.c:1449 [inline]
    __run_timers kernel/time/timer.c:1773 [inline]
    __run_timers kernel/time/timer.c:1740 [inline]
    run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
    
    Reported-and-tested-by: syzbot+d403396d4df67ad0bd5f@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200404041838.10426-5-hqjagain@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 435f90a6506625722bd7c253b06274477dacd7ce
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Sat Apr 4 12:18:36 2020 +0800

    ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
    
    commit e4ff08a4d727146bb6717a39a8d399d834654345 upstream.
    
    Write out of slab bounds. We should check epid.
    
    The case reported by syzbot:
    https://lore.kernel.org/linux-usb/0000000000006ac55b05a1c05d72@google.com
    BUG: KASAN: use-after-free in htc_process_conn_rsp
    drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline]
    BUG: KASAN: use-after-free in ath9k_htc_rx_msg+0xa25/0xaf0
    drivers/net/wireless/ath/ath9k/htc_hst.c:443
    Write of size 2 at addr ffff8881cea291f0 by task swapper/1/0
    
    Call Trace:
     htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131
    [inline]
    ath9k_htc_rx_msg+0xa25/0xaf0
    drivers/net/wireless/ath/ath9k/htc_hst.c:443
    ath9k_hif_usb_reg_in_cb+0x1ba/0x630
    drivers/net/wireless/ath/ath9k/hif_usb.c:718
    __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
    usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
    dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
    call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
    expire_timers kernel/time/timer.c:1449 [inline]
    __run_timers kernel/time/timer.c:1773 [inline]
    __run_timers kernel/time/timer.c:1740 [inline]
    run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
    
    Reported-and-tested-by: syzbot+b1c61e5f11be5782f192@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200404041838.10426-4-hqjagain@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44736603a7099d2a9b48c669e43a689588e272a5
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Sat Apr 4 12:18:35 2020 +0800

    ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
    
    commit abeaa85054ff8cfe8b99aafc5c70ea067e5d0908 upstream.
    
    Free wmi later after cmd urb has been killed, as urb cb will access wmi.
    
    the case reported by syzbot:
    https://lore.kernel.org/linux-usb/0000000000000002fc05a1d61a68@google.com
    BUG: KASAN: use-after-free in ath9k_wmi_ctrl_rx+0x416/0x500
    drivers/net/wireless/ath/ath9k/wmi.c:215
    Read of size 1 at addr ffff8881cef1417c by task swapper/1/0
    
    Call Trace:
    <IRQ>
    ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215
    ath9k_htc_rx_msg+0x2da/0xaf0
    drivers/net/wireless/ath/ath9k/htc_hst.c:459
    ath9k_hif_usb_reg_in_cb+0x1ba/0x630
    drivers/net/wireless/ath/ath9k/hif_usb.c:718
    __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
    usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
    dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
    call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
    expire_timers kernel/time/timer.c:1449 [inline]
    __run_timers kernel/time/timer.c:1773 [inline]
    __run_timers kernel/time/timer.c:1740 [inline]
    run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
    
    Reported-and-tested-by: syzbot+5d338854440137ea0fef@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200404041838.10426-3-hqjagain@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fce258c1163bd69547327c66e82df7ac3077a0d
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Jun 9 08:40:35 2020 +0100

    KVM: arm64: Make vcpu_cp1x() work on Big Endian hosts
    
    commit 3204be4109ad681523e3461ce64454c79278450a upstream.
    
    AArch32 CP1x registers are overlayed on their AArch64 counterparts
    in the vcpu struct. This leads to an interesting problem as they
    are stored in their CPU-local format, and thus a CP1x register
    doesn't "hit" the lower 32bit portion of the AArch64 register on
    a BE host.
    
    To workaround this unfortunate situation, introduce a bias trick
    in the vcpu_cp1x() accessors which picks the correct half of the
    64bit register.
    
    Cc: stable@vger.kernel.org
    Reported-by: James Morse <james.morse@arm.com>
    Tested-by: James Morse <james.morse@arm.com>
    Acked-by: James Morse <james.morse@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb671aa02528073d677aaf1d044539ab024c9470
Author: Xing Li <lixing@loongson.cn>
Date:   Sat May 23 15:56:29 2020 +0800

    KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits
    
    commit 5816c76dea116a458f1932eefe064e35403248eb upstream.
    
    If a CPU support more than 32bit vmbits (which is true for 64bit CPUs),
    VPN2_MASK set to fixed 0xffffe000 will lead to a wrong EntryHi in some
    functions such as _kvm_mips_host_tlb_inv().
    
    The cpu_vmbits definition of 32bit CPU in cpu-features.h is 31, so we
    still use the old definition.
    
    Cc: Stable <stable@vger.kernel.org>
    Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
    Signed-off-by: Xing Li <lixing@loongson.cn>
    [Huacai: Improve commit messages]
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Message-Id: <1590220602-3547-3-git-send-email-chenhc@lemote.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ab5aec37049529fce062472221a91433984b731
Author: Xing Li <lixing@loongson.cn>
Date:   Sat May 23 15:56:28 2020 +0800

    KVM: MIPS: Define KVM_ENTRYHI_ASID to cpu_asid_mask(&boot_cpu_data)
    
    commit fe2b73dba47fb6d6922df1ad44e83b1754d5ed4d upstream.
    
    The code in decode_config4() of arch/mips/kernel/cpu-probe.c
    
            asid_mask = MIPS_ENTRYHI_ASID;
            if (config4 & MIPS_CONF4_AE)
                    asid_mask |= MIPS_ENTRYHI_ASIDX;
            set_cpu_asid_mask(c, asid_mask);
    
    set asid_mask to cpuinfo->asid_mask.
    
    So in order to support variable ASID_MASK, KVM_ENTRYHI_ASID should also
    be changed to cpu_asid_mask(&boot_cpu_data).
    
    Cc: Stable <stable@vger.kernel.org>  #4.9+
    Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
    Signed-off-by: Xing Li <lixing@loongson.cn>
    [Huacai: Change current_cpu_data to boot_cpu_data for optimization]
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Message-Id: <1590220602-3547-2-git-send-email-chenhc@lemote.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99a9857ddbd732be6348af989535fc39bbd2ab20
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Feb 27 09:44:30 2020 -0800

    KVM: nVMX: Consult only the "basic" exit reason when routing nested exit
    
    commit 2ebac8bb3c2d35f5135466490fc8eeaf3f3e2d37 upstream.
    
    Consult only the basic exit reason, i.e. bits 15:0 of vmcs.EXIT_REASON,
    when determining whether a nested VM-Exit should be reflected into L1 or
    handled by KVM in L0.
    
    For better or worse, the switch statement in nested_vmx_exit_reflected()
    currently defaults to "true", i.e. reflects any nested VM-Exit without
    dedicated logic.  Because the case statements only contain the basic
    exit reason, any VM-Exit with modifier bits set will be reflected to L1,
    even if KVM intended to handle it in L0.
    
    Practically speaking, this only affects EXIT_REASON_MCE_DURING_VMENTRY,
    i.e. a #MC that occurs on nested VM-Enter would be incorrectly routed to
    L1, as "failed VM-Entry" is the only modifier that KVM can currently
    encounter.  The SMM modifiers will never be generated as KVM doesn't
    support/employ a SMI Transfer Monitor.  Ditto for "exit from enclave",
    as KVM doesn't yet support virtualizing SGX, i.e. it's impossible to
    enter an enclave in a KVM guest (L1 or L2).
    
    Fixes: 644d711aa0e1 ("KVM: nVMX: Deciding if L0 or L1 should handle an L2 exit")
    Cc: Jim Mattson <jmattson@google.com>
    Cc: Xiaoyao Li <xiaoyao.li@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Message-Id: <20200227174430.26371-1-sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e9cc6ea67757d1ddfceddd870ea390cb964b841
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed May 20 08:02:17 2020 -0400

    KVM: nSVM: leave ASID aside in copy_vmcb_control_area
    
    commit 6c0238c4a62b3a0b1201aeb7e33a4636d552a436 upstream.
    
    Restoring the ASID from the hsave area on VMEXIT is wrong, because its
    value depends on the handling of TLB flushes.  Just skipping the field in
    copy_vmcb_control_area will do.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8ef2244dfda97fcbaa18f06ed0edc66b7288b03
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed May 6 20:19:02 2020 +0200

    video: fbdev: w100fb: Fix a potential double free.
    
    commit 18722d48a6bb9c2e8d046214c0a5fd19d0a7c9f6 upstream.
    
    Some memory is vmalloc'ed in the 'w100fb_save_vidmem' function and freed in
    the 'w100fb_restore_vidmem' function. (these functions are called
    respectively from the 'suspend' and the 'resume' functions)
    
    However, it is also freed in the 'remove' function.
    
    In order to avoid a potential double free, set the corresponding pointer
    to NULL once freed in the 'w100fb_restore_vidmem' function.
    
    Fixes: aac51f09d96a ("[PATCH] w100fb: Rewrite for platform independence")
    Cc: Richard Purdie <rpurdie@rpsys.net>
    Cc: Antonino Daplas <adaplas@pol.net>
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Cc: <stable@vger.kernel.org> # v2.6.14+
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200506181902.193290-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b85bf5cf3af4584a7198c1a4e780b0e029eb50e
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Jun 12 09:42:03 2020 -0500

    proc: Use new_inode not new_inode_pseudo
    
    commit ef1548adada51a2f32ed7faef50aa465e1b4c5da upstream.
    
    Recently syzbot reported that unmounting proc when there is an ongoing
    inotify watch on the root directory of proc could result in a use
    after free when the watch is removed after the unmount of proc
    when the watcher exits.
    
    Commit 69879c01a0c3 ("proc: Remove the now unnecessary internal mount
    of proc") made it easier to unmount proc and allowed syzbot to see the
    problem, but looking at the code it has been around for a long time.
    
    Looking at the code the fsnotify watch should have been removed by
    fsnotify_sb_delete in generic_shutdown_super.  Unfortunately the inode
    was allocated with new_inode_pseudo instead of new_inode so the inode
    was not on the sb->s_inodes list.  Which prevented
    fsnotify_unmount_inodes from finding the inode and removing the watch
    as well as made it so the "VFS: Busy inodes after unmount" warning
    could not find the inodes to warn about them.
    
    Make all of the inodes in proc visible to generic_shutdown_super,
    and fsnotify_sb_delete by using new_inode instead of new_inode_pseudo.
    The only functional difference is that new_inode places the inodes
    on the sb->s_inodes list.
    
    I wrote a small test program and I can verify that without changes it
    can trigger this issue, and by replacing new_inode_pseudo with
    new_inode the issues goes away.
    
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/000000000000d788c905a7dfa3f4@google.com
    Reported-by: syzbot+7d2debdcdb3cb93c1e5e@syzkaller.appspotmail.com
    Fixes: 0097875bd415 ("proc: Implement /proc/thread-self to point at the directory of the current thread")
    Fixes: 021ada7dff22 ("procfs: switch /proc/self away from proc_dir_entry")
    Fixes: 51f0885e5415 ("vfs,proc: guarantee unique inodes in /proc")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd50ed659b388546cfc99caf5ac1cf7f0e2ec8cb
Author: Yuxuan Shui <yshuiv7@gmail.com>
Date:   Wed May 27 04:08:02 2020 +0100

    ovl: initialize error in ovl_copy_xattr
    
    commit 520da69d265a91c6536c63851cbb8a53946974f0 upstream.
    
    In ovl_copy_xattr, if all the xattrs to be copied are overlayfs private
    xattrs, the copy loop will terminate without assigning anything to the
    error variable, thus returning an uninitialized value.
    
    If ovl_copy_xattr is called from ovl_clear_empty, this uninitialized error
    value is put into a pointer by ERR_PTR(), causing potential invalid memory
    accesses down the line.
    
    This commit initialize error with 0. This is the correct value because when
    there's no xattr to copy, because all xattrs are private, ovl_copy_xattr
    should succeed.
    
    This bug is discovered with the help of INIT_STACK_ALL and clang.
    
    Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
    Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1050405
    Fixes: 0956254a2d5b ("ovl: don't copy up opaqueness")
    Cc: stable@vger.kernel.org # v4.8
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 826332330dab13003337a22bbd1685afb1f79d6d
Author: Lukas Wunner <lukas@wunner.de>
Date:   Fri May 15 17:58:02 2020 +0200

    spi: bcm2835: Fix controller unregister order
    
    [ Upstream commit 9dd277ff92d06f6aa95b39936ad83981d781f49b ]
    
    The BCM2835 SPI driver uses devm_spi_register_controller() on bind.
    As a consequence, on unbind, __device_release_driver() first invokes
    bcm2835_spi_remove() before unregistering the SPI controller via
    devres_release_all().
    
    This order is incorrect:  bcm2835_spi_remove() tears down the DMA
    channels and turns off the SPI controller, including its interrupts
    and clock.  The SPI controller is thus no longer usable.
    
    When the SPI controller is subsequently unregistered, it unbinds all
    its slave devices.  If their drivers need to access the SPI bus,
    e.g. to quiesce their interrupts, unbinding will fail.
    
    As a rule, devm_spi_register_controller() must not be used if the
    ->remove() hook performs teardown steps which shall be performed
    after unbinding of slaves.
    
    Fix by using the non-devm variant spi_register_controller().  Note that
    the struct spi_controller as well as the driver-private data are not
    freed until after bcm2835_spi_remove() has finished, so accessing them
    is safe.
    
    Fixes: 247263dba208 ("spi: bcm2835: use devm_spi_register_master()")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v3.13+
    Link: https://lore.kernel.org/r/2397dd70cdbe95e0bc4da2b9fca0f31cb94e5aed.1589557526.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97cf608da5be7c2b48aa05410e261b1c0273857b
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon May 25 14:25:02 2020 +0200

    spi: pxa2xx: Fix controller unregister order
    
    [ Upstream commit 32e5b57232c0411e7dea96625c415510430ac079 ]
    
    The PXA2xx SPI driver uses devm_spi_register_controller() on bind.
    As a consequence, on unbind, __device_release_driver() first invokes
    pxa2xx_spi_remove() before unregistering the SPI controller via
    devres_release_all().
    
    This order is incorrect:  pxa2xx_spi_remove() disables the chip,
    rendering the SPI bus inaccessible even though the SPI controller is
    still registered.  When the SPI controller is subsequently unregistered,
    it unbinds all its slave devices.  Because their drivers cannot access
    the SPI bus, e.g. to quiesce interrupts, the slave devices may be left
    in an improper state.
    
    As a rule, devm_spi_register_controller() must not be used if the
    ->remove() hook performs teardown steps which shall be performed after
    unregistering the controller and specifically after unbinding of slaves.
    
    Fix by reverting to the non-devm variant of spi_register_controller().
    
    An alternative approach would be to use device-managed functions for all
    steps in pxa2xx_spi_remove(), e.g. by calling devm_add_action_or_reset()
    on probe.  However that approach would add more LoC to the driver and
    it wouldn't lend itself as well to backporting to stable.
    
    The improper use of devm_spi_register_controller() was introduced in 2013
    by commit a807fcd090d6 ("spi: pxa2xx: use devm_spi_register_master()"),
    but all earlier versions of the driver going back to 2006 were likewise
    broken because they invoked spi_unregister_master() at the end of
    pxa2xx_spi_remove(), rather than at the beginning.
    
    Fixes: e0c9905e87ac ("[PATCH] SPI: add PXA2xx SSP SPI Driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org # v2.6.17+
    Cc: Tsuchiya Yuto <kitakar@gmail.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206403#c1
    Link: https://lore.kernel.org/r/834c446b1cf3284d2660f1bee1ebe3e737cd02a9.1590408496.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7e41e1caa713225f5f16f144cc0f8760a7a06c4
Author: Lukas Wunner <lukas@wunner.de>
Date:   Fri May 15 17:58:01 2020 +0200

    spi: Fix controller unregister order
    
    [ Upstream commit 84855678add8aba927faf76bc2f130a40f94b6f7 ]
    
    When an SPI controller unregisters, it unbinds all its slave devices.
    For this, their drivers may need to access the SPI bus, e.g. to quiesce
    interrupts.
    
    However since commit ffbbdd21329f ("spi: create a message queueing
    infrastructure"), spi_destroy_queue() is executed before unbinding the
    slaves.  It sets ctlr->running = false, thereby preventing SPI bus
    access and causing unbinding of slave devices to fail.
    
    Fix by unbinding slaves before calling spi_destroy_queue().
    
    Fixes: ffbbdd21329f ("spi: create a message queueing infrastructure")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v3.4+
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/8aaf9d44c153fe233b17bc2dec4eb679898d7e7b.1589557526.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bc16ca02b374b687f47044817c8ccdb89773b35
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sat Jun 15 20:41:35 2019 +0300

    spi: No need to assign dummy value in spi_unregister_controller()
    
    [ Upstream commit ebc37af5e0a134355ea2b62ed4141458bdbd5389 ]
    
    The device_for_each_child() doesn't require the returned value to be checked.
    Thus, drop the dummy variable completely and have no warning anymore:
    
    drivers/spi/spi.c: In function ‘spi_unregister_controller’:
    drivers/spi/spi.c:2480:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
      int dummy;
          ^~~~~
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35654d44a5f15449000a91a47b4769ea6572e028
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon May 25 14:25:01 2020 +0200

    spi: dw: Fix controller unregister order
    
    [ Upstream commit ca8b19d61e3fce5d2d7790cde27a0b57bcb3f341 ]
    
    The Designware SPI driver uses devm_spi_register_controller() on bind.
    As a consequence, on unbind, __device_release_driver() first invokes
    dw_spi_remove_host() before unregistering the SPI controller via
    devres_release_all().
    
    This order is incorrect:  dw_spi_remove_host() shuts down the chip,
    rendering the SPI bus inaccessible even though the SPI controller is
    still registered.  When the SPI controller is subsequently unregistered,
    it unbinds all its slave devices.  Because their drivers cannot access
    the SPI bus, e.g. to quiesce interrupts, the slave devices may be left
    in an improper state.
    
    As a rule, devm_spi_register_controller() must not be used if the
    ->remove() hook performs teardown steps which shall be performed after
    unregistering the controller and specifically after unbinding of slaves.
    
    Fix by reverting to the non-devm variant of spi_register_controller().
    
    An alternative approach would be to use device-managed functions for all
    steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset()
    on probe.  However that approach would add more LoC to the driver and
    it wouldn't lend itself as well to backporting to stable.
    
    Fixes: 04f421e7b0b1 ("spi: dw: use managed resources")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org # v3.14+
    Cc: Baruch Siach <baruch@tkos.co.il>
    Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79645f0e85c4986eb9bbcdc577030502c826e397
Author: Sasha Levin <sashal@kernel.org>
Date:   Mon Jun 15 17:28:08 2020 -0400

    spi: dw: fix possible race condition
    
    [ Upstream commit 66b19d762378785d1568b5650935205edfeb0503 ]
    
    It is possible to get an interrupt as soon as it is requested.  dw_spi_irq
    does spi_controller_get_devdata(master) and expects it to be different than
    NULL. However, spi_controller_set_devdata() is called after request_irq(),
    resulting in the following crash:
    
    CPU 0 Unable to handle kernel paging request at virtual address 00000030, epc == 8058e09c, ra == 8018ff90
    [...]
    Call Trace:
    [<8058e09c>] dw_spi_irq+0x8/0x64
    [<8018ff90>] __handle_irq_event_percpu+0x70/0x1d4
    [<80190128>] handle_irq_event_percpu+0x34/0x8c
    [<801901c4>] handle_irq_event+0x44/0x80
    [<801951a8>] handle_level_irq+0xdc/0x194
    [<8018f580>] generic_handle_irq+0x38/0x50
    [<804c6924>] ocelot_irq_handler+0x104/0x1c0
    
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db39004352a40107213a70dc8e549936a6468fa9
Author: Anthony Steinhauser <asteinhauser@google.com>
Date:   Sun Jun 7 05:44:19 2020 -0700

    x86/speculation: PR_SPEC_FORCE_DISABLE enforcement for indirect branches.
    
    [ Upstream commit 4d8df8cbb9156b0a0ab3f802b80cb5db57acc0bf ]
    
    Currently, it is possible to enable indirect branch speculation even after
    it was force-disabled using the PR_SPEC_FORCE_DISABLE option. Moreover, the
    PR_GET_SPECULATION_CTRL command gives afterwards an incorrect result
    (force-disabled when it is in fact enabled). This also is inconsistent
    vs. STIBP and the documention which cleary states that
    PR_SPEC_FORCE_DISABLE cannot be undone.
    
    Fix this by actually enforcing force-disabled indirect branch
    speculation. PR_SPEC_ENABLE called after PR_SPEC_FORCE_DISABLE now fails
    with -EPERM as described in the documentation.
    
    Fixes: 9137bb27e60e ("x86/speculation: Add prctl() control for indirect branch speculation")
    Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38be87f5e7a7a7378d4ef4528c13bd1d666ab867
Author: Anthony Steinhauser <asteinhauser@google.com>
Date:   Tue May 19 06:40:42 2020 -0700

    x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
    
    [ Upstream commit 21998a351512eba4ed5969006f0c55882d995ada ]
    
    When STIBP is unavailable or enhanced IBRS is available, Linux
    force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
    multithreading is disabled. While attempts to enable IBPB using
    prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
    EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
    which are used e.g. by Chromium or OpenSSH succeed with no errors but the
    application remains silently vulnerable to cross-process Spectre v2 attacks
    (classical BTB poisoning). At the same time the SYSFS reporting
    (/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
    conditionally enabled when in fact it is unconditionally disabled.
    
    STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
    unavailable, it makes no sense to force-disable also IBPB, because IBPB
    protects against cross-process Spectre-BTB attacks regardless of the SMT
    state. At the same time since missing STIBP was only observed on AMD CPUs,
    AMD does not recommend using STIBP, but recommends using IBPB, so disabling
    IBPB because of missing STIBP goes directly against AMD's advice:
    https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
    
    Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
    and BTB-poisoning attacks from user space against kernel (and
    BTB-poisoning attacks from guest against hypervisor), it is not designed
    to prevent cross-process (or cross-VM) BTB poisoning between processes (or
    VMs) running on the same core. Therefore, even with enhanced IBRS it is
    necessary to flush the BTB during context-switches, so there is no reason
    to force disable IBPB when enhanced IBRS is available.
    
    Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
    IBRS is available.
    
    Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
    Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5eaa7ef6506313ca424292ae9f1b8e50c54e6488
Author: Thomas Lendacky <Thomas.Lendacky@amd.com>
Date:   Thu Dec 13 23:03:54 2018 +0000

    x86/speculation: Add support for STIBP always-on preferred mode
    
    [ Upstream commit 20c3a2c33e9fdc82e9e8e8d2a6445b3256d20191 ]
    
    Different AMD processors may have different implementations of STIBP.
    When STIBP is conditionally enabled, some implementations would benefit
    from having STIBP always on instead of toggling the STIBP bit through MSR
    writes. This preference is advertised through a CPUID feature bit.
    
    When conditional STIBP support is requested at boot and the CPU advertises
    STIBP always-on mode as preferred, switch to STIBP "on" support. To show
    that this transition has occurred, create a new spectre_v2_user_mitigation
    value and a new spectre_v2_user_strings message. The new mitigation value
    is used in spectre_v2_user_select_mitigation() to print the new mitigation
    message as well as to return a new string from stibp_state().
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Link: https://lkml.kernel.org/r/20181213230352.6937.74943.stgit@tlendack-t1.amdoffice.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 669ce559aec775e9c26ace076d650e7bbb21e80a
Author: Waiman Long <longman@redhat.com>
Date:   Wed Dec 5 14:49:27 2018 -0500

    x86/speculation: Change misspelled STIPB to STIBP
    
    [ Upstream commit aa77bfb354c495fc4361199e63fc5765b9e1e783 ]
    
    STIBP stands for Single Thread Indirect Branch Predictors. The acronym,
    however, can be easily mis-spelled as STIPB. It is perhaps due to the
    presence of another related term - IBPB (Indirect Branch Predictor
    Barrier).
    
    Fix the mis-spelling in the code.
    
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: KarimAllah Ahmed <karahmed@amazon.de>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/1544039368-9009-1-git-send-email-longman@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 496d422fcbd696e402aa0cac29851338d35b9f18
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Mon Jun 8 18:50:39 2020 +0200

    ALSA: pcm: disallow linking stream to itself
    
    commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
    
    Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
    can't handle it. Fixed commit is not where bug was introduced, but
    changes the context significantly.
    
    Cc: stable@vger.kernel.org
    Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Link: https://lore.kernel.org/r/89c4a2487609a0ed6af3ecf01cc972bdc59a7a2d.1591634956.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 855995d68e9a5c9e633ca6eaf58b3eedae966ab6
Author: Justin Chen <justinpopo6@gmail.com>
Date:   Mon Apr 20 15:08:49 2020 -0400

    spi: bcm-qspi: when tx/rx buffer is NULL set to 0
    
    commit 4df3bea7f9d2ddd9ac2c29ba945c7c4db2def29c upstream.
    
    Currently we set the tx/rx buffer to 0xff when NULL. This causes
    problems with some spi slaves where 0xff is a valid command. Looking
    at other drivers, the tx/rx buffer is usually set to 0x00 when NULL.
    Following this convention solves the issue.
    
    Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver")
    Signed-off-by: Justin Chen <justinpopo6@gmail.com>
    Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200420190853.45614-6-kdasu.kdev@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 639cd86bdadeb83ed603fd6556a64d61189622ec
Author: Lukas Wunner <lukas@wunner.de>
Date:   Fri May 15 17:58:03 2020 +0200

    spi: bcm2835aux: Fix controller unregister order
    
    commit b9dd3f6d417258ad0beeb292a1bc74200149f15d upstream.
    
    The BCM2835aux SPI driver uses devm_spi_register_master() on bind.
    As a consequence, on unbind, __device_release_driver() first invokes
    bcm2835aux_spi_remove() before unregistering the SPI controller via
    devres_release_all().
    
    This order is incorrect:  bcm2835aux_spi_remove() turns off the SPI
    controller, including its interrupts and clock.  The SPI controller
    is thus no longer usable.
    
    When the SPI controller is subsequently unregistered, it unbinds all
    its slave devices.  If their drivers need to access the SPI bus,
    e.g. to quiesce their interrupts, unbinding will fail.
    
    As a rule, devm_spi_register_master() must not be used if the
    ->remove() hook performs teardown steps which shall be performed
    after unbinding of slaves.
    
    Fix by using the non-devm variant spi_register_master().  Note that the
    struct spi_master as well as the driver-private data are not freed until
    after bcm2835aux_spi_remove() has finished, so accessing them is safe.
    
    Fixes: 1ea29b39f4c8 ("spi: bcm2835aux: add bcm2835 auxiliary spi device driver")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v4.4+
    Cc: Martin Sperl <kernel@martin.sperl.org>
    Link: https://lore.kernel.org/r/32f27f4d8242e4d75f9a53f7e8f1f77483b08669.1589557526.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b23abc6de626360b19b4e579ff6b8e3c0c57abe
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Jun 10 18:41:35 2020 -0700

    nilfs2: fix null pointer dereference at nilfs_segctor_do_construct()
    
    commit 8301c719a2bd131436438e49130ee381d30933f5 upstream.
    
    After commit c3aab9a0bd91 ("mm/filemap.c: don't initiate writeback if
    mapping has no dirty pages"), the following null pointer dereference has
    been reported on nilfs2:
    
      BUG: kernel NULL pointer dereference, address: 00000000000000a8
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      ...
      RIP: 0010:percpu_counter_add_batch+0xa/0x60
      ...
      Call Trace:
        __test_set_page_writeback+0x2d3/0x330
        nilfs_segctor_do_construct+0x10d3/0x2110 [nilfs2]
        nilfs_segctor_construct+0x168/0x260 [nilfs2]
        nilfs_segctor_thread+0x127/0x3b0 [nilfs2]
        kthread+0xf8/0x130
        ...
    
    This crash turned out to be caused by set_page_writeback() call for
    segment summary buffers at nilfs_segctor_prepare_write().
    
    set_page_writeback() can call inc_wb_stat(inode_to_wb(inode),
    WB_WRITEBACK) where inode_to_wb(inode) is NULL if the inode of
    underlying block device does not have an associated wb.
    
    This fixes the issue by calling inode_attach_wb() in advance to ensure
    to associate the bdev inode with its wb.
    
    Fixes: c3aab9a0bd91 ("mm/filemap.c: don't initiate writeback if mapping has no dirty pages")
    Reported-by: Walton Hoops <me@waltonhoops.com>
    Reported-by: Tomas Hlavaty <tom@logand.com>
    Reported-by: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
    Reported-by: Hideki EIRAKU <hdk1983@gmail.com>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>    [5.4+]
    Link: http://lkml.kernel.org/r/20200608.011819.1399059588922299158.konishi.ryusuke@gmail.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4341f4655811a2b6540f990e08209b1e47963d7
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jun 27 13:39:48 2019 -0700

    cgroup, blkcg: Prepare some symbols for module and !CONFIG_CGROUP usages
    
    commit 9b0eb69b75bccada2d341d7e7ca342f0cb1c9a6a upstream.
    
    btrfs is going to use css_put() and wbc helpers to improve cgroup
    writeback support.  Add dummy css_get() definition and export wbc
    helpers to prepare for module and !CONFIG_CGROUP builds.
    
    [only backport the export of __inode_attach_wb for stable kernels - gregkh]
    
    Reported-by: kbuild test robot <lkp@intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 744aa65957cf5aa8b040246d7036c56f0a50a46f
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jun 4 19:22:26 2020 +0200

    ACPI: PM: Avoid using power resources if there are none for D0
    
    commit 956ad9d98b73f59e442cc119c98ba1e04e94fe6d upstream.
    
    As recently reported, some platforms provide a list of power
    resources for device power state D3hot, through the _PR3 object,
    but they do not provide a list of power resources for device power
    state D0.
    
    Among other things, this causes acpi_device_get_power() to return
    D3hot as the current state of the device in question if all of the
    D3hot power resources are "on", because it sees the power_resources
    flag set and calls acpi_power_get_inferred_state() which finds that
    D3hot is the shallowest power state with all of the associated power
    resources turned "on", so that's what it returns.  Moreover, that
    value takes precedence over the acpi_dev_pm_explicit_get() return
    value, because it means a deeper power state.  The device may very
    well be in D0 physically at that point, however.
    
    Moreover, the presence of _PR3 without _PR0 for a given device
    means that only one D3-level power state can be supported by it.
    Namely, because there are no power resources to turn "off" when
    transitioning the device from D0 into D3cold (which should be
    supported since _PR3 is present), the evaluation of _PS3 should
    be sufficient to put it straight into D3cold, but this means that
    the effect of turning "on" the _PR3 power resources is unclear,
    so it is better to avoid doing that altogether.  Consequently,
    there is no practical way do distinguish D3cold from D3hot for
    the device in question and the power states of it can be labeled
    so that D3hot is the deepest supported one (and Linux assumes
    that putting a device into D3hot via ACPI may cause power to be
    removed from it anyway, for legacy reasons).
    
    To work around the problem described above modify the ACPI
    enumeration of devices so that power resources are only used
    for device power management if the list of D0 power resources
    is not empty and make it mart D3cold as supported only if that
    is the case and the D3hot list of power resources is not empty
    too.
    
    Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057
    Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: youling257@gmail.com
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac0a27243228c1f867873c90160881292241e483
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri May 15 11:36:13 2020 +0200

    ACPI: GED: add support for _Exx / _Lxx handler methods
    
    commit ea6f3af4c5e63f6981c0b0ab8ebec438e2d5ef40 upstream.
    
    Per the ACPI spec, interrupts in the range [0, 255] may be handled
    in AML using individual methods whose naming is based on the format
    _Exx or _Lxx, where xx is the hex representation of the interrupt
    index.
    
    Add support for this missing feature to our ACPI GED driver.
    
    Cc: v4.9+ <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17cac70bdf319d85e6f4ba78f686c06ee55f86cf
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Wed May 27 17:35:51 2020 -0500

    ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()
    
    commit 4d8be4bc94f74bb7d096e1c2e44457b530d5a170 upstream.
    
    kobject_init_and_add() takes reference even when it fails.
    If this function returns an error, kobject_put() must be called to
    properly clean up the memory associated with the object. Previous
    commit "b8eb718348b8" fixed a similar problem.
    
    Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance")
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdce493344432a5ce4afa45e6ec8d14edd8dd468
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Wed May 27 16:17:17 2020 -0500

    ACPI: sysfs: Fix reference count leak in acpi_sysfs_add_hotplug_profile()
    
    commit 6e6c25283dff866308c87b49434c7dbad4774cc0 upstream.
    
    kobject_init_and_add() takes reference even when it fails.
    Thus, when kobject_init_and_add() returns an error,
    kobject_put() must be called to properly clean up the kobject.
    
    Fixes: 3f8055c35836 ("ACPI / hotplug: Introduce user space interface for hotplug profiles")
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4df2c5f97951b1767005e79bd7d5897694539c0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jun 3 17:37:08 2020 +0200

    ALSA: usb-audio: Fix inconsistent card PM state after resume
    
    commit 862b2509d157c629dd26d7ac6c6cdbf043d332eb upstream.
    
    When a USB-audio interface gets runtime-suspended via auto-pm feature,
    the driver suspends all functionality and increment
    chip->num_suspended_intf.  Later on, when the system gets suspended to
    S3, the driver increments chip->num_suspended_intf again, skips the
    device changes, and sets the card power state to
    SNDRV_CTL_POWER_D3hot.  In return, when the system gets resumed from
    S3, the resume callback decrements chip->num_suspended_intf.  Since
    this refcount is still not zero (it's been runtime-suspended), the
    whole resume is skipped.  But there is a small pitfall here.
    
    The problem is that the driver doesn't restore the card power state
    after this resume call, leaving it as SNDRV_CTL_POWER_D3hot.  So,
    even after the system resume finishes, the card instance still appears
    as if it were system-suspended, and this confuses many ioctl accesses
    that are blocked unexpectedly.
    
    In details, we have two issues behind the scene: one is that the card
    power state is changed only when the refcount becomes zero, and
    another is that the prior auto-suspend check is kept in a boolean
    flag.  Although the latter problem is almost negligible since the
    auto-pm feature is imposed only on the primary interface, but this can
    be a potential problem on the devices with multiple interfaces.
    
    This patch addresses those issues by the following:
    
    - Replace chip->autosuspended boolean flag with chip->system_suspend
      counter
    
    - At the first system-suspend, chip->num_suspended_intf is recorded to
      chip->system_suspend
    
    - At system-resume, the card power state is restored when the
      chip->num_suspended_intf refcount reaches to chip->system_suspend,
      i.e. the state returns to the auto-suspended
    
    Also, the patch fixes yet another hidden problem by the code
    refactoring along with the fixes above: namely, when some resume
    procedure failed, the driver left chip->num_suspended_intf that was
    already decreased, and it might lead to the refcount unbalance.
    In the new code, the refcount decrement is done after the whole resume
    procedure, and the problem is avoided as well.
    
    Fixes: 0662292aec05 ("ALSA: usb-audio: Handle normal and auto-suspend equally")
    Reported-and-tested-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200603153709.6293-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 008eaa9e6b84b0325c7725ce8918c47692e99641
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Wed Jun 3 17:24:59 2020 +0800

    ALSA: es1688: Add the missed snd_card_free()
    
    commit d9b8fbf15d05350b36081eddafcf7b15aa1add50 upstream.
    
    snd_es968_pnp_detect() misses a snd_card_free() in a failed path.
    Add the missed function call to fix it.
    
    Fixes: a20971b201ac ("ALSA: Merge es1688 and es968 drivers")
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200603092459.1424093-1-hslester96@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e8fd13caaa1403c4b776acc2f9e2e21d4dfe00f
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri May 22 18:15:49 2020 +0200

    efi/efivars: Add missing kobject_put() in sysfs entry creation error path
    
    commit d8bd8c6e2cfab8b78b537715255be8d7557791c0 upstream.
    
    The documentation provided by kobject_init_and_add() clearly spells out
    the need to call kobject_put() on the kobject if an error is returned.
    Add this missing call to the error path.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: 亿一 <teroincn@gmail.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc66d80027fc21111b2241a3bb0fc7ec21f99125
Author: Hill Ma <maahiuzeon@gmail.com>
Date:   Sat Apr 25 13:06:41 2020 -0700

    x86/reboot/quirks: Add MacBook6,1 reboot quirk
    
    commit 140fd4ac78d385e6c8e6a5757585f6c707085f87 upstream.
    
    On MacBook6,1 reboot would hang unless parameter reboot=pci is added.
    Make it automatic.
    
    Signed-off-by: Hill Ma <maahiuzeon@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20200425200641.GA1554@cslab.localdomain
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc0abf5a64ea5d028af0cf5d37d5898afe6748c5
Author: Anthony Steinhauser <asteinhauser@google.com>
Date:   Sun Jan 5 12:19:43 2020 -0800

    x86/speculation: Prevent rogue cross-process SSBD shutdown
    
    commit dbbe2ad02e9df26e372f38cc3e70dab9222c832e upstream.
    
    On context switch the change of TIF_SSBD and TIF_SPEC_IB are evaluated
    to adjust the mitigations accordingly. This is optimized to avoid the
    expensive MSR write if not needed.
    
    This optimization is buggy and allows an attacker to shutdown the SSBD
    protection of a victim process.
    
    The update logic reads the cached base value for the speculation control
    MSR which has neither the SSBD nor the STIBP bit set. It then OR's the
    SSBD bit only when TIF_SSBD is different and requests the MSR update.
    
    That means if TIF_SSBD of the previous and next task are the same, then
    the base value is not updated, even if TIF_SSBD is set. The MSR write is
    not requested.
    
    Subsequently if the TIF_STIBP bit differs then the STIBP bit is updated
    in the base value and the MSR is written with a wrong SSBD value.
    
    This was introduced when the per task/process conditional STIPB
    switching was added on top of the existing SSBD switching.
    
    It is exploitable if the attacker creates a process which enforces SSBD
    and has the contrary value of STIBP than the victim process (i.e. if the
    victim process enforces STIBP, the attacker process must not enforce it;
    if the victim process does not enforce STIBP, the attacker process must
    enforce it) and schedule it on the same core as the victim process. If
    the victim runs after the attacker the victim becomes vulnerable to
    Spectre V4.
    
    To fix this, update the MSR value independent of the TIF_SSBD difference
    and dependent on the SSBD mitigation method available. This ensures that
    a subsequent STIPB initiated MSR write has the correct state of SSBD.
    
    [ tglx: Handle X86_FEATURE_VIRT_SSBD & X86_FEATURE_VIRT_SSBD correctly
            and massaged changelog ]
    
    Fixes: 5bfbe3ad5840 ("x86/speculation: Prepare for per task indirect branch speculation control")
    Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4046a2e4f6f5f07c1bd5ecb2dcdcca185cc0e53e
Author: Xiaochun Lee <lixc17@lenovo.com>
Date:   Thu May 14 23:31:07 2020 -0400

    x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs
    
    commit 1574051e52cb4b5b7f7509cfd729b76ca1117808 upstream.
    
    The Intel C620 Platform Controller Hub has MROM functions that have non-PCI
    registers (undocumented in the public spec) where BAR 0 is supposed to be,
    which results in messages like this:
    
      pci 0000:00:11.0: [Firmware Bug]: reg 0x30: invalid BAR (can't size)
    
    Mark these MROM functions as having non-compliant BARs so we don't try to
    probe any of them.  There are no other BARs on these devices.
    
    See the Intel C620 Series Chipset Platform Controller Hub Datasheet,
    May 2019, Document Number 336067-007US, sec 2.1, 35.5, 35.6.
    
    [bhelgaas: commit log, add 0xa26d]
    Link: https://lore.kernel.org/r/1589513467-17070-1-git-send-email-lixiaochun.2888@163.com
    Signed-off-by: Xiaochun Lee <lixc17@lenovo.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79138a2f6e322f3dac4b12a67cb5a2e263eecd9c
Author: Bob Haarman <inglorion@google.com>
Date:   Tue Jun 2 12:30:59 2020 -0700

    x86_64: Fix jiffies ODR violation
    
    commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream.
    
    'jiffies' and 'jiffies_64' are meant to alias (two different symbols that
    share the same address).  Most architectures make the symbols alias to the
    same address via a linker script assignment in their
    arch/<arch>/kernel/vmlinux.lds.S:
    
    jiffies = jiffies_64;
    
    which is effectively a definition of jiffies.
    
    jiffies and jiffies_64 are both forward declared for all architectures in
    include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c.
    
    x86_64 was peculiar in that it wasn't doing the above linker script
    assignment, but rather was:
    1. defining jiffies in arch/x86/kernel/time.c instead via the linker script.
    2. overriding the symbol jiffies_64 from kernel/time/timer.c in
    arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'.
    
    As Fangrui notes:
    
      In LLD, symbol assignments in linker scripts override definitions in
      object files. GNU ld appears to have the same behavior. It would
      probably make sense for LLD to error "duplicate symbol" but GNU ld
      is unlikely to adopt for compatibility reasons.
    
    This results in an ODR violation (UB), which seems to have survived
    thus far. Where it becomes harmful is when;
    
    1. -fno-semantic-interposition is used:
    
    As Fangrui notes:
    
      Clang after LLVM commit 5b22bcc2b70d
      ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local")
      defaults to -fno-semantic-interposition similar semantics which help
      -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined
      within the same translation unit. Unlike GCC
      -fno-semantic-interposition, Clang emits such relocations referencing
      local symbols for non-pic code as well.
    
    This causes references to jiffies to refer to '.Ljiffies$local' when
    jiffies is defined in the same translation unit. Likewise, references to
    jiffies_64 become references to '.Ljiffies_64$local' in translation units
    that define jiffies_64.  Because these differ from the names used in the
    linker script, they will not be rewritten to alias one another.
    
    2. Full LTO
    
    Full LTO effectively treats all source files as one translation
    unit, causing these local references to be produced everywhere.  When
    the linker processes the linker script, there are no longer any
    references to jiffies_64' anywhere to replace with 'jiffies'.  And
    thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias
    at all.
    
    In the process of porting patches enabling Full LTO from arm64 to x86_64,
    spooky bugs have been observed where the kernel appeared to boot, but init
    doesn't get scheduled.
    
    Avoid the ODR violation by matching other architectures and define jiffies
    only by linker script.  For -fno-semantic-interposition + Full LTO, there
    is no longer a global definition of jiffies for the compiler to produce a
    local symbol which the linker script won't ensure aliases to jiffies_64.
    
    Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible")
    Reported-by: Nathan Chancellor <natechancellor@gmail.com>
    Reported-by: Alistair Delva <adelva@google.com>
    Debugged-by: Nick Desaulniers <ndesaulniers@google.com>
    Debugged-by: Sami Tolvanen <samitolvanen@google.com>
    Suggested-by: Fangrui Song <maskray@google.com>
    Signed-off-by: Bob Haarman <inglorion@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # build+boot on
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://github.com/ClangBuiltLinux/linux/issues/852
    Link: https://lkml.kernel.org/r/20200602193100.229287-1-inglorion@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42133b6931b976fc987417a8e572628ac6c64018
Author: Masashi Honma <masashi.honma@gmail.com>
Date:   Tue May 5 06:44:43 2020 +0900

    ath9k_htc: Silence undersized packet warnings
    
    [ Upstream commit 450edd2805982d14ed79733a82927d2857b27cac ]
    
    Some devices like TP-Link TL-WN722N produces this kind of messages
    frequently.
    
    kernel: ath: phy0: Short RX data len, dropping (dlen: 4)
    
    This warning is useful for developers to recognize that the device
    (Wi-Fi dongle or USB hub etc) is noisy but not for general users. So
    this patch make this warning to debug message.
    
    Reported-By: Denis <pro.denis@protonmail.com>
    Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207539
    Fixes: cd486e627e67 ("ath9k_htc: Discard undersized packets")
    Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200504214443.4485-1-masashi.honma@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c465ee6aeb130687a9cd8605b363273800d0cff6
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Thu May 28 11:19:17 2020 -0500

    drivers/net/ibmvnic: Update VNIC protocol version reporting
    
    [ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ]
    
    VNIC protocol version is reported in big-endian format, but it
    is not byteswapped before logging. Fix that, and remove version
    comparison as only one protocol version exists at this time.
    
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4205ab13e3e6cfcc290da48f1af33add7cb75252
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue May 26 09:38:31 2020 -0600

    sched/fair: Don't NUMA balance for kthreads
    
    [ Upstream commit 18f855e574d9799a0e7489f8ae6fd8447d0dd74a ]
    
    Stefano reported a crash with using SQPOLL with io_uring:
    
      BUG: kernel NULL pointer dereference, address: 00000000000003b0
      CPU: 2 PID: 1307 Comm: io_uring-sq Not tainted 5.7.0-rc7 #11
      RIP: 0010:task_numa_work+0x4f/0x2c0
      Call Trace:
       task_work_run+0x68/0xa0
       io_sq_thread+0x252/0x3d0
       kthread+0xf9/0x130
       ret_from_fork+0x35/0x40
    
    which is task_numa_work() oopsing on current->mm being NULL.
    
    The task work is queued by task_tick_numa(), which checks if current->mm is
    NULL at the time of the call. But this state isn't necessarily persistent,
    if the kthread is using use_mm() to temporarily adopt the mm of a task.
    
    Change the task_tick_numa() check to exclude kernel threads in general,
    as it doesn't make sense to attempt ot balance for kthreads anyway.
    
    Reported-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/865de121-8190-5d30-ece5-3b097dc74431@kernel.dk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d95c626d0b89ddbd223d210cafa07b38e53d9898
Author: Fredrik Strupe <fredrik@strupe.net>
Date:   Mon May 18 19:41:11 2020 +0100

    ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook
    
    [ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ]
    
    call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
    and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
    (0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
    instructions will be masked out. This makes the function match 32-bit
    thumb instructions where the second half-word is equal to instr_val,
    regardless of the first half-word.
    
    The result in this case is that all undefined 32-bit thumb instructions
    with the second half-word equal to 0xde01 (udf #1) work as breakpoints
    and will raise a SIGTRAP instead of a SIGILL, instead of just the one
    intended 16-bit instruction. An example of such an instruction is
    0xeaa0de01, which is unallocated according to Arm ARM and should raise a
    SIGILL, but instead raises a SIGTRAP.
    
    This patch fixes the issue by setting all the bits in instr_mask, which
    will still match the intended 16-bit thumb instruction (where the
    upper half is always 0), but not any 32-bit thumb instructions.
    
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adbbd088ab97077fa0529740ec43185c7fb7cdd5
Author: Su Kang Yin <cantona@cantona.net>
Date:   Thu Jun 11 19:50:47 2020 +0800

    crypto: talitos - fix ECB and CBC algs ivsize
    
    commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
    wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
    
    This restore the CBC algs original ivsize of removes ECB's ones.
    
    Fixes: e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
    Signed-off-by: Su Kang Yin <cantona@cantona.net>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07e0b16899ebc1f8bf0558561869be1612decd53
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Wed Apr 12 09:21:19 2017 +0200

    scsi: return correct blkprep status code in case scsi_init_io() fails.
    
    commit e7661a8e5ce10b5321882d0bbaf3f81070903319 upstream.
    
    When instrumenting the SCSI layer to run into the
    !blk_rq_nr_phys_segments(rq) case the following warning emitted from the
    block layer:
    
    blk_peek_request: bad return=-22
    
    This happens because since commit fd3fc0b4d730 ("scsi: don't BUG_ON()
    empty DMA transfers") we return the wrong error value from
    scsi_prep_fn() back to the block layer.
    
    [mkp: silenced checkpatch]
    
    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Fixes: fd3fc0b4d730 scsi: don't BUG_ON() empty DMA transfers
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [iwamatsu: - backport for 4.4.y and 4.9.y
        - Use rq->nr_phys_segments instead of blk_rq_nr_phys_segments]
    Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72787b04621661e9e9a63af4215749a938233e2a
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Mon Jun 1 15:58:55 2020 +0300

    vxlan: Avoid infinite loop when suppressing NS messages with invalid options
    
    [ Upstream commit 8066e6b449e050675df48e7c4b16c29f00507ff0 ]
    
    When proxy mode is enabled the vxlan device might reply to Neighbor
    Solicitation (NS) messages on behalf of remote hosts.
    
    In case the NS message includes the "Source link-layer address" option
    [1], the vxlan device will use the specified address as the link-layer
    destination address in its reply.
    
    To avoid an infinite loop, break out of the options parsing loop when
    encountering an option with length zero and disregard the NS message.
    
    This is consistent with the IPv6 ndisc code and RFC 4886 which states
    that "Nodes MUST silently discard an ND packet that contains an option
    with length zero" [2].
    
    [1] https://tools.ietf.org/html/rfc4861#section-4.3
    [2] https://tools.ietf.org/html/rfc4861#section-4.6
    
    Fixes: 4b29dba9c085 ("vxlan: fix nonfunctional neigh_reduce()")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47fb86422692fac566708d2719226c1a2f857249
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Mon Jun 1 11:55:03 2020 +0800

    ipv6: fix IPV6_ADDRFORM operation logic
    
    [ Upstream commit 79a1f0ccdbb4ad700590f61b00525b390cb53905 ]
    
    Socket option IPV6_ADDRFORM supports UDP/UDPLITE and TCP at present.
    Previously the checking logic looks like:
    if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE)
            do_some_check;
    else if (sk->sk_protocol != IPPROTO_TCP)
            break;
    
    After commit b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation"), TCP
    was blocked as the logic changed to:
    if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE)
            do_some_check;
    else if (sk->sk_protocol == IPPROTO_TCP)
            do_some_check;
            break;
    else
            break;
    
    Then after commit 82c9ae440857 ("ipv6: fix restrict IPV6_ADDRFORM operation")
    UDP/UDPLITE were blocked as the logic changed to:
    if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE)
            do_some_check;
    if (sk->sk_protocol == IPPROTO_TCP)
            do_some_check;
    
    if (sk->sk_protocol != IPPROTO_TCP)
            break;
    
    Fix it by using Eric's code and simply remove the break in TCP check, which
    looks like:
    if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE)
            do_some_check;
    else if (sk->sk_protocol == IPPROTO_TCP)
            do_some_check;
    else
            break;
    
    Fixes: 82c9ae440857 ("ipv6: fix restrict IPV6_ADDRFORM operation")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>