commit 6a24ca2506d64598eac5d5219e99acca9bde4ca5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 21 09:48:24 2020 +0200

    Linux 4.14.194
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b61727de55249d2754a93f4ea617ade1e329b22a
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Oct 19 17:30:20 2017 -0400

    dm cache: remove all obsolete writethrough-specific code
    
    commit 9958f1d9a04efb3db19134482b3f4c6897e0e7b8 upstream.
    
    Now that the writethrough code is much simpler there is no need to track
    so much state or cascade bio submission (as was done, via
    writethrough_endio(), to issue origin then cache IO in series).
    
    As such the obsolete writethrough list and workqueue is also removed.
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8036335f8f4feddcdc118c4442e6e7af9c8116d8
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Oct 19 17:16:54 2017 -0400

    dm cache: submit writethrough writes in parallel to origin and cache
    
    commit 2df3bae9a6543e90042291707b8db0cbfbae9ee9 upstream.
    
    Discontinue issuing writethrough write IO in series to the origin and
    then cache.
    
    Use bio_clone_fast() to create a new origin clone bio that will be
    mapped to the origin device and then bio_chain() it to the bio that gets
    remapped to the cache device.  The origin clone bio does _not_ have a
    copy of the per_bio_data -- as such check_if_tick_bio_needed() will not
    be called.
    
    The cache bio (parent bio) will not complete until the origin bio has
    completed -- this fulfills bio_clone_fast()'s requirements as well as
    the requirement to not complete the original IO until the write IO has
    completed to both the origin and cache device.
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 755b4e83e11cfc530e426e1f717e97dc8af31d3d
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Oct 19 21:01:04 2017 -0400

    dm cache: pass cache structure to mode functions
    
    commit 8e3c3827776fc93728c0c8d7c7b731226dc6ee23 upstream.
    
    No functional changes, just a bit cleaner than passing cache_features
    structure.
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a7a29935d98567331ae26b183422e22f4d0ae90
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Jul 24 22:44:41 2020 +0200

    genirq/affinity: Make affinity setting if activated opt-in
    
    commit f0c7baca180046824e07fc5f1326e83a8fd150c7 upstream.
    
    John reported that on a RK3288 system the perf per CPU interrupts are all
    affine to CPU0 and provided the analysis:
    
     "It looks like what happens is that because the interrupts are not per-CPU
      in the hardware, armpmu_request_irq() calls irq_force_affinity() while
      the interrupt is deactivated and then request_irq() with IRQF_PERCPU |
      IRQF_NOBALANCING.
    
      Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls
      irq_setup_affinity() which returns early because IRQF_PERCPU and
      IRQF_NOBALANCING are set, leaving the interrupt on its original CPU."
    
    This was broken by the recent commit which blocked interrupt affinity
    setting in hardware before activation of the interrupt. While this works in
    general, it does not work for this particular case. As contrary to the
    initial analysis not all interrupt chip drivers implement an activate
    callback, the safe cure is to make the deferred interrupt affinity setting
    at activation time opt-in.
    
    Implement the necessary core logic and make the two irqchip implementations
    for which this is required opt-in. In hindsight this would have been the
    right thing to do, but ...
    
    Fixes: baedb87d1b53 ("genirq/affinity: Handle affinity setting on inactive interrupts correctly")
    Reported-by: John Keeping <john@metanate.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/87blk4tzgm.fsf@nanos.tec.linutronix.de
    [fllinden@amazon.com - backported to 4.14]
    Signed-off-by: Frank van der Linden <fllinden@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da54edbe563866eb2bd57a12bc8f76ddc88fc369
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Jul 17 18:00:02 2020 +0200

    genirq/affinity: Handle affinity setting on inactive interrupts correctly
    
    commit baedb87d1b53532f81b4bd0387f83b05d4f7eb9a upstream.
    
    Setting interrupt affinity on inactive interrupts is inconsistent when
    hierarchical irq domains are enabled. The core code should just store the
    affinity and not call into the irq chip driver for inactive interrupts
    because the chip drivers may not be in a state to handle such requests.
    
    X86 has a hacky workaround for that but all other irq chips have not which
    causes problems e.g. on GIC V3 ITS.
    
    Instead of adding more ugly hacks all over the place, solve the problem in
    the core code. If the affinity is set on an inactive interrupt then:
    
        - Store it in the irq descriptors affinity mask
        - Update the effective affinity to reflect that so user space has
          a consistent view
        - Don't call into the irq chip driver
    
    This is the core equivalent of the X86 workaround and works correctly
    because the affinity setting is established in the irq chip when the
    interrupt is activated later on.
    
    Note, that this is only effective when hierarchical irq domains are enabled
    by the architecture. Doing it unconditionally would break legacy irq chip
    implementations.
    
    For hierarchial irq domains this works correctly as none of the drivers can
    have a dependency on affinity setting in inactive state by design.
    
    Remove the X86 workaround as it is not longer required.
    
    Fixes: 02edee152d6e ("x86/apic/vector: Ignore set_affinity call for inactive interrupts")
    Reported-by: Ali Saidi <alisaidi@amazon.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Ali Saidi <alisaidi@amazon.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200529015501.15771-1-alisaidi@amazon.com
    Link: https://lkml.kernel.org/r/877dv2rv25.fsf@nanos.tec.linutronix.de
    [fllinden@amazon.com - 4.14 never had the x86 workaround, so skip x86 changes]
    Signed-off-by: Frank van der Linden <fllinden@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 463af34829c9d1bd25a82210c502a3009807d9fb
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Aug 6 23:26:22 2020 -0700

    khugepaged: retract_page_tables() remember to test exit
    
    commit 18e77600f7a1ed69f8ce46c9e11cad0985712dfa upstream.
    
    Only once have I seen this scenario (and forgot even to notice what forced
    the eventual crash): a sequence of "BUG: Bad page map" alerts from
    vm_normal_page(), from zap_pte_range() servicing exit_mmap();
    pmd:00000000, pte values corresponding to data in physical page 0.
    
    The pte mappings being zapped in this case were supposed to be from a huge
    page of ext4 text (but could as well have been shmem): my belief is that
    it was racing with collapse_file()'s retract_page_tables(), found *pmd
    pointing to a page table, locked it, but *pmd had become 0 by the time
    start_pte was decided.
    
    In most cases, that possibility is excluded by holding mmap lock; but
    exit_mmap() proceeds without mmap lock.  Most of what's run by khugepaged
    checks khugepaged_test_exit() after acquiring mmap lock:
    khugepaged_collapse_pte_mapped_thps() and hugepage_vma_revalidate() do so,
    for example.  But retract_page_tables() did not: fix that.
    
    The fix is for retract_page_tables() to check khugepaged_test_exit(),
    after acquiring mmap lock, before doing anything to the page table.
    Getting the mmap lock serializes with __mmput(), which briefly takes and
    drops it in __khugepaged_exit(); then the khugepaged_test_exit() check on
    mm_users makes sure we don't touch the page table once exit_mmap() might
    reach it, since exit_mmap() will be proceeding without mmap lock, not
    expecting anyone to be racing with it.
    
    Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008021215400.27773@eggly.anvils
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22c900e6ffa62b5ae3679a9853e9690f32676e34
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Aug 14 14:42:45 2020 +0200

    sh: landisk: Add missing initialization of sh_io_port_base
    
    [ Upstream commit 0c64a0dce51faa9c706fdf1f957d6f19878f4b81 ]
    
    The Landisk setup code maps the CF IDE area using ioremap_prot(), and
    passes the resulting virtual addresses to the pata_platform driver,
    disguising them as I/O port addresses.  Hence the pata_platform driver
    translates them again using ioport_map().
    As CONFIG_GENERIC_IOMAP=n, and CONFIG_HAS_IOPORT_MAP=y, the
    SuperH-specific mapping code in arch/sh/kernel/ioport.c translates
    I/O port addresses to virtual addresses by adding sh_io_port_base, which
    defaults to -1, thus breaking the assumption of an identity mapping.
    
    Fix this by setting sh_io_port_base to zero.
    
    Fixes: 37b7a97884ba64bf ("sh: machvec IO death.")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Rich Felker <dalias@libc.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 364c02263a1831075c967e9245165243a82ba851
Author: Daniel Díaz <daniel.diaz@linaro.org>
Date:   Wed Aug 12 17:15:17 2020 -0500

    tools build feature: Quote CC and CXX for their arguments
    
    [ Upstream commit fa5c893181ed2ca2f96552f50073786d2cfce6c0 ]
    
    When using a cross-compilation environment, such as OpenEmbedded,
    the CC an CXX variables are set to something more than just a
    command: there are arguments (such as --sysroot) that need to be
    passed on to the compiler so that the right set of headers and
    libraries are used.
    
    For the particular case that our systems detected, CC is set to
    the following:
    
      export CC="aarch64-linaro-linux-gcc  --sysroot=/oe/build/tmp/work/machine/perf/1.0-r9/recipe-sysroot"
    
    Without quotes, detection is as follows:
    
      Auto-detecting system features:
      ...                         dwarf: [ OFF ]
      ...            dwarf_getlocations: [ OFF ]
      ...                         glibc: [ OFF ]
      ...                          gtk2: [ OFF ]
      ...                        libbfd: [ OFF ]
      ...                        libcap: [ OFF ]
      ...                        libelf: [ OFF ]
      ...                       libnuma: [ OFF ]
      ...        numa_num_possible_cpus: [ OFF ]
      ...                       libperl: [ OFF ]
      ...                     libpython: [ OFF ]
      ...                     libcrypto: [ OFF ]
      ...                     libunwind: [ OFF ]
      ...            libdw-dwarf-unwind: [ OFF ]
      ...                          zlib: [ OFF ]
      ...                          lzma: [ OFF ]
      ...                     get_cpuid: [ OFF ]
      ...                           bpf: [ OFF ]
      ...                        libaio: [ OFF ]
      ...                       libzstd: [ OFF ]
      ...        disassembler-four-args: [ OFF ]
    
      Makefile.config:414: *** No gnu/libc-version.h found, please install glibc-dev[el].  Stop.
      Makefile.perf:230: recipe for target 'sub-make' failed
      make[1]: *** [sub-make] Error 2
      Makefile:69: recipe for target 'all' failed
      make: *** [all] Error 2
    
    With CC and CXX quoted, some of those features are now detected.
    
    Fixes: e3232c2f39ac ("tools build feature: Use CC and CXX from parent")
    Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
    Reviewed-by: Thomas Hebb <tommyhebb@gmail.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andrii Nakryiko <andriin@fb.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: KP Singh <kpsingh@chromium.org>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Yonghong Song <yhs@fb.com>
    Link: http://lore.kernel.org/lkml/20200812221518.2869003-1-daniel.diaz@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23e444f93405e0fce23795d4f64bae4c08d8a156
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Mon Aug 10 15:34:04 2020 +0200

    perf bench mem: Always memset source before memcpy
    
    [ Upstream commit 1beaef29c34154ccdcb3f1ae557f6883eda18840 ]
    
    For memcpy, the source pages are memset to zero only when --cycles is
    used.  This leads to wildly different results with or without --cycles,
    since all sources pages are likely to be mapped to the same zero page
    without explicit writes.
    
    Before this fix:
    
    $ export cmd="./perf stat -e LLC-loads -- ./perf bench \
      mem memcpy -s 1024MB -l 100 -f default"
    $ $cmd
    
             2,935,826      LLC-loads
           3.821677452 seconds time elapsed
    
    $ $cmd --cycles
    
           217,533,436      LLC-loads
           8.616725985 seconds time elapsed
    
    After this fix:
    
    $ $cmd
    
           214,459,686      LLC-loads
           8.674301124 seconds time elapsed
    
    $ $cmd --cycles
    
           214,758,651      LLC-loads
           8.644480006 seconds time elapsed
    
    Fixes: 47b5757bac03c338 ("perf bench mem: Move boilerplate memory allocation to the infrastructure")
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: kernel@axis.com
    Link: http://lore.kernel.org/lkml/20200810133404.30829-1-vincent.whitchurch@axis.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ef79789689b7c1126cc8c279c50738b0c01506a
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Thu Aug 13 15:46:30 2020 +0800

    ALSA: echoaudio: Fix potential Oops in snd_echo_resume()
    
    [ Upstream commit 5a25de6df789cc805a9b8ba7ab5deef5067af47e ]
    
    Freeing chip on error may lead to an Oops at the next time
    the system goes to resume. Fix this by removing all
    snd_echo_free() calls on error.
    
    Fixes: 47b5d028fdce8 ("ALSA: Echoaudio - Add suspend support #2")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20200813074632.17022-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4c83f8e6490f2454dfc029dbdedb6bc7773d549
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Jul 23 16:02:46 2020 +0300

    mfd: dln2: Run event handler loop under spinlock
    
    [ Upstream commit 3d858942250820b9adc35f963a257481d6d4c81d ]
    
    The event handler loop must be run with interrupts disabled.
    Otherwise we will have a warning:
    
    [ 1970.785649] irq 31 handler lineevent_irq_handler+0x0/0x20 enabled interrupts
    [ 1970.792739] WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x162/0x170
    [ 1970.860732] RIP: 0010:__handle_irq_event_percpu+0x162/0x170
    ...
    [ 1970.946994] Call Trace:
    [ 1970.949446]  <IRQ>
    [ 1970.951471]  handle_irq_event_percpu+0x2c/0x80
    [ 1970.955921]  handle_irq_event+0x23/0x43
    [ 1970.959766]  handle_simple_irq+0x57/0x70
    [ 1970.963695]  generic_handle_irq+0x42/0x50
    [ 1970.967717]  dln2_rx+0xc1/0x210 [dln2]
    [ 1970.971479]  ? usb_hcd_unmap_urb_for_dma+0xa6/0x1c0
    [ 1970.976362]  __usb_hcd_giveback_urb+0x77/0xe0
    [ 1970.980727]  usb_giveback_urb_bh+0x8e/0xe0
    [ 1970.984837]  tasklet_action_common.isra.0+0x4a/0xe0
    ...
    
    Recently xHCI driver switched to tasklets in the commit 36dc01657b49
    ("usb: host: xhci: Support running urb giveback in tasklet context").
    
    The handle_irq_event_* functions are expected to be called with interrupts
    disabled and they rightfully complain here because we run in tasklet context
    with interrupts enabled.
    
    Use a event spinlock to protect event handler from being interrupted.
    
    Note, that there are only two users of this GPIO and ADC drivers and both of
    them are using generic_handle_irq() which makes above happen.
    
    Fixes: 338a12814297 ("mfd: Add support for Diolan DLN-2 devices")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40e009db0712ff065471950990be766eddd2d53e
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Aug 11 18:36:16 2020 -0700

    test_kmod: avoid potential double free in trigger_config_run_type()
    
    [ Upstream commit 0776d1231bec0c7ab43baf440a3f5ef5f49dd795 ]
    
    Reset the member "test_fs" of the test configuration after a call of the
    function "kfree_const" to a null pointer so that a double memory release
    will not be performed.
    
    Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader")
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Chuck Lever <chuck.lever@oracle.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: James Morris <jmorris@namei.org>
    Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Cc: J. Bruce Fields <bfields@fieldses.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Lars Ellenberg <lars.ellenberg@linbit.com>
    Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Cc: Philipp Reisner <philipp.reisner@linbit.com>
    Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
    Cc: "Serge E. Hallyn" <serge@hallyn.com>
    Cc: Sergei Trofimovich <slyfox@gentoo.org>
    Cc: Sergey Kvachonok <ravenexp@gmail.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Tony Vroon <chainsaw@gentoo.org>
    Cc: Christoph Hellwig <hch@infradead.org>
    Link: http://lkml.kernel.org/r/20200610154923.27510-4-mcgrof@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50d3cd6fedfc40345b018cc0552bb62a47e1a155
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Aug 11 18:35:53 2020 -0700

    fs/ufs: avoid potential u32 multiplication overflow
    
    [ Upstream commit 88b2e9b06381551b707d980627ad0591191f7a2d ]
    
    The 64 bit ino is being compared to the product of two u32 values,
    however, the multiplication is being performed using a 32 bit multiply so
    there is a potential of an overflow.  To be fully safe, cast uspi->s_ncg
    to a u64 to ensure a 64 bit multiplication occurs to avoid any chance of
    overflow.
    
    Fixes: f3e2a520f5fb ("ufs: NFS support")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Evgeniy Dushistov <dushistov@mail.ru>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Link: http://lkml.kernel.org/r/20200715170355.1081713-1-colin.king@canonical.com
    Addresses-Coverity: ("Unintentional integer overflow")
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4ddf4e58946c7dfe8568a21ee3d27b03d96bc56
Author: Jeffrey Mitchell <jeffrey.mitchell@starlab.io>
Date:   Wed Aug 5 12:23:19 2020 -0500

    nfs: Fix getxattr kernel panic and memory overflow
    
    [ Upstream commit b4487b93545214a9db8cbf32e86411677b0cca21 ]
    
    Move the buffer size check to decode_attr_security_label() before memcpy()
    Only call memcpy() if the buffer is large enough
    
    Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
    Signed-off-by: Jeffrey Mitchell <jeffrey.mitchell@starlab.io>
    [Trond: clean up duplicate test of label->len != 0]
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9836942b4388a07e06b4adab253b8cb381ef385
Author: Wang Hai <wanghai38@huawei.com>
Date:   Mon Aug 10 10:57:05 2020 +0800

    net: qcom/emac: add missed clk_disable_unprepare in error path of emac_clks_phase1_init
    
    [ Upstream commit 50caa777a3a24d7027748e96265728ce748b41ef ]
    
    Fix the missing clk_disable_unprepare() before return
    from emac_clks_phase1_init() in the error handling case.
    
    Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Acked-by: Timur Tabi <timur@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f77fe42f1515de78a65fb3365b987207bfb84103
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jun 26 13:39:59 2020 +0300

    drm/vmwgfx: Fix two list_for_each loop exit tests
    
    [ Upstream commit 4437c1152ce0e57ab8f401aa696ea6291cc07ab1 ]
    
    These if statements are supposed to be true if we ended the
    list_for_each_entry() loops without hitting a break statement but they
    don't work.
    
    In the first loop, we increment "i" after the "if (i == unit)" condition
    so we don't necessarily know that "i" is not equal to unit at the end of
    the loop.
    
    In the second loop we exit when mode is not pointing to a valid
    drm_display_mode struct so it doesn't make sense to check "mode->type".
    
    Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>
    Signed-off-by: Roland Scheidegger <sroland@vmware.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c8cd977d4752b43635b0e656d78745822c8c594
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jun 26 13:34:37 2020 +0300

    drm/vmwgfx: Use correct vmw_legacy_display_unit pointer
    
    [ Upstream commit 1d2c0c565bc0da25f5e899a862fb58e612b222df ]
    
    The "entry" pointer is an offset from the list head and it doesn't
    point to a valid vmw_legacy_display_unit struct.  Presumably the
    intent was to point to the last entry.
    
    Also the "i++" wasn't used so I have removed that as well.
    
    Fixes: d7e1958dbe4a ("drm/vmwgfx: Support older hardware.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>
    Signed-off-by: Roland Scheidegger <sroland@vmware.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52fd3aad73a2eee08f3ef40ae25787896ba72b52
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Aug 6 15:35:34 2020 -0700

    Input: sentelic - fix error return when fsp_reg_write fails
    
    [ Upstream commit ea38f06e0291986eb93beb6d61fd413607a30ca4 ]
    
    Currently when the call to fsp_reg_write fails -EIO is not being returned
    because the count is being returned instead of the return value in retval.
    Fix this by returning the value in retval instead of count.
    
    Addresses-Coverity: ("Unused value")
    Fixes: fc69f4a6af49 ("Input: add new driver for Sentelic Finger Sensing Pad")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20200603141218.131663-1-colin.king@canonical.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 104f1552c137aa53401d5ef9d8b83f1741fee9bf
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sun Jul 26 18:16:06 2020 +0200

    i2c: rcar: avoid race when unregistering slave
    
    [ Upstream commit c7c9e914f9a0478fba4dc6f227cfd69cf84a4063 ]
    
    Due to the lockless design of the driver, it is theoretically possible
    to access a NULL pointer, if a slave interrupt was running while we were
    unregistering the slave. To make this rock solid, disable the interrupt
    for a short time while we are clearing the interrupt_enable register.
    This patch is purely based on code inspection. The OOPS is super-hard to
    trigger because clearing SAR (the address) makes interrupts even more
    unlikely to happen as well. While here, reinit SCR to SDBS because this
    bit should always be set according to documentation. There is no effect,
    though, because the interface is disabled.
    
    Fixes: 7b814d852af6 ("i2c: rcar: avoid race when unregistering slave client")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0999f2835cd4ecb5e6374d86d57a2e041333a504
Author: Thomas Hebb <tommyhebb@gmail.com>
Date:   Sun Jul 26 21:08:14 2020 -0700

    tools build feature: Use CC and CXX from parent
    
    [ Upstream commit e3232c2f39acafd5a29128425bc30b9884642cfa ]
    
    commit c8c188679ccf ("tools build: Use the same CC for feature detection
    and actual build") changed these assignments from unconditional (:=) to
    conditional (?=) so that they wouldn't clobber values from the
    environment. However, conditional assignment does not work properly for
    variables that Make implicitly sets, among which are CC and CXX. To
    quote tools/scripts/Makefile.include, which handles this properly:
    
      # Makefiles suck: This macro sets a default value of $(2) for the
      # variable named by $(1), unless the variable has been set by
      # environment or command line. This is necessary for CC and AR
      # because make sets default values, so the simpler ?= approach
      # won't work as expected.
    
    In other words, the conditional assignments will not run even if the
    variables are not overridden in the environment; Make will set CC to
    "cc" and CXX to "g++" when it starts[1], meaning the variables are not
    empty by the time the conditional assignments are evaluated. This breaks
    cross-compilation when CROSS_COMPILE is set but CC isn't, since "cc"
    gets used for feature detection instead of the cross compiler (and
    likewise for CXX).
    
    To fix the issue, just pass down the values of CC and CXX computed by
    the parent Makefile, which gets included by the Makefile that actually
    builds whatever we're detecting features for and so is guaranteed to
    have good values. This is a better solution anyway, since it means we
    aren't trying to replicate the logic of the parent build system and so
    don't risk it getting out of sync.
    
    Leave PKG_CONFIG alone, since 1) there's no common logic to compute it
    in Makefile.include, and 2) it's not an implicit variable, so
    conditional assignment works properly.
    
    [1] https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
    
    Fixes: c8c188679ccf ("tools build: Use the same CC for feature detection and actual build")
    Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Cc: David Carrillo-Cisneros <davidcc@google.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Igor Lubashev <ilubashe@akamai.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Quentin Monnet <quentin@isovalent.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: thomas hebb <tommyhebb@gmail.com>
    Link: http://lore.kernel.org/lkml/0a6e69d1736b0fa231a648f50b0cce5d8a6734ef.1595822871.git.tommyhebb@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b215b29ca28c4b9e909662c2443e0477b0d19bd9
Author: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Date:   Fri Jul 17 21:46:06 2020 -0700

    pwm: bcm-iproc: handle clk_get_rate() return
    
    [ Upstream commit 6ced5ff0be8e94871ba846dfbddf69d21363f3d7 ]
    
    Handle clk_get_rate() returning 0 to avoid possible division by zero.
    
    Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller")
    Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
    Signed-off-by: Scott Branden <scott.branden@broadcom.com>
    Reviewed-by: Ray Jui <ray.jui@broadcom.com>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8d95b2ac42e76967e635bc1d6e0855b22369310
Author: Xu Wang <vulab@iscas.ac.cn>
Date:   Mon Jul 13 03:21:43 2020 +0000

    clk: clk-atlas6: fix return value check in atlas6_clk_init()
    
    [ Upstream commit 12b90b40854a8461a02ef19f6f4474cc88d64b66 ]
    
    In case of error, the function clk_register() returns ERR_PTR()
    and never returns NULL. The NULL test in the return value check
    should be replaced with IS_ERR().
    
    Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20200713032143.21362-1-vulab@iscas.ac.cn
    Acked-by: Barry Song <baohua@kernel.org>
    Fixes: 7bf21bc81f28 ("clk: sirf: re-arch to make the codes support both prima2 and atlas6")
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b52fc176607f1f4607bf5a23ae64334474938baa
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Mon Jun 29 17:38:07 2020 +0200

    i2c: rcar: slave: only send STOP event when we have been addressed
    
    [ Upstream commit 314139f9f0abdba61ed9a8463bbcb0bf900ac5a2 ]
    
    When the SSR interrupt is activated, it will detect every STOP condition
    on the bus, not only the ones after we have been addressed. So, enable
    this interrupt only after we have been addressed, and disable it
    otherwise.
    
    Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40f782ead6b1d0bcebff304a6a55d10d7ebcb275
Author: Liu Yi L <yi.l.liu@intel.com>
Date:   Fri Jul 24 09:49:14 2020 +0800

    iommu/vt-d: Enforce PASID devTLB field mask
    
    [ Upstream commit 5f77d6ca5ca74e4b4a5e2e010f7ff50c45dea326 ]
    
    Set proper masks to avoid invalid input spillover to reserved bits.
    
    Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
    Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20200724014925.15523-2-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b3916435f76fd092e0a14dfc968a7ed45e6e9d5
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Jul 14 20:22:11 2020 +0100

    iommu/omap: Check for failure of a call to omap_iommu_dump_ctx
    
    [ Upstream commit dee9d154f40c58d02f69acdaa5cfd1eae6ebc28b ]
    
    It is possible for the call to omap_iommu_dump_ctx to return
    a negative error number, so check for the failure and return
    the error number rather than pass the negative value to
    simple_read_from_buffer.
    
    Fixes: 14e0e6796a0d ("OMAP: iommu: add initial debugfs support")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20200714192211.744776-1-colin.king@canonical.com
    Addresses-Coverity: ("Improper use of negative value")
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0a52e5dbb0e731d4b069eacab91d737201a90f2
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Jun 19 16:42:14 2020 +0800

    dm rq: don't call blk_mq_queue_stopped() in dm_stop_queue()
    
    [ Upstream commit e766668c6cd49d741cfb49eaeb38998ba34d27bc ]
    
    dm_stop_queue() only uses blk_mq_quiesce_queue() so it doesn't
    formally stop the blk-mq queue; therefore there is no point making the
    blk_mq_queue_stopped() check -- it will never be stopped.
    
    In addition, even though dm_stop_queue() actually tries to quiesce hw
    queues via blk_mq_quiesce_queue(), checking with blk_queue_quiesced()
    to avoid unnecessary queue quiesce isn't reliable because: the
    QUEUE_FLAG_QUIESCED flag is set before synchronize_rcu() and
    dm_stop_queue() may be called when synchronize_rcu() from another
    blk_mq_quiesce_queue() is in-progress.
    
    Fixes: 7b17c2f7292ba ("dm: Fix a race condition related to stopping and starting queues")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24e014e194b66d5535163e3efc25da650a0120d8
Author: Steve Longerbeam <slongerbeam@gmail.com>
Date:   Wed Jun 17 15:40:37 2020 -0700

    gpu: ipu-v3: image-convert: Combine rotate/no-rotate irq handlers
    
    [ Upstream commit 0f6245f42ce9b7e4d20f2cda8d5f12b55a44d7d1 ]
    
    Combine the rotate_irq() and norotate_irq() handlers into a single
    eof_irq() handler.
    
    Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e4eaf895b5217e8933f0c3536bbc9e12d049e2f
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jul 8 14:49:52 2020 +0200

    USB: serial: ftdi_sio: clean up receive processing
    
    [ Upstream commit ce054039ba5e47b75a3be02a00274e52b06a6456 ]
    
    Clean up receive processing by dropping the character pointer and
    keeping the length argument unchanged throughout the function.
    
    Also make it more apparent that sysrq processing can consume a
    characters by adding an explicit continue.
    
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abb9d1a281c6249aff4a144252f3176c5b1f8bc1
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jul 8 14:49:51 2020 +0200

    USB: serial: ftdi_sio: make process-packet buffer unsigned
    
    [ Upstream commit ab4cc4ef6724ea588e835fc1e764c4b4407a70b7 ]
    
    Use an unsigned type for the process-packet buffer argument and give it
    a more apt name.
    
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 198f9960a740be4cf66a995a41f8c56260cd3a61
Author: Kamal Heib <kamalheib1@gmail.com>
Date:   Tue Jun 23 13:52:36 2020 +0300

    RDMA/ipoib: Return void from ipoib_ib_dev_stop()
    
    [ Upstream commit 95a5631f6c9f3045f26245e6045244652204dfdb ]
    
    The return value from ipoib_ib_dev_stop() is always 0 - change it to be
    void.
    
    Link: https://lore.kernel.org/r/20200623105236.18683-1-kamalheib1@gmail.com
    Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 545017c9c8c46a04236c964336a4bcea853b590c
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Mon Jun 15 14:53:21 2020 +0100

    mfd: arizona: Ensure 32k clock is put on driver unbind and error
    
    [ Upstream commit ddff6c45b21d0437ce0c85f8ac35d7b5480513d7 ]
    
    Whilst it doesn't matter if the internal 32k clock register settings
    are cleaned up on exit, as the part will be turned off losing any
    settings, hence the driver hasn't historially bothered. The external
    clock should however be cleaned up, as it could cause clocks to be
    left on, and will at best generate a warning on unbind.
    
    Add clean up on both the probe error path and unbind for the 32k
    clock.
    
    Fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks")
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81c62cae5e0a93f5e4fc618a28a22ef700a5eebd
Author: Liu Ying <victor.liu@nxp.com>
Date:   Thu Jul 9 10:28:52 2020 +0800

    drm/imx: imx-ldb: Disable both channels for split mode in enc->disable()
    
    commit 3b2a999582c467d1883716b37ffcc00178a13713 upstream.
    
    Both of the two LVDS channels should be disabled for split mode
    in the encoder's ->disable() callback, because they are enabled
    in the encoder's ->enable() callback.
    
    Fixes: 6556f7f82b9c ("drm: imx: Move imx-drm driver out of staging")
    Cc: Philipp Zabel <p.zabel@pengutronix.de>
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Liu Ying <victor.liu@nxp.com>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3513136ffe0aa1c1a8b7f04a1ad09766414cbc7
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Jul 10 18:10:53 2020 +0300

    perf intel-pt: Fix FUP packet state
    
    commit 401136bb084fd021acd9f8c51b52fe0a25e326b2 upstream.
    
    While walking code towards a FUP ip, the packet state is
    INTEL_PT_STATE_FUP or INTEL_PT_STATE_FUP_NO_TIP. That was mishandled
    resulting in the state becoming INTEL_PT_STATE_IN_SYNC prematurely.  The
    result was an occasional lost EXSTOP event.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20200710151104.15137-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8e3a27c37f887a5abc89a387f6a977722ce9cf5
Author: Anton Blanchard <anton@ozlabs.org>
Date:   Wed Jul 15 10:08:20 2020 +1000

    pseries: Fix 64 bit logical memory block panic
    
    commit 89c140bbaeee7a55ed0360a88f294ead2b95201b upstream.
    
    Booting with a 4GB LMB size causes us to panic:
    
      qemu-system-ppc64: OS terminated: OS panic:
          Memory block size not suitable: 0x0
    
    Fix pseries_memory_block_size() to handle 64 bit LMBs.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Anton Blanchard <anton@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200715000820.1255764-1-anton@ozlabs.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88679b3b529101d43d0f9c6ec69f85adb46a60be
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Thu Jun 11 21:17:45 2020 +0200

    watchdog: f71808e_wdt: clear watchdog timeout occurred flag
    
    commit 4f39d575844148fbf3081571a1f3b4ae04150958 upstream.
    
    The flag indicating a watchdog timeout having occurred normally persists
    till Power-On Reset of the Fintek Super I/O chip. The user can clear it
    by writing a `1' to the bit.
    
    The driver doesn't offer a restart method, so regular system reboot
    might not reset the Super I/O and if the watchdog isn't enabled, we
    won't touch the register containing the bit on the next boot.
    In this case all subsequent regular reboots will be wrongly flagged
    by the driver as being caused by the watchdog.
    
    Fix this by having the flag cleared after read. This is also done by
    other drivers like those for the i6300esb and mpc8xxx_wdt.
    
    Fixes: b97cb21a4634 ("watchdog: f71808e_wdt: Fix WDTMOUT_STS register read")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20200611191750.28096-5-a.fatoum@pengutronix.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7aea136711435d20656761e9b83a2cec5fe37c9b
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Thu Jun 11 21:17:44 2020 +0200

    watchdog: f71808e_wdt: remove use of wrong watchdog_info option
    
    commit 802141462d844f2e6a4d63a12260d79b7afc4c34 upstream.
    
    The flags that should be or-ed into the watchdog_info.options by drivers
    all start with WDIOF_, e.g. WDIOF_SETTIMEOUT, which indicates that the
    driver's watchdog_ops has a usable set_timeout.
    
    WDIOC_SETTIMEOUT was used instead, which expands to 0xc0045706, which
    equals:
    
       WDIOF_FANFAULT | WDIOF_EXTERN1 | WDIOF_PRETIMEOUT | WDIOF_ALARMONLY |
       WDIOF_MAGICCLOSE | 0xc0045000
    
    These were so far indicated to userspace on WDIOC_GETSUPPORT.
    As the driver has not yet been migrated to the new watchdog kernel API,
    the constant can just be dropped without substitute.
    
    Fixes: 96cb4eb019ce ("watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20200611191750.28096-4-a.fatoum@pengutronix.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e60f0961e9c706fc92017b4cace9d6ce347b0532
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Thu Jun 11 21:17:43 2020 +0200

    watchdog: f71808e_wdt: indicate WDIOF_CARDRESET support in watchdog_info.options
    
    commit e871e93fb08a619dfc015974a05768ed6880fd82 upstream.
    
    The driver supports populating bootstatus with WDIOF_CARDRESET, but so
    far userspace couldn't portably determine whether absence of this flag
    meant no watchdog reset or no driver support. Or-in the bit to fix this.
    
    Fixes: b97cb21a4634 ("watchdog: f71808e_wdt: Fix WDTMOUT_STS register read")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20200611191750.28096-3-a.fatoum@pengutronix.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9e38a3cc4b3917ae59a9446fa56bda05f1ab43d
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Aug 4 20:00:02 2020 -0400

    tracing: Use trace_sched_process_free() instead of exit() for pid tracing
    
    commit afcab636657421f7ebfa0783a91f90256bba0091 upstream.
    
    On exit, if a process is preempted after the trace_sched_process_exit()
    tracepoint but before the process is done exiting, then when it gets
    scheduled in, the function tracers will not filter it properly against the
    function tracing pid filters.
    
    That is because the function tracing pid filters hooks to the
    sched_process_exit() tracepoint to remove the exiting task's pid from the
    filter list. Because the filtering happens at the sched_switch tracepoint,
    when the exiting task schedules back in to finish up the exit, it will no
    longer be in the function pid filtering tables.
    
    This was noticeable in the notrace self tests on a preemptable kernel, as
    the tests would fail as it exits and preempted after being taken off the
    notrace filter table and on scheduling back in it would not be in the
    notrace list, and then the ending of the exit function would trace. The test
    detected this and would fail.
    
    Cc: stable@vger.kernel.org
    Cc: Namhyung Kim <namhyung@kernel.org>
    Fixes: 1e10486ffee0a ("ftrace: Add 'function-fork' trace option")
    Fixes: c37775d57830a ("tracing: Add infrastructure to allow set_event_pid to follow children"
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3bb307dc629225a9730bff0bb9b73b0cd726361
Author: Kevin Hao <haokexin@gmail.com>
Date:   Thu Jul 30 16:23:18 2020 +0800

    tracing/hwlat: Honor the tracing_cpumask
    
    commit 96b4833b6827a62c295b149213c68b559514c929 upstream.
    
    In calculation of the cpu mask for the hwlat kernel thread, the wrong
    cpu mask is used instead of the tracing_cpumask, this causes the
    tracing/tracing_cpumask useless for hwlat tracer. Fixes it.
    
    Link: https://lkml.kernel.org/r/20200730082318.42584-2-haokexin@gmail.com
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 0330f7aa8ee6 ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs")
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afd39cbaca880da82f35b726fabbc6111da20ac3
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Tue Jul 28 14:45:36 2020 +0800

    kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler
    
    commit 0cb2f1372baa60af8456388a574af6133edd7d80 upstream.
    
    We found a case of kernel panic on our server. The stack trace is as
    follows(omit some irrelevant information):
    
      BUG: kernel NULL pointer dereference, address: 0000000000000080
      RIP: 0010:kprobe_ftrace_handler+0x5e/0xe0
      RSP: 0018:ffffb512c6550998 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff8e9d16eea018 RCX: 0000000000000000
      RDX: ffffffffbe1179c0 RSI: ffffffffc0535564 RDI: ffffffffc0534ec0
      RBP: ffffffffc0534ec1 R08: ffff8e9d1bbb0f00 R09: 0000000000000004
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffff8e9d1f797060 R14: 000000000000bacc R15: ffff8e9ce13eca00
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000080 CR3: 00000008453d0005 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <IRQ>
       ftrace_ops_assist_func+0x56/0xe0
       ftrace_call+0x5/0x34
       tcpa_statistic_send+0x5/0x130 [ttcp_engine]
    
    The tcpa_statistic_send is the function being kprobed. After analysis,
    the root cause is that the fourth parameter regs of kprobe_ftrace_handler
    is NULL. Why regs is NULL? We use the crash tool to analyze the kdump.
    
      crash> dis tcpa_statistic_send -r
             <tcpa_statistic_send>: callq 0xffffffffbd8018c0 <ftrace_caller>
    
    The tcpa_statistic_send calls ftrace_caller instead of ftrace_regs_caller.
    So it is reasonable that the fourth parameter regs of kprobe_ftrace_handler
    is NULL. In theory, we should call the ftrace_regs_caller instead of the
    ftrace_caller. After in-depth analysis, we found a reproducible path.
    
      Writing a simple kernel module which starts a periodic timer. The
      timer's handler is named 'kprobe_test_timer_handler'. The module
      name is kprobe_test.ko.
    
      1) insmod kprobe_test.ko
      2) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
      3) echo 0 > /proc/sys/kernel/ftrace_enabled
      4) rmmod kprobe_test
      5) stop step 2) kprobe
      6) insmod kprobe_test.ko
      7) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
    
    We mark the kprobe as GONE but not disarm the kprobe in the step 4).
    The step 5) also do not disarm the kprobe when unregister kprobe. So
    we do not remove the ip from the filter. In this case, when the module
    loads again in the step 6), we will replace the code to ftrace_caller
    via the ftrace_module_enable(). When we register kprobe again, we will
    not replace ftrace_caller to ftrace_regs_caller because the ftrace is
    disabled in the step 3). So the step 7) will trigger kernel panic. Fix
    this problem by disarming the kprobe when the module is going away.
    
    Link: https://lkml.kernel.org/r/20200728064536.24405-1-songmuchun@bytedance.com
    
    Cc: stable@vger.kernel.org
    Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Co-developed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b5858751a051fbd7ad7dc831fadf8bbed741ccc
Author: Chengming Zhou <zhouchengming@bytedance.com>
Date:   Wed Jul 29 02:05:53 2020 +0800

    ftrace: Setup correct FTRACE_FL_REGS flags for module
    
    commit 8a224ffb3f52b0027f6b7279854c71a31c48fc97 upstream.
    
    When module loaded and enabled, we will use __ftrace_replace_code
    for module if any ftrace_ops referenced it found. But we will get
    wrong ftrace_addr for module rec in ftrace_get_addr_new, because
    rec->flags has not been setup correctly. It can cause the callback
    function of a ftrace_ops has FTRACE_OPS_FL_SAVE_REGS to be called
    with pt_regs set to NULL.
    So setup correct FTRACE_FL_REGS flags for rec when we call
    referenced_filters to find ftrace_ops references it.
    
    Link: https://lkml.kernel.org/r/20200728180554.65203-1-zhouchengming@bytedance.com
    
    Cc: stable@vger.kernel.org
    Fixes: 8c4f3c3fa9681 ("ftrace: Check module functions being traced on reload")
    Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2905e9be282a87cd398441c0f342682df2ddf7ed
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Aug 6 23:18:02 2020 -0700

    ocfs2: change slot number type s16 to u16
    
    commit 38d51b2dd171ad973afc1f5faab825ed05a2d5e9 upstream.
    
    Dan Carpenter reported the following static checker warning.
    
            fs/ocfs2/super.c:1269 ocfs2_parse_options() warn: '(-1)' 65535 can't fit into 32767 'mopt->slot'
            fs/ocfs2/suballoc.c:859 ocfs2_init_inode_steal_slot() warn: '(-1)' 65535 can't fit into 32767 'osb->s_inode_steal_slot'
            fs/ocfs2/suballoc.c:867 ocfs2_init_meta_steal_slot() warn: '(-1)' 65535 can't fit into 32767 'osb->s_meta_steal_slot'
    
    That's because OCFS2_INVALID_SLOT is (u16)-1. Slot number in ocfs2 can be
    never negative, so change s16 to u16.
    
    Fixes: 9277f8334ffc ("ocfs2: fix value of OCFS2_INVALID_SLOT")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Reviewed-by: Gang He <ghe@suse.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200627001259.19757-1-junxiao.bi@oracle.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56525e594a0a2837160f4e36decdc1b09db4ee5d
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Apr 20 16:02:21 2020 -0400

    ext2: fix missing percpu_counter_inc
    
    commit bc2fbaa4d3808aef82dd1064a8e61c16549fe956 upstream.
    
    sbi->s_freeinodes_counter is only decreased by the ext2 code, it is never
    increased. This patch fixes it.
    
    Note that sbi->s_freeinodes_counter is only used in the algorithm that
    tries to find the group for new allocations, so this bug is not easily
    visible (the only visibility is that the group finding algorithm selects
    inoptinal result).
    
    Link: https://lore.kernel.org/r/alpine.LRH.2.02.2004201538300.19436@file01.intranet.prod.int.rdu2.redhat.com
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9bff9442312af9117723e4d32c11cfbb9d93afa
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Jul 16 18:40:23 2020 +0800

    MIPS: CPU#0 is not hotpluggable
    
    commit 9cce844abf07b683cff5f0273977d5f8d0af94c7 upstream.
    
    Now CPU#0 is not hotpluggable on MIPS, so prevent to create /sys/devices
    /system/cpu/cpu0/online which confuses some user-space tools.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 737e3834e607f86f74d45dce6eb1ca6f4a711c1a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 3 11:02:10 2020 +0200

    mac80211: fix misplaced while instead of if
    
    commit 5981fe5b0529ba25d95f37d7faa434183ad618c5 upstream.
    
    This never was intended to be a 'while' loop, it should've
    just been an 'if' instead of 'while'. Fix this.
    
    I noticed this while applying another patch from Ben that
    intended to fix a busy loop at this spot.
    
    Cc: stable@vger.kernel.org
    Fixes: b16798f5b907 ("mac80211: mark station unauthorized before key removal")
    Reported-by: Ben Greear <greearb@candelatech.com>
    Link: https://lore.kernel.org/r/20200803110209.253009ae41ff.I3522aad099392b31d5cf2dcca34cbac7e5832dde@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4476c8ef04dd52a3bd6f382cd133ad725980f923
Author: Coly Li <colyli@suse.de>
Date:   Sat Jul 25 20:00:16 2020 +0800

    bcache: allocate meta data pages as compound pages
    
    commit 5fe48867856367142d91a82f2cbf7a57a24cbb70 upstream.
    
    There are some meta data of bcache are allocated by multiple pages,
    and they are used as bio bv_page for I/Os to the cache device. for
    example cache_set->uuids, cache->disk_buckets, journal_write->data,
    bset_tree->data.
    
    For such meta data memory, all the allocated pages should be treated
    as a single memory block. Then the memory management and underlying I/O
    code can treat them more clearly.
    
    This patch adds __GFP_COMP flag to all the location allocating >0 order
    pages for the above mentioned meta data. Then their pages are treated
    as compound pages now.
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9ce604687f34c133aa921c3345e60a81609fecf
Author: ChangSyun Peng <allenpeng@synology.com>
Date:   Fri Jul 31 17:50:17 2020 +0800

    md/raid5: Fix Force reconstruct-write io stuck in degraded raid5
    
    commit a1c6ae3d9f3dd6aa5981a332a6f700cf1c25edef upstream.
    
    In degraded raid5, we need to read parity to do reconstruct-write when
    data disks fail. However, we can not read parity from
    handle_stripe_dirtying() in force reconstruct-write mode.
    
    Reproducible Steps:
    
    1. Create degraded raid5
    mdadm -C /dev/md2 --assume-clean -l5 -n3 /dev/sda2 /dev/sdb2 missing
    2. Set rmw_level to 0
    echo 0 > /sys/block/md2/md/rmw_level
    3. IO to raid5
    
    Now some io may be stuck in raid5. We can use handle_stripe_fill() to read
    the parity in this situation.
    
    Cc: <stable@vger.kernel.org> # v4.4+
    Reviewed-by: Alex Wu <alexwu@synology.com>
    Reviewed-by: BingJing Chang <bingjingc@synology.com>
    Reviewed-by: Danny Shih <dannyshih@synology.com>
    Signed-off-by: ChangSyun Peng <allenpeng@synology.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e34237a26c04308c721b6ce460b0beaa7d7e0e28
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jun 9 16:11:29 2020 -0700

    net/compat: Add missing sock updates for SCM_RIGHTS
    
    commit d9539752d23283db4692384a634034f451261e29 upstream.
    
    Add missed sock updates to compat path via a new helper, which will be
    used more in coming patches. (The net/core/scm.c code is left as-is here
    to assist with -stable backports for the compat path.)
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Sargun Dhillon <sargun@sargun.me>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not set correctly")
    Fixes: d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not set correctly")
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5b5d63d537341738b8cb3e93a4bf5387dc9119e
Author: Jonathan McDowell <noodles@earth.li>
Date:   Wed Aug 12 20:37:01 2020 +0100

    net: stmmac: dwmac1000: provide multicast filter fallback
    
    commit 592d751c1e174df5ff219946908b005eb48934b3 upstream.
    
    If we don't have a hardware multicast filter available then instead of
    silently failing to listen for the requested ethernet broadcast
    addresses fall back to receiving all multicast packets, in a similar
    fashion to other drivers with no multicast filter.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan McDowell <noodles@earth.li>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 783539b347a8cb3cefaef1002f1e629e40ba2520
Author: Jonathan McDowell <noodles@earth.li>
Date:   Wed Aug 12 20:37:23 2020 +0100

    net: ethernet: stmmac: Disable hardware multicast filter
    
    commit df43dd526e6609769ae513a81443c7aa727c8ca3 upstream.
    
    The IPQ806x does not appear to have a functional multicast ethernet
    address filter. This was observed as a failure to correctly receive IPv6
    packets on a LAN to the all stations address. Checking the vendor driver
    shows that it does not attempt to enable the multicast filter and
    instead falls back to receiving all multicast packets, internally
    setting ALLMULTI.
    
    Use the new fallback support in the dwmac1000 driver to correctly
    achieve the same with the mainline IPQ806x driver. Confirmed to fix IPv6
    functionality on an RB3011 router.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan McDowell <noodles@earth.li>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 028b34d23dbc08e44b3494384a0878064f833ffa
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Aug 4 22:44:06 2020 +1000

    powerpc: Fix circular dependency between percpu.h and mmu.h
    
    commit 0c83b277ada72b585e6a3e52b067669df15bcedb upstream.
    
    Recently random.h started including percpu.h (see commit
    f227e3ec3b5c ("random32: update the net random state on interrupt and
    activity")), which broke corenet64_smp_defconfig:
    
      In file included from /linux/arch/powerpc/include/asm/paca.h:18,
                       from /linux/arch/powerpc/include/asm/percpu.h:13,
                       from /linux/include/linux/random.h:14,
                       from /linux/lib/uuid.c:14:
      /linux/arch/powerpc/include/asm/mmu.h:139:22: error: unknown type name 'next_tlbcam_idx'
        139 | DECLARE_PER_CPU(int, next_tlbcam_idx);
    
    This is due to a circular header dependency:
      asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
      includes asm/mmu.h
    
    Which means DECLARE_PER_CPU() isn't defined when mmu.h needs it.
    
    We can fix it by moving the include of paca.h below the include of
    asm-generic/percpu.h.
    
    This moves the include of paca.h out of the #ifdef __powerpc64__, but
    that is OK because paca.h is almost entirely inside #ifdef
    CONFIG_PPC64 anyway.
    
    It also moves the include of paca.h out of the #ifdef CONFIG_SMP,
    which could possibly break something, but seems to have no ill
    effects.
    
    Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
    Cc: stable@vger.kernel.org # v5.8
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200804130558.292328-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffcb9544744baa43c07b86ae0f370968f4a46eeb
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Fri Jul 31 12:37:32 2020 -0700

    xtensa: fix xtensa_pmu_setup prototype
    
    commit 6d65d3769d1910379e1cfa61ebf387efc6bfb22c upstream.
    
    Fix the following build error in configurations with
    CONFIG_XTENSA_VARIANT_HAVE_PERF_EVENTS=y:
    
      arch/xtensa/kernel/perf_event.c:420:29: error: passing argument 3 of
      ‘cpuhp_setup_state’ from incompatible pointer type
    
    Cc: stable@vger.kernel.org
    Fixes: 25a77b55e74c ("xtensa/perf: Convert the hotplug notifier to state machine callbacks")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ebdb47527b01fc083dafead2068385f18a3942d
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Mon Jul 6 14:02:57 2020 +0300

    iio: dac: ad5592r: fix unbalanced mutex unlocks in ad5592r_read_raw()
    
    commit 65afb0932a81c1de719ceee0db0b276094b10ac8 upstream.
    
    There are 2 exit paths where the lock isn't held, but try to unlock the
    mutex when exiting. In these places we should just return from the
    function.
    
    A neater approach would be to cleanup the ad5592r_read_raw(), but that
    would make this patch more difficult to backport to stable versions.
    
    Fixes 56ca9db862bf3: ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
    Reported-by: Charles Stanhope <charles.stanhope@gmail.com>
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9a6664b7d26a1266a3c851bba339af267c2e1ba
Author: Christian Eggers <ceggers@arri.de>
Date:   Mon Jul 27 12:16:05 2020 +0200

    dt-bindings: iio: io-channel-mux: Fix compatible string in example code
    
    commit add48ba425192c6e04ce70549129cacd01e2a09e upstream.
    
    The correct compatible string is "gpio-mux" (see
    bindings/mux/gpio-mux.txt).
    
    Cc: stable@vger.kernel.org # v4.13+
    Reviewed-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Christian Eggers <ceggers@arri.de>
    Link: https://lore.kernel.org/r/20200727101605.24384-1-ceggers@arri.de
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 547cc243f66b9fae46530f67f7bc7c6c5b022747
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Jul 29 10:17:50 2020 +0100

    btrfs: fix memory leaks after failure to lookup checksums during inode logging
    
    commit 4f26433e9b3eb7a55ed70d8f882ae9cd48ba448b upstream.
    
    While logging an inode, at copy_items(), if we fail to lookup the checksums
    for an extent we release the destination path, free the ins_data array and
    then return immediately. However a previous iteration of the for loop may
    have added checksums to the ordered_sums list, in which case we leak the
    memory used by them.
    
    So fix this by making sure we iterate the ordered_sums list and free all
    its checksums before returning.
    
    Fixes: 3650860b90cc2a ("Btrfs: remove almost all of the BUG()'s from tree-log.c")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10742034076daea73acc17779e8f234060e03489
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Jul 27 10:28:05 2020 -0400

    btrfs: only search for left_info if there is no right_info in try_merge_free_space
    
    commit bf53d4687b8f3f6b752f091eb85f62369a515dfd upstream.
    
    In try_to_merge_free_space we attempt to find entries to the left and
    right of the entry we are adding to see if they can be merged.  We
    search for an entry past our current info (saved into right_info), and
    then if right_info exists and it has a rb_prev() we save the rb_prev()
    into left_info.
    
    However there's a slight problem in the case that we have a right_info,
    but no entry previous to that entry.  At that point we will search for
    an entry just before the info we're attempting to insert.  This will
    simply find right_info again, and assign it to left_info, making them
    both the same pointer.
    
    Now if right_info _can_ be merged with the range we're inserting, we'll
    add it to the info and free right_info.  However further down we'll
    access left_info, which was right_info, and thus get a use-after-free.
    
    Fix this by only searching for the left entry if we don't find a right
    entry at all.
    
    The CVE referenced had a specially crafted file system that could
    trigger this use-after-free. However with the tree checker improvements
    we no longer trigger the conditions for the UAF.  But the original
    conditions still apply, hence this fix.
    
    Reference: CVE-2019-19448
    Fixes: 963030817060 ("Btrfs: use hybrid extents+bitmap rb tree for free space")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aac009ffa0758952be9631f7427d5d7b2f55026a
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jun 16 10:17:34 2020 +0800

    btrfs: don't allocate anonymous block device for user invisible roots
    
    commit 851fd730a743e072badaf67caf39883e32439431 upstream.
    
    [BUG]
    When a lot of subvolumes are created, there is a user report about
    transaction aborted:
    
      BTRFS: Transaction aborted (error -24)
      WARNING: CPU: 17 PID: 17041 at fs/btrfs/transaction.c:1576 create_pending_snapshot+0xbc4/0xd10 [btrfs]
      RIP: 0010:create_pending_snapshot+0xbc4/0xd10 [btrfs]
      Call Trace:
       create_pending_snapshots+0x82/0xa0 [btrfs]
       btrfs_commit_transaction+0x275/0x8c0 [btrfs]
       btrfs_mksubvol+0x4b9/0x500 [btrfs]
       btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs]
       btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs]
       btrfs_ioctl+0x11a4/0x2da0 [btrfs]
       do_vfs_ioctl+0xa9/0x640
       ksys_ioctl+0x67/0x90
       __x64_sys_ioctl+0x1a/0x20
       do_syscall_64+0x5a/0x110
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      ---[ end trace 33f2f83f3d5250e9 ]---
      BTRFS: error (device sda1) in create_pending_snapshot:1576: errno=-24 unknown
      BTRFS info (device sda1): forced readonly
      BTRFS warning (device sda1): Skipping commit of aborted transaction.
      BTRFS: error (device sda1) in cleanup_transaction:1831: errno=-24 unknown
    
    [CAUSE]
    The error is EMFILE (Too many files open) and comes from the anonymous
    block device allocation. The ids are in a shared pool of size 1<<20.
    
    The ids are assigned to live subvolumes, ie. the root structure exists
    in memory (eg. after creation or after the root appears in some path).
    The pool could be exhausted if the numbers are not reclaimed fast
    enough, after subvolume deletion or if other system component uses the
    anon block devices.
    
    [WORKAROUND]
    Since it's not possible to completely solve the problem, we can only
    minimize the time the id is allocated to a subvolume root.
    
    Firstly, we can reduce the use of anon_dev by trees that are not
    subvolume roots, like data reloc tree.
    
    This patch will do extra check on root objectid, to skip roots that
    don't need anon_dev.  Currently it's only data reloc tree and orphan
    roots.
    
    Reported-by: Greed Rong <greedrong@gmail.com>
    Link: https://lore.kernel.org/linux-btrfs/CA+UqX+NTrZ6boGnWHhSeZmEY5J76CTqmYjO2S+=tHJX7nb9DPw@mail.gmail.com/
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ceeb1defbd59ef1585f32bb95d0498c7beeebd9b
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Jun 26 19:42:34 2020 +0200

    PCI: hotplug: ACPI: Fix context refcounting in acpiphp_grab_context()
    
    commit dae68d7fd4930315389117e9da35b763f12238f9 upstream.
    
    If context is not NULL in acpiphp_grab_context(), but the
    is_going_away flag is set for the device's parent, the reference
    counter of the context needs to be decremented before returning
    NULL or the context will never be freed, so make that happen.
    
    Fixes: edf5bf34d408 ("ACPI / dock: Use callback pointers from devices' ACPI hotplug contexts")
    Reported-by: Vasily Averin <vvs@virtuozzo.com>
    Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 233f70bdb12800fce6b153c270ec987acbaa773b
Author: Steve French <stfrench@microsoft.com>
Date:   Thu Jul 16 00:34:21 2020 -0500

    smb3: warn on confusing error scenario with sec=krb5
    
    commit 0a018944eee913962bce8ffebbb121960d5125d9 upstream.
    
    When mounting with Kerberos, users have been confused about the
    default error returned in scenarios in which either keyutils is
    not installed or the user did not properly acquire a krb5 ticket.
    Log a warning message in the case that "ENOKEY" is returned
    from the get_spnego_key upcall so that users can better understand
    why mount failed in those two cases.
    
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4d2f15c8dd70bc9d007dd08379ac93617a94a6e
Author: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Date:   Tue Aug 11 20:33:24 2020 +0200

    net: initialize fastreuse on inet_inherit_port
    
    commit d76f3351cea2d927fdf70dd7c06898235035e84e upstream.
    
    In the case of TPROXY, bind_conflict optimizations for SO_REUSEADDR or
    SO_REUSEPORT are broken, possibly resulting in O(n) instead of O(1) bind
    behaviour or in the incorrect reuse of a bind.
    
    the kernel keeps track for each bind_bucket if all sockets in the
    bind_bucket support SO_REUSEADDR or SO_REUSEPORT in two fastreuse flags.
    These flags allow skipping the costly bind_conflict check when possible
    (meaning when all sockets have the proper SO_REUSE option).
    
    For every socket added to a bind_bucket, these flags need to be updated.
    As soon as a socket that does not support reuse is added, the flag is
    set to false and will never go back to true, unless the bind_bucket is
    deleted.
    
    Note that there is no mechanism to re-evaluate these flags when a socket
    is removed (this might make sense when removing a socket that would not
    allow reuse; this leaves room for a future patch).
    
    For this optimization to work, it is mandatory that these flags are
    properly initialized and updated.
    
    When a child socket is created from a listen socket in
    __inet_inherit_port, the TPROXY case could create a new bind bucket
    without properly initializing these flags, thus preventing the
    optimization to work. Alternatively, a socket not allowing reuse could
    be added to an existing bind bucket without updating the flags, causing
    bind_conflict to never be called as it should.
    
    Call inet_csk_update_fastreuse when __inet_inherit_port decides to create
    a new bind_bucket or use a different bind_bucket than the one of the
    listen socket.
    
    Fixes: 093d282321da ("tproxy: fix hash locking issue when using port redirection in __inet_inherit_port()")
    Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc3f473342464ac741471ba1486467614e92d464
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Mon Jul 27 11:13:40 2020 +0200

    xen/balloon: make the balloon wait interruptible
    
    commit 88a479ff6ef8af7f07e11593d58befc644244ff7 upstream.
    
    So it can be killed, or else processes can get hung indefinitely
    waiting for balloon pages.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200727091342.52325-3-roger.pau@citrix.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6235d910a5b85ec92cd3da929cb57971fb530f88
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Mon Jul 27 11:13:39 2020 +0200

    xen/balloon: fix accounting in alloc_xenballooned_pages error path
    
    commit 1951fa33ec259abdf3497bfee7b63e7ddbb1a394 upstream.
    
    target_unpopulated is incremented with nr_pages at the start of the
    function, but the call to free_xenballooned_pages will only subtract
    pgno number of pages, and thus the rest need to be subtracted before
    returning or else accounting will be skewed.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200727091342.52325-2-roger.pau@citrix.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0673b5b73c6ed8c2a6e08770d0b3d6ec0078cbf3
Author: Jon Derrick <jonathan.derrick@intel.com>
Date:   Tue Jul 21 14:26:09 2020 -0600

    irqdomain/treewide: Free firmware node after domain removal
    
    commit ec0160891e387f4771f953b888b1fe951398e5d9 upstream.
    
    Commit 711419e504eb ("irqdomain: Add the missing assignment of
    domain->fwnode for named fwnode") unintentionally caused a dangling pointer
    page fault issue on firmware nodes that were freed after IRQ domain
    allocation. Commit e3beca48a45b fixed that dangling pointer issue by only
    freeing the firmware node after an IRQ domain allocation failure. That fix
    no longer frees the firmware node immediately, but leaves the firmware node
    allocated after the domain is removed.
    
    The firmware node must be kept around through irq_domain_remove, but should be
    freed it afterwards.
    
    Add the missing free operations after domain removal where where appropriate.
    
    Fixes: e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated")
    Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>   # drivers/pci
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1595363169-7157-1-git-send-email-jonathan.derrick@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86a92de7833342f34e1cb98429ac100797605f73
Author: Nathan Huckleberry <nhuck@google.com>
Date:   Fri Jul 10 20:23:37 2020 +0100

    ARM: 8992/1: Fix unwind_frame for clang-built kernels
    
    commit b4d5ec9b39f8b31d98f65bc5577b5d15d93795d7 upstream.
    
    Since clang does not push pc and sp in function prologues, the current
    implementation of unwind_frame does not work. By using the previous
    frame's lr/fp instead of saved pc/sp we get valid unwinds on clang-built
    kernels.
    
    The bounds check on next frame pointer must be changed as well since
    there are 8 less bytes between frames.
    
    This fixes /proc/<pid>/stack.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/912
    
    Reported-by: Miles Chen <miles.chen@mediatek.com>
    Tested-by: Miles Chen <miles.chen@mediatek.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Huckleberry <nhuck@google.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1dd9a06bcc8e724ee8e5acbc83b29f05f598211
Author: Sven Schnelle <svens@stackframe.org>
Date:   Tue Aug 11 18:19:19 2020 +0200

    parisc: mask out enable and reserved bits from sba imask
    
    commit 5b24993c21cbf2de11aff077a48c5cb0505a0450 upstream.
    
    When using kexec the SBA IOMMU IBASE might still have the RE
    bit set. This triggers a WARN_ON when trying to write back the
    IBASE register later, and it also makes some mask calculations fail.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ca974e9e527afb1e9941f5f13c0cecac8d2b7b6
Author: John David Anglin <dave.anglin@bell.net>
Date:   Thu Jul 30 08:59:12 2020 -0400

    parisc: Implement __smp_store_release and __smp_load_acquire barriers
    
    commit e96ebd589debd9a6a793608c4ec7019c38785dea upstream.
    
    This patch implements the __smp_store_release and __smp_load_acquire barriers
    using ordered stores and loads.  This avoids the sync instruction present in
    the generic implementation.
    
    Cc: <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Dave Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 337be2b46991cf3d5afe3dbb114440946b84fe42
Author: Sivaprakash Murugesan <sivaprak@codeaurora.org>
Date:   Fri Jun 12 13:28:15 2020 +0530

    mtd: rawnand: qcom: avoid write to unavailable register
    
    commit 443440cc4a901af462239d286cd10721aa1c7dfc upstream.
    
    SFLASHC_BURST_CFG is only available on older ipq NAND platforms, this
    register has been removed when the NAND controller got implemented in
    the qpic controller.
    
    Avoid writing this register on devices which are based on qpic NAND
    controller.
    
    Fixes: dce84760b09f ("mtd: nand: qcom: Support for IPQ8074 QPIC NAND controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/1591948696-16015-2-git-send-email-sivaprak@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fd8f313a9fdeb06986bd2bb8caa7c87602b9729
Author: Christian Eggers <ceggers@arri.de>
Date:   Tue Jul 28 12:08:32 2020 +0200

    spi: spidev: Align buffers for DMA
    
    commit aa9e862d7d5bcecd4dca9f39e8b684b93dd84ee7 upstream.
    
    Simply copying all xfers from userspace into one bounce buffer causes
    alignment problems if the SPI controller uses DMA.
    
    Ensure that all transfer data blocks within the rx and tx bounce buffers
    are aligned for DMA (according to ARCH_KMALLOC_MINALIGN).
    
    Alignment may increase the usage of the bounce buffers. In some cases,
    the buffers may need to be increased using the "bufsiz" module
    parameter.
    
    Signed-off-by: Christian Eggers <ceggers@arri.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200728100832.24788-1-ceggers@arri.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f337f8a302f715ba280477ecf2cdaeae0d86b45e
Author: Zheng Bin <zhengbin13@huawei.com>
Date:   Mon Jun 15 09:21:53 2020 +0800

    9p: Fix memory leak in v9fs_mount
    
    commit cb0aae0e31c632c407a2cab4307be85a001d4d98 upstream.
    
    v9fs_mount
      v9fs_session_init
        v9fs_cache_session_get_cookie
          v9fs_random_cachetag                     -->alloc cachetag
          v9ses->fscache = fscache_acquire_cookie  -->maybe NULL
      sb = sget                                    -->fail, goto clunk
    clunk_fid:
      v9fs_session_close
        if (v9ses->fscache)                        -->NULL
          kfree(v9ses->cachetag)
    
    Thus memleak happens.
    
    Link: http://lkml.kernel.org/r/20200615012153.89538-1-zhengbin13@huawei.com
    Fixes: 60e78d2c993e ("9p: Add fscache support to 9p")
    Cc: <stable@vger.kernel.org> # v2.6.32+
    Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff114bcd7635211d051c6031fac800fd45424ece
Author: Hector Martin <marcan@marcan.st>
Date:   Mon Aug 10 17:24:00 2020 +0900

    ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109
    
    commit 1b7ecc241a67ad6b584e071bd791a54e0cd5f097 upstream.
    
    Further investigation of the L-R swap problem on the MS2109 reveals that
    the problem isn't that the channels are swapped, but rather that they
    are swapped and also out of phase by one sample. In other words, the
    issue is actually that the very first frame that comes from the hardware
    is a half-frame containing only the right channel, and after that
    everything becomes offset.
    
    So introduce a new quirk field to drop the very first 2 bytes that come
    in after the format is configured and a capture stream starts. This puts
    the channels in phase and in the correct order.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Link: https://lore.kernel.org/r/20200810082400.225858-1-marcan@marcan.st
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0900097ef667097b0a4afb0155a4f5add77ece19
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Aug 11 18:35:30 2020 -0700

    fs/minix: reject too-large maximum file size
    
    commit 270ef41094e9fa95273f288d7d785313ceab2ff3 upstream.
    
    If the minix filesystem tries to map a very large logical block number to
    its on-disk location, block_to_path() can return offsets that are too
    large, causing out-of-bounds memory accesses when accessing indirect index
    blocks.  This should be prevented by the check against the maximum file
    size, but this doesn't work because the maximum file size is read directly
    from the on-disk superblock and isn't validated itself.
    
    Fix this by validating the maximum file size at mount time.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+c7d9ec7a1a7272dd71b3@syzkaller.appspotmail.com
    Reported-by: syzbot+3b7b03a0c28948054fb5@syzkaller.appspotmail.com
    Reported-by: syzbot+6e056ee473568865f3e6@syzkaller.appspotmail.com
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Qiujun Huang <anenbupt@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200628060846.682158-4-ebiggers@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12490f06ef084bc34f5e5dbda104aa034e376f2e
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Aug 11 18:35:27 2020 -0700

    fs/minix: don't allow getting deleted inodes
    
    commit facb03dddec04e4aac1bb2139accdceb04deb1f3 upstream.
    
    If an inode has no links, we need to mark it bad rather than allowing it
    to be accessed.  This avoids WARNINGs in inc_nlink() and drop_nlink() when
    doing directory operations on a fuzzed filesystem.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+a9ac3de1b5de5fb10efc@syzkaller.appspotmail.com
    Reported-by: syzbot+df958cf5688a96ad3287@syzkaller.appspotmail.com
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Qiujun Huang <anenbupt@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200628060846.682158-3-ebiggers@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c775629a5ffe3f6305f9a4f53d8167f629435ad
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Aug 11 18:35:24 2020 -0700

    fs/minix: check return value of sb_getblk()
    
    commit da27e0a0e5f655f0d58d4e153c3182bb2b290f64 upstream.
    
    Patch series "fs/minix: fix syzbot bugs and set s_maxbytes".
    
    This series fixes all syzbot bugs in the minix filesystem:
    
            KASAN: null-ptr-deref Write in get_block
            KASAN: use-after-free Write in get_block
            KASAN: use-after-free Read in get_block
            WARNING in inc_nlink
            KMSAN: uninit-value in get_block
            WARNING in drop_nlink
    
    It also fixes the minix filesystem to set s_maxbytes correctly, so that
    userspace sees the correct behavior when exceeding the max file size.
    
    This patch (of 6):
    
    sb_getblk() can fail, so check its return value.
    
    This fixes a NULL pointer dereference.
    
    Originally from Qiujun Huang.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+4a88b2b9dc280f47baf4@syzkaller.appspotmail.com
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Qiujun Huang <anenbupt@gmail.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200628060846.682158-1-ebiggers@kernel.org
    Link: http://lkml.kernel.org/r/20200628060846.682158-2-ebiggers@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4840e848efa4648a551e3d833bfe7cebde344d2
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Aug 10 11:21:11 2020 -0700

    bitfield.h: don't compile-time validate _val in FIELD_FIT
    
    commit 444da3f52407d74c9aa12187ac6b01f76ee47d62 upstream.
    
    When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
    compiler to deduce a case where _val can only have the value of -1 at
    compile time. Specifically,
    
    /* struct bpf_insn: _s32 imm */
    u64 imm = insn->imm; /* sign extend */
    if (imm >> 32) { /* non-zero only if insn->imm is negative */
      /* inlined from ur_load_imm_any */
      u32 __imm = imm >> 32; /* therefore, always 0xffffffff */
      if (__builtin_constant_p(__imm) && __imm > 255)
        compiletime_assert_XXX()
    
    This can result in tripping a BUILD_BUG_ON() in __BF_FIELD_CHECK() that
    checks that a given value is representable in one byte (interpreted as
    unsigned).
    
    FIELD_FIT() should return true or false at runtime for whether a value
    can fit for not. Don't break the build over a value that's too large for
    the mask. We'd prefer to keep the inlining and compiler optimizations
    though we know this case will always return false.
    
    Cc: stable@vger.kernel.org
    Fixes: 1697599ee301a ("bitfield.h: add FIELD_FIT() helper")
    Link: https://lore.kernel.org/kernel-hardening/CAK7LNASvb0UDJ0U5wkYYRzTAdnEs64HjXpEUL7d=V0CXiAXcNw@mail.gmail.com/
    Reported-by: Masahiro Yamada <masahiroy@kernel.org>
    Debugged-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2c4136587cf19066758091eb60694a8f5120897
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jun 17 09:48:56 2020 -0400

    crypto: cpt - don't sleep of CRYPTO_TFM_REQ_MAY_SLEEP was not specified
    
    commit 9e27c99104707f083dccd3b4d79762859b5a0614 upstream.
    
    There is this call chain:
    cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc
    where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
    was not specified.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org      # v4.11+
    Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99e69b921dae3ebe63d2c424ce00f91b4cab2826
Author: John Allen <john.allen@amd.com>
Date:   Mon Jun 22 15:24:02 2020 -0500

    crypto: ccp - Fix use of merged scatterlists
    
    commit 8a302808c60d441d9884cb00ea7f2b534f2e3ca5 upstream.
    
    Running the crypto manager self tests with
    CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
    when using the ccp-crypto driver:
    
    alg: skcipher: cbc-des3-ccp encryption failed on test vector 0; expected_error=0, actual_error=-5 ...
    
    alg: skcipher: ctr-aes-ccp decryption overran dst buffer on test vector 0 ...
    
    alg: ahash: sha224-ccp test failed (wrong result) on test vector ...
    
    These errors are the result of improper processing of scatterlists mapped
    for DMA.
    
    Given a scatterlist in which entries are merged as part of mapping the
    scatterlist for DMA, the DMA length of a merged entry will reflect the
    combined length of the entries that were merged. The subsequent
    scatterlist entry will contain DMA information for the scatterlist entry
    after the last merged entry, but the non-DMA information will be that of
    the first merged entry.
    
    The ccp driver does not take this scatterlist merging into account. To
    address this, add a second scatterlist pointer to track the current
    position in the DMA mapped representation of the scatterlist. Both the DMA
    representation and the original representation of the scatterlist must be
    tracked as while most of the driver can use just the DMA representation,
    scatterlist_map_and_copy() must use the original representation and
    expects the scatterlist pointer to be accurate to the original
    representation.
    
    In order to properly walk the original scatterlist, the scatterlist must
    be walked until the combined lengths of the entries seen is equal to the
    DMA length of the current entry being processed in the DMA mapped
    representation.
    
    Fixes: 63b945091a070 ("crypto: ccp - CCP device driver and interface support")
    Signed-off-by: John Allen <john.allen@amd.com>
    Cc: stable@vger.kernel.org
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 454b00bb81679c95f763d3ecdb706d985d053f7a
Author: Tom Rix <trix@redhat.com>
Date:   Mon Jul 13 07:06:34 2020 -0700

    crypto: qat - fix double free in qat_uclo_create_batch_init_list
    
    commit c06c76602e03bde24ee69a2022a829127e504202 upstream.
    
    clang static analysis flags this error
    
    qat_uclo.c:297:3: warning: Attempt to free released memory
      [unix.Malloc]
                    kfree(*init_tab_base);
                    ^~~~~~~~~~~~~~~~~~~~~
    
    When input *init_tab_base is null, the function allocates memory for
    the head of the list.  When there is problem allocating other list
    elements the list is unwound and freed.  Then a check is made if the
    list head was allocated and is also freed.
    
    Keeping track of the what may need to be freed is the variable 'tail_old'.
    The unwinding/freeing block is
    
            while (tail_old) {
                    mem_init = tail_old->next;
                    kfree(tail_old);
                    tail_old = mem_init;
            }
    
    The problem is that the first element of tail_old is also what was
    allocated for the list head
    
                    init_header = kzalloc(sizeof(*init_header), GFP_KERNEL);
                    ...
                    *init_tab_base = init_header;
                    flag = 1;
            }
            tail_old = init_header;
    
    So *init_tab_base/init_header are freed twice.
    
    There is another problem.
    When the input *init_tab_base is non null the tail_old is calculated by
    traveling down the list to first non null entry.
    
            tail_old = init_header;
            while (tail_old->next)
                    tail_old = tail_old->next;
    
    When the unwinding free happens, the last entry of the input list will
    be freed.
    
    So the freeing needs a general changed.
    If locally allocated the first element of tail_old is freed, else it
    is skipped.  As a bit of cleanup, reset *init_tab_base if it came in
    as null.
    
    Fixes: b4b7e67c917f ("crypto: qat - Intel(R) QAT ucode part of fw loader")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17b84284d2a2b49f5fe625d063cd0a0ac58e10e1
Author: Hector Martin <marcan@marcan.st>
Date:   Mon Aug 10 17:25:02 2020 +0900

    ALSA: usb-audio: add quirk for Pioneer DDJ-RB
    
    commit 6e8596172ee1cd46ec0bfd5adcf4ff86371478b6 upstream.
    
    This is just another Pioneer device with fixed endpoints. Input is dummy
    but used as feedback (it always returns silence).
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Link: https://lore.kernel.org/r/20200810082502.225979-1-marcan@marcan.st
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fa2227bb563179772163d02697703493e2e1606
Author: Hector Martin <marcan@marcan.st>
Date:   Mon Aug 10 13:53:19 2020 +0900

    ALSA: usb-audio: fix overeager device match for MacroSilicon MS2109
    
    commit 14a720dc1f5332f3bdf30a23a3bc549e81be974c upstream.
    
    Matching by device matches all interfaces, which breaks the video/HID
    portions of the device depending on module load order.
    
    Fixes: e337bf19f6af ("ALSA: usb-audio: add quirk for MacroSilicon MS2109")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Link: https://lore.kernel.org/r/20200810045319.128745-1-marcan@marcan.st
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b10bafd333b75f9f85f99d2d96f5e33c50664679
Author: Mirko Dietrich <buzz@l4m1.de>
Date:   Thu Aug 6 14:48:50 2020 +0200

    ALSA: usb-audio: Creative USB X-Fi Pro SB1095 volume knob support
    
    commit fec9008828cde0076aae595ac031bfcf49d335a4 upstream.
    
    Adds an entry for Creative USB X-Fi to the rc_config array in
    mixer_quirks.c to allow use of volume knob on the device.
    Adds support for newer X-Fi Pro card, known as "Model No. SB1095"
    with USB ID "041e:3263"
    
    Signed-off-by: Mirko Dietrich <buzz@l4m1.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200806124850.20334-1-buzz@l4m1.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11a800116d76d3466739c9de6d1056d248f6dc05
Author: Brant Merryman <brant.merryman@silabs.com>
Date:   Fri Jun 26 04:22:58 2020 +0000

    USB: serial: cp210x: enable usb generic throttle/unthrottle
    
    commit 4387b3dbb079d482d3c2b43a703ceed4dd27ed28 upstream.
    
    Assign the .throttle and .unthrottle functions to be generic function
    in the driver structure to prevent data loss that can otherwise occur
    if the host does not enable USB throttling.
    
    Signed-off-by: Brant Merryman <brant.merryman@silabs.com>
    Co-developed-by: Phu Luu <phu.luu@silabs.com>
    Signed-off-by: Phu Luu <phu.luu@silabs.com>
    Link: https://lore.kernel.org/r/57401AF3-9961-461F-95E1-F8AFC2105F5E@silabs.com
    [ johan: fix up tags ]
    Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control")
    Cc: stable <stable@vger.kernel.org>     # 2.6.12
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b00b89e16ecf186153a5c62b15a940b991a6a3ef
Author: Brant Merryman <brant.merryman@silabs.com>
Date:   Fri Jun 26 04:24:20 2020 +0000

    USB: serial: cp210x: re-enable auto-RTS on open
    
    commit c7614ff9b73a1e6fb2b1b51396da132ed22fecdb upstream.
    
    CP210x hardware disables auto-RTS but leaves auto-CTS when in hardware
    flow control mode and UART on cp210x hardware is disabled. When
    re-opening the port, if auto-CTS is enabled on the cp210x, then auto-RTS
    must be re-enabled in the driver.
    
    Signed-off-by: Brant Merryman <brant.merryman@silabs.com>
    Co-developed-by: Phu Luu <phu.luu@silabs.com>
    Signed-off-by: Phu Luu <phu.luu@silabs.com>
    Link: https://lore.kernel.org/r/ECCF8E73-91F3-4080-BE17-1714BC8818FB@silabs.com
    [ johan: fix up tags and problem description ]
    Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control")
    Cc: stable <stable@vger.kernel.org>     # 2.6.12
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb70a1cbe5e470cf740f33091190b144c8a99461
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Thu Aug 6 19:53:16 2020 +0800

    net: Set fput_needed iff FDPUT_FPUT is set
    
    [ Upstream commit ce787a5a074a86f76f5d3fd804fa78e01bfb9e89 ]
    
    We should fput() file iff FDPUT_FPUT is set. So we should set fput_needed
    accordingly.
    
    Fixes: 00e188ef6a7e ("sockfd_lookup_light(): switch to fdget^W^Waway from fget_light")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6de6d1ca5f3e8383cb175777f0e9aba7a3c397f5
Author: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Date:   Tue Aug 11 20:33:23 2020 +0200

    net: refactor bind_bucket fastreuse into helper
    
    [ Upstream commit 62ffc589abb176821662efc4525ee4ac0b9c3894 ]
    
    Refactor the fastreuse update code in inet_csk_get_port into a small
    helper function that can be called from other places.
    
    Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 980415fffec6952602edac586eb8c3a7d3f50b43
Author: Qingyu Li <ieatmuttonchuan@gmail.com>
Date:   Mon Aug 10 09:51:00 2020 +0800

    net/nfc/rawsock.c: add CAP_NET_RAW check.
    
    [ Upstream commit 26896f01467a28651f7a536143fe5ac8449d4041 ]
    
    When creating a raw AF_NFC socket, CAP_NET_RAW needs to be checked first.
    
    Signed-off-by: Qingyu Li <ieatmuttonchuan@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit beafe1d05798982ae21db383884611bb389a1639
Author: Xie He <xie.he.0141@gmail.com>
Date:   Wed Aug 5 18:50:40 2020 -0700

    drivers/net/wan/lapbether: Added needed_headroom and a skb->len check
    
    [ Upstream commit c7ca03c216acb14466a713fedf1b9f2c24994ef2 ]
    
    1. Added a skb->len check
    
    This driver expects upper layers to include a pseudo header of 1 byte
    when passing down a skb for transmission. This driver will read this
    1-byte header. This patch added a skb->len check before reading the
    header to make sure the header exists.
    
    2. Changed to use needed_headroom instead of hard_header_len to request
    necessary headroom to be allocated
    
    In net/packet/af_packet.c, the function packet_snd first reserves a
    headroom of length (dev->hard_header_len + dev->needed_headroom).
    Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
    which calls dev->header_ops->create, to create the link layer header.
    If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of
    length (dev->hard_header_len), and assumes the user to provide the
    appropriate link layer header.
    
    So according to the logic of af_packet.c, dev->hard_header_len should
    be the length of the header that would be created by
    dev->header_ops->create.
    
    However, this driver doesn't provide dev->header_ops, so logically
    dev->hard_header_len should be 0.
    
    So we should use dev->needed_headroom instead of dev->hard_header_len
    to request necessary headroom to be allocated.
    
    This change fixes kernel panic when this driver is used with AF_PACKET
    SOCK_RAW sockets.
    
    Call stack when panic:
    
    [  168.399197] skbuff: skb_under_panic: text:ffffffff819d95fb len:20
    put:14 head:ffff8882704c0a00 data:ffff8882704c09fd tail:0x11 end:0xc0
    dev:veth0
    ...
    [  168.399255] Call Trace:
    [  168.399259]  skb_push.cold+0x14/0x24
    [  168.399262]  eth_header+0x2b/0xc0
    [  168.399267]  lapbeth_data_transmit+0x9a/0xb0 [lapbether]
    [  168.399275]  lapb_data_transmit+0x22/0x2c [lapb]
    [  168.399277]  lapb_transmit_buffer+0x71/0xb0 [lapb]
    [  168.399279]  lapb_kick+0xe3/0x1c0 [lapb]
    [  168.399281]  lapb_data_request+0x76/0xc0 [lapb]
    [  168.399283]  lapbeth_xmit+0x56/0x90 [lapbether]
    [  168.399286]  dev_hard_start_xmit+0x91/0x1f0
    [  168.399289]  ? irq_init_percpu_irqstack+0xc0/0x100
    [  168.399291]  __dev_queue_xmit+0x721/0x8e0
    [  168.399295]  ? packet_parse_headers.isra.0+0xd2/0x110
    [  168.399297]  dev_queue_xmit+0x10/0x20
    [  168.399298]  packet_sendmsg+0xbf0/0x19b0
    ......
    
    Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
    Cc: Martin Schiller <ms@dev.tdt.de>
    Cc: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Xie He <xie.he.0141@gmail.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1b1a3d2dff2ac034682eb8610eec83e0efd33b0
Author: John Ogness <john.ogness@linutronix.de>
Date:   Thu Aug 13 21:45:25 2020 +0206

    af_packet: TPACKET_V3: fix fill status rwlock imbalance
    
    [ Upstream commit 88fd1cb80daa20af063bce81e1fad14e945a8dc4 ]
    
    After @blk_fill_in_prog_lock is acquired there is an early out vnet
    situation that can occur. In that case, the rwlock needs to be
    released.
    
    Also, since @blk_fill_in_prog_lock is only acquired when @tp_version
    is exactly TPACKET_V3, only release it on that exact condition as
    well.
    
    And finally, add sparse annotation so that it is clearer that
    prb_fill_curr_block() and prb_clear_blk_fill_status() are acquiring
    and releasing @blk_fill_in_prog_lock, respectively. sparse is still
    unable to understand the balance, but the warnings are now on a
    higher level that make more sense.
    
    Fixes: 632ca50f2cbd ("af_packet: TPACKET_V3: replace busy-wait loop")
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffe484d867918a019b55a16b7e1821d2504b89d8
Author: Jian Cai <caij2003@gmail.com>
Date:   Mon Jun 22 16:24:33 2020 -0700

    crypto: aesni - add compatibility with IAS
    
    [ Upstream commit 44069737ac9625a0f02f0f7f5ab96aae4cd819bc ]
    
    Clang's integrated assembler complains "invalid reassignment of
    non-absolute variable 'var_ddq_add'" while assembling
    arch/x86/crypto/aes_ctrby8_avx-x86_64.S. It was because var_ddq_add was
    reassigned with non-absolute values several times, which IAS did not
    support. We can avoid the reassignment by replacing the uses of
    var_ddq_add with its definitions accordingly to have compatilibility
    with IAS.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1008
    Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
    Reported-by: Fangrui Song <maskray@google.com>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # build+boot Linux v5.7.5; clang v11.0.0-git
    Signed-off-by: Jian Cai <caij2003@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ee1fff8cd878bd961a2c9aeded72dc0c7700d13
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Aug 14 11:16:17 2020 -0700

    x86/fsgsbase/64: Fix NULL deref in 86_fsgsbase_read_task
    
    [ Upstream commit 8ab49526b53d3172d1d8dd03a75c7d1f5bd21239 ]
    
    syzbot found its way in 86_fsgsbase_read_task() and triggered this oops:
    
       KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
       CPU: 0 PID: 6866 Comm: syz-executor262 Not tainted 5.8.0-syzkaller #0
       RIP: 0010:x86_fsgsbase_read_task+0x16d/0x310 arch/x86/kernel/process_64.c:393
       Call Trace:
         putreg32+0x3ab/0x530 arch/x86/kernel/ptrace.c:876
         genregs32_set arch/x86/kernel/ptrace.c:1026 [inline]
         genregs32_set+0xa4/0x100 arch/x86/kernel/ptrace.c:1006
         copy_regset_from_user include/linux/regset.h:326 [inline]
         ia32_arch_ptrace arch/x86/kernel/ptrace.c:1061 [inline]
         compat_arch_ptrace+0x36c/0xd90 arch/x86/kernel/ptrace.c:1198
         __do_compat_sys_ptrace kernel/ptrace.c:1420 [inline]
         __se_compat_sys_ptrace kernel/ptrace.c:1389 [inline]
         __ia32_compat_sys_ptrace+0x220/0x2f0 kernel/ptrace.c:1389
         do_syscall_32_irqs_on arch/x86/entry/common.c:84 [inline]
         __do_fast_syscall_32+0x57/0x80 arch/x86/entry/common.c:126
         do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:149
         entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
    
    This can happen if ptrace() or sigreturn() pokes an LDT selector into FS
    or GS for a task with no LDT and something tries to read the base before
    a return to usermode notices the bad selector and fixes it.
    
    The fix is to make sure ldt pointer is not NULL.
    
    Fixes: 07e1d88adaae ("x86/fsgsbase/64: Fix ptrace() to read the FS/GS base accurately")
    Co-developed-by: Jann Horn <jannh@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Andy Lutomirski <luto@kernel.org>
    Cc: Chang S. Bae <chang.seok.bae@intel.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Markus T Metzger <markus.t.metzger@intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Shankar <ravi.v.shankar@intel.com>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac67d2b38a800387f108899e5ae57e1dd9a758b6
Author: Drew Fustini <drew@beagleboard.org>
Date:   Mon Jun 8 14:51:43 2020 +0200

    pinctrl-single: fix pcs_parse_pinconf() return value
    
    [ Upstream commit f46fe79ff1b65692a65266a5bec6dbe2bf7fc70f ]
    
    This patch causes pcs_parse_pinconf() to return -ENOTSUPP when no
    pinctrl_map is added.  The current behavior is to return 0 when
    !PCS_HAS_PINCONF or !nconfs.  Thus pcs_parse_one_pinctrl_entry()
    incorrectly assumes that a map was added and sets num_maps = 2.
    
    Analysis:
    =========
    The function pcs_parse_one_pinctrl_entry() calls pcs_parse_pinconf()
    if PCS_HAS_PINCONF is enabled.  The function pcs_parse_pinconf()
    returns 0 to indicate there was no error and num_maps is then set to 2:
    
     980 static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
     981                                                 struct device_node *np,
     982                                                 struct pinctrl_map **map,
     983                                                 unsigned *num_maps,
     984                                                 const char **pgnames)
     985 {
    <snip>
    1053         (*map)->type = PIN_MAP_TYPE_MUX_GROUP;
    1054         (*map)->data.mux.group = np->name;
    1055         (*map)->data.mux.function = np->name;
    1056
    1057         if (PCS_HAS_PINCONF && function) {
    1058                 res = pcs_parse_pinconf(pcs, np, function, map);
    1059                 if (res)
    1060                         goto free_pingroups;
    1061                 *num_maps = 2;
    1062         } else {
    1063                 *num_maps = 1;
    1064         }
    
    However, pcs_parse_pinconf() will also return 0 if !PCS_HAS_PINCONF or
    !nconfs.  I believe these conditions should indicate that no map was
    added by returning -ENOTSUPP. Otherwise pcs_parse_one_pinctrl_entry()
    will set num_maps = 2 even though no maps were successfully added, as
    it does not reach "m++" on line 940:
    
     895 static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
     896                              struct pcs_function *func,
     897                              struct pinctrl_map **map)
     898
     899 {
     900         struct pinctrl_map *m = *map;
    <snip>
     917         /* If pinconf isn't supported, don't parse properties in below. */
     918         if (!PCS_HAS_PINCONF)
     919                 return 0;
     920
     921         /* cacluate how much properties are supported in current node */
     922         for (i = 0; i < ARRAY_SIZE(prop2); i++) {
     923                 if (of_find_property(np, prop2[i].name, NULL))
     924                         nconfs++;
     925         }
     926         for (i = 0; i < ARRAY_SIZE(prop4); i++) {
     927                 if (of_find_property(np, prop4[i].name, NULL))
     928                         nconfs++;
     929         }
     930         if (!nconfs)
     919                 return 0;
     932
     933         func->conf = devm_kcalloc(pcs->dev,
     934                                   nconfs, sizeof(struct pcs_conf_vals),
     935                                   GFP_KERNEL);
     936         if (!func->conf)
     937                 return -ENOMEM;
     938         func->nconfs = nconfs;
     939         conf = &(func->conf[0]);
     940         m++;
    
    This situtation will cause a boot failure [0] on the BeagleBone Black
    (AM3358) when am33xx_pinmux node in arch/arm/boot/dts/am33xx-l4.dtsi
    has compatible = "pinconf-single" instead of "pinctrl-single".
    
    The patch fixes this issue by returning -ENOSUPP when !PCS_HAS_PINCONF
    or !nconfs, so that pcs_parse_one_pinctrl_entry() will know that no
    map was added.
    
    Logic is also added to pcs_parse_one_pinctrl_entry() to distinguish
    between -ENOSUPP and other errors.  In the case of -ENOSUPP, num_maps
    is set to 1 as it is valid for pinconf to be enabled and a given pin
    group to not any pinconf properties.
    
    [0] https://lore.kernel.org/linux-omap/20200529175544.GA3766151@x1/
    
    Fixes: 9dddb4df90d1 ("pinctrl: single: support generic pinconf")
    Signed-off-by: Drew Fustini <drew@beagleboard.org>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20200608125143.GA2789203@x1
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f0bd77337c2810271c04ab09a9b5154e9fa2188
Author: Wang Hai <wanghai38@huawei.com>
Date:   Mon Jun 15 11:25:33 2020 +0800

    dlm: Fix kobject memleak
    
    [ Upstream commit 0ffddafc3a3970ef7013696e7f36b3d378bc4c16 ]
    
    Currently the error return path from kobject_init_and_add() is not
    followed by a call to kobject_put() - which means we are leaking
    the kobject.
    
    Set do_unreg = 1 before kobject_init_and_add() to ensure that
    kobject_put() can be called in its error patch.
    
    Fixes: 901195ed7f4b ("Kobject: change GFS2 to use kobject_init_and_add")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ac2e3425382667ceb957d0837c81e81dc02a2dc
Author: Florinel Iordache <florinel.iordache@nxp.com>
Date:   Mon Aug 3 10:07:34 2020 +0300

    fsl/fman: fix eth hash table allocation
    
    [ Upstream commit 3207f715c34317d08e798e11a10ce816feb53c0f ]
    
    Fix memory allocation for ethernet address hash table.
    The code was wrongly allocating an array for eth hash table which
    is incorrect because this is the main structure for eth hash table
    (struct eth_hash_t) that contains inside a number of elements.
    
    Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
    Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee11e170e8205d1918e1f2f9b9b9868de96eb9a1
Author: Florinel Iordache <florinel.iordache@nxp.com>
Date:   Mon Aug 3 10:07:33 2020 +0300

    fsl/fman: check dereferencing null pointer
    
    [ Upstream commit cc5d229a122106733a85c279d89d7703f21e4d4f ]
    
    Add a safe check to avoid dereferencing null pointer
    
    Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
    Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80c8e386044c422894b49410acf64c729cf84947
Author: Florinel Iordache <florinel.iordache@nxp.com>
Date:   Mon Aug 3 10:07:32 2020 +0300

    fsl/fman: fix unreachable code
    
    [ Upstream commit cc79fd8f557767de90ff199d3b6fb911df43160a ]
    
    The parameter 'priority' is incorrectly forced to zero which ultimately
    induces logically dead code in the subsequent lines.
    
    Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
    Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b13f68bc6480bd8db6bcb10cd570221b9e453a5b
Author: Florinel Iordache <florinel.iordache@nxp.com>
Date:   Mon Aug 3 10:07:31 2020 +0300

    fsl/fman: fix dereference null return value
    
    [ Upstream commit 0572054617f32670abab4b4e89a876954d54b704 ]
    
    Check before using returned value to avoid dereferencing null pointer.
    
    Fixes: 18a6c85fcc78 ("fsl/fman: Add FMan Port Support")
    Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 178c6c8d0c47e4bd97ee65474979ef695ffbc0e7
Author: Florinel Iordache <florinel.iordache@nxp.com>
Date:   Mon Aug 3 10:07:30 2020 +0300

    fsl/fman: use 32-bit unsigned integer
    
    [ Upstream commit 99f47abd9f7bf6e365820d355dc98f6955a562df ]
    
    Potentially overflowing expression (ts_freq << 16 and intgr << 16)
    declared as type u32 (32-bit unsigned) is evaluated using 32-bit
    arithmetic and then used in a context that expects an expression of
    type u64 (64-bit unsigned) which ultimately is used as 16-bit
    unsigned by typecasting to u16. Fixed by using an unsigned 32-bit
    integer since the value is truncated anyway in the end.
    
    Fixes: 414fd46e7762 ("fsl/fman: Add FMan support")
    Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5184569002c4296c8bb94dc012b11b6ede9d9ea4
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Aug 2 15:53:33 2020 +0200

    net: spider_net: Fix the size used in a 'dma_free_coherent()' call
    
    [ Upstream commit 36f28f7687a9ce665479cce5d64ce7afaa9e77ae ]
    
    Update the size used in 'dma_free_coherent()' in order to match the one
    used in the corresponding 'dma_alloc_coherent()', in
    'spider_net_init_chain()'.
    
    Fixes: d4ed8f8d1fb7 ("Spidernet DMA coalescing")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 927b8e3acb5858d975a93b47708f61c8fbf675c5
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Sun Aug 2 19:15:44 2020 +0800

    liquidio: Fix wrong return value in cn23xx_get_pf_num()
    
    [ Upstream commit aa027850a292ea65524b8fab83eb91a124ad362c ]
    
    On an error exit path, a negative error code should be returned
    instead of a positive return value.
    
    Fixes: 0c45d7fe12c7e ("liquidio: fix use of pf in pass-through mode in a virtual machine")
    Cc: Rick Farrington <ricardo.farrington@cavium.com>
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5cf824da9a4300d7cd8ce5457e2562c091d583c
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Sun Aug 2 19:15:37 2020 +0800

    net: ethernet: aquantia: Fix wrong return value
    
    [ Upstream commit 0470a48880f8bc42ce26962b79c7b802c5a695ec ]
    
    In function hw_atl_a0_hw_multicast_list_set(), when an invalid
    request is encountered, a negative error code should be returned.
    
    Fixes: bab6de8fd180b ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions")
    Cc: David VomLehn <vomlehn@texas.net>
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 431a1b512ee33f7b765e2cd6737ae802b292ea58
Author: Andrii Nakryiko <andriin@fb.com>
Date:   Thu Jul 30 19:42:44 2020 -0700

    tools, build: Propagate build failures from tools/build/Makefile.build
    
    [ Upstream commit a278f3d8191228212c553a5d4303fa603214b717 ]
    
    The '&&' command seems to have a bad effect when $(cmd_$(1)) exits with
    non-zero effect: the command failure is masked (despite `set -e`) and all but
    the first command of $(dep-cmd) is executed (successfully, as they are mostly
    printfs), thus overall returning 0 in the end.
    
    This means in practice that despite compilation errors, tools's build Makefile
    will return success. We see this very reliably with libbpf's Makefile, which
    doesn't get compilation error propagated properly. This in turns causes issues
    with selftests build, as well as bpftool and other projects that rely on
    building libbpf.
    
    The fix is simple: don't use &&. Given `set -e`, we don't need to chain
    commands with &&. The shell will exit on first failure, giving desired
    behavior and propagating error properly.
    
    Fixes: 275e2d95591e ("tools build: Move dependency copy into function")
    Signed-off-by: Andrii Nakryiko <andriin@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jiri Olsa <jolsa@redhat.com>
    Link: https://lore.kernel.org/bpf/20200731024244.872574-1-andriin@fb.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96f448206b4b6679b93a25dc30feb0ce1f996278
Author: Wang Hai <wanghai38@huawei.com>
Date:   Thu Jul 30 15:39:39 2020 +0800

    wl1251: fix always return 0 error
    
    [ Upstream commit 20e6421344b5bc2f97b8e2db47b6994368417904 ]
    
    wl1251_event_ps_report() should not always return 0 because
    wl1251_ps_set_mode() may fail. Change it to return 'ret'.
    
    Fixes: f7ad1eed4d4b ("wl1251: retry power save entry")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200730073939.33704-1-wanghai38@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75d838fab1538eb4906d02efbb7eb8779937e795
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Thu Jul 30 17:01:20 2020 +0200

    s390/qeth: don't process empty bridge port events
    
    [ Upstream commit 02472e28b9a45471c6d8729ff2c7422baa9be46a ]
    
    Discard events that don't contain any entries. This shouldn't happen,
    but subsequent code relies on being able to use entry 0. So better
    be safe than accessing garbage.
    
    Fixes: b4d72c08b358 ("qeth: bridgeport support - basic control")
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f85a744df434cfe37ce8eea24b84bdb444b7a2e
Author: Sandipan Das <sandipan@linux.ibm.com>
Date:   Thu Jul 30 10:38:46 2020 +0530

    selftests/powerpc: Fix online CPU selection
    
    [ Upstream commit dfa03fff86027e58c8dba5c03ae68150d4e513ad ]
    
    The size of the CPU affinity mask must be large enough for
    systems with a very large number of CPUs. Otherwise, tests
    which try to determine the first online CPU by calling
    sched_getaffinity() will fail. This makes sure that the size
    of the allocated affinity mask is dependent on the number of
    CPUs as reported by get_nprocs_conf().
    
    Fixes: 3752e453f6ba ("selftests/powerpc: Add tests of PMU EBBs")
    Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/a408c4b8e9a23bb39b539417a21eb0ff47bb5127.1596084858.git.sandipan@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 581752c3f34936dbf0f2491a45d9cb57b89f688d
Author: Hanjun Guo <guohanjun@huawei.com>
Date:   Wed Jul 22 17:44:28 2020 +0800

    PCI: Release IVRS table in AMD ACS quirk
    
    [ Upstream commit 090688fa4e448284aaa16136372397d7d10814db ]
    
    The acpi_get_table() should be coupled with acpi_put_table() if the mapped
    table is not used at runtime to release the table mapping.
    
    In pci_quirk_amd_sb_acs(), IVRS table is just used for checking AMD IOMMU
    is supported, not used at runtime, so put the table after using it.
    
    Fixes: 15b100dfd1c9 ("PCI: Claim ACS support for AMD southbridge devices")
    Link: https://lore.kernel.org/r/1595411068-15440-1-git-send-email-guohanjun@huawei.com
    Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1700e567440ccadb5b5a1ddaebc700f0f8c4fdcf
Author: Harish <harish@linux.ibm.com>
Date:   Tue Jun 9 13:44:23 2020 +0530

    selftests/powerpc: Fix CPU affinity for child process
    
    [ Upstream commit 854eb5022be04f81e318765f089f41a57c8e5d83 ]
    
    On systems with large number of cpus, test fails trying to set
    affinity by calling sched_setaffinity() with smaller size for affinity
    mask. This patch fixes it by making sure that the size of allocated
    affinity mask is dependent on the number of CPUs as reported by
    get_nprocs().
    
    Fixes: 00b7ec5c9cf3 ("selftests/powerpc: Import Anton's context_switch2 benchmark")
    Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Signed-off-by: Harish <harish@linux.ibm.com>
    Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    Reviewed-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200609081423.529664-1-harish@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36bac0f1d441fc6603017dd5881a3641f011fbd5
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Tue Jul 21 10:37:16 2020 +0800

    Bluetooth: hci_serdev: Only unregister device if it was registered
    
    [ Upstream commit 202798db9570104728dce8bb57dfeed47ce764bc ]
    
    We should not call hci_unregister_dev if the device was not
    successfully registered.
    
    Fixes: c34dc3bfa7642fd ("Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca869971a904aa67813a1b04624df4cd83e06196
Author: Tom Rix <trix@redhat.com>
Date:   Sun Jul 12 12:23:51 2020 -0700

    power: supply: check if calc_soc succeeded in pm860x_init_battery
    
    [ Upstream commit ccf193dee1f0fff55b556928591f7818bac1b3b1 ]
    
    clang static analysis flags this error
    
    88pm860x_battery.c:522:19: warning: Assigned value is
      garbage or undefined [core.uninitialized.Assign]
                    info->start_soc = soc;
                                    ^ ~~~
    soc is set by calling calc_soc.
    But calc_soc can return without setting soc.
    
    So check the return status and bail similarly to other
    checks in pm860x_init_battery and initialize soc to
    silence the warning.
    
    Fixes: a830d28b48bf ("power_supply: Enable battery-charger for 88pm860x")
    
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75f8b5a67b62b40d6308f3f2998de2cfa264f212
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jul 23 18:23:05 2020 +0300

    Smack: prevent underflow in smk_set_cipso()
    
    [ Upstream commit 42a2df3e829f3c5562090391b33714b2e2e5ad4a ]
    
    We have an upper bound on "maplevel" but forgot to check for negative
    values.
    
    Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 12917b448aa665cfa032f37925a10ae5f43bee35
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jul 23 18:22:19 2020 +0300

    Smack: fix another vsscanf out of bounds
    
    [ Upstream commit a6bd4f6d9b07452b0b19842044a6c3ea384b0b88 ]
    
    This is similar to commit 84e99e58e8d1 ("Smack: slab-out-of-bounds in
    vsscanf") where we added a bounds check on "rule".
    
    Reported-by: syzbot+a22c6092d003d6fe1122@syzkaller.appspotmail.com
    Fixes: f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5af2995953ec553ee190a5ba8d544d2f942efd76
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Fri Jul 24 11:21:20 2020 +1200

    net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration
    
    [ Upstream commit 0f3c66a3c7b4e8b9f654b3c998e9674376a51b0f ]
    
    The MV88E6097 chip does not support configuring jumbo frames. Prior to
    commit 5f4366660d65 only the 6352, 6351, 6165 and 6320 chips configured
    jumbo mode. The refactor accidentally added the function for the 6097.
    Remove the erroneous function pointer assignment.
    
    Fixes: 5f4366660d65 ("net: dsa: mv88e6xxx: Refactor setting of jumbo frames")
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74d1e724b115abb7ed40498c9cd75b1ff2c69f1e
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Thu Jul 23 09:25:51 2020 +1000

    scsi: mesh: Fix panic after host or bus reset
    
    [ Upstream commit edd7dd2292ab9c3628b65c4d04514c3068ad54f6 ]
    
    Booting Linux with a Conner CP3200 drive attached to the MESH SCSI bus
    results in EH measures and a panic:
    
    [   25.499838] mesh: configured for synchronous 5 MB/s
    [   25.787154] mesh: performing initial bus reset...
    [   29.867115] scsi host0: MESH
    [   29.929527] mesh: target 0 synchronous at 3.6 MB/s
    [   29.998763] scsi 0:0:0:0: Direct-Access     CONNER   CP3200-200mb-3.5 4040 PQ: 0 ANSI: 1 CCS
    [   31.989975] sd 0:0:0:0: [sda] 415872 512-byte logical blocks: (213 MB/203 MiB)
    [   32.070975] sd 0:0:0:0: [sda] Write Protect is off
    [   32.137197] sd 0:0:0:0: [sda] Mode Sense: 5b 00 00 08
    [   32.209661] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [   32.332708]  sda: [mac] sda1 sda2 sda3
    [   32.417733] sd 0:0:0:0: [sda] Attached SCSI disk
    ... snip ...
    [   76.687067] mesh_abort((ptrval))
    [   76.743606] mesh: state at (ptrval), regs at (ptrval), dma at (ptrval)
    [   76.810798]     ct=6000 seq=86 bs=4017 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=85
    [   76.880720]     dma stat=84e0 cmdptr=1f73d000
    [   76.941387]     phase=4 msgphase=0 conn_tgt=0 data_ptr=24576
    [   77.005567]     dma_st=1 dma_ct=0 n_msgout=0
    [   77.065456]     target 0: req=(ptrval) goes_out=0 saved_ptr=0
    [   77.130512] mesh_abort((ptrval))
    [   77.187670] mesh: state at (ptrval), regs at (ptrval), dma at (ptrval)
    [   77.255594]     ct=6000 seq=86 bs=4017 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=85
    [   77.325778]     dma stat=84e0 cmdptr=1f73d000
    [   77.387239]     phase=4 msgphase=0 conn_tgt=0 data_ptr=24576
    [   77.453665]     dma_st=1 dma_ct=0 n_msgout=0
    [   77.515900]     target 0: req=(ptrval) goes_out=0 saved_ptr=0
    [   77.582902] mesh_host_reset
    [   88.187083] Kernel panic - not syncing: mesh: double DMA start !
    [   88.254510] CPU: 0 PID: 358 Comm: scsi_eh_0 Not tainted 5.6.13-pmac #1
    [   88.323302] Call Trace:
    [   88.378854] [e16ddc58] [c0027080] panic+0x13c/0x308 (unreliable)
    [   88.446221] [e16ddcb8] [c02b2478] mesh_start.part.12+0x130/0x414
    [   88.513298] [e16ddcf8] [c02b2fc8] mesh_queue+0x54/0x70
    [   88.577097] [e16ddd18] [c02a1848] scsi_send_eh_cmnd+0x374/0x384
    [   88.643476] [e16dddc8] [c02a1938] scsi_eh_tur+0x5c/0xb8
    [   88.707878] [e16dddf8] [c02a1ab8] scsi_eh_test_devices+0x124/0x178
    [   88.775663] [e16dde28] [c02a2094] scsi_eh_ready_devs+0x588/0x8a8
    [   88.843124] [e16dde98] [c02a31d8] scsi_error_handler+0x344/0x520
    [   88.910697] [e16ddf08] [c00409c8] kthread+0xe4/0xe8
    [   88.975166] [e16ddf38] [c000f234] ret_from_kernel_thread+0x14/0x1c
    [   89.044112] Rebooting in 180 seconds..
    
    In theory, a panic can happen after a bus or host reset with dma_started
    flag set. Fix this by halting the DMA before reinitializing the host.
    Don't assume that ms->current_req is set when halt_dma() is invoked as it
    may not hold for bus or host reset.
    
    BTW, this particular Conner drive can be made to work by inhibiting
    disconnect/reselect with 'mesh.resel_targets=0'.
    
    Link: https://lore.kernel.org/r/3952bc691e150a7128b29120999b6092071b039a.1595460351.git.fthain@telegraphics.com.au
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: Paul Mackerras <paulus@ozlabs.org>
    Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a8841b9f3eb1f46e3fc6d56a9b9299c53f4f86f
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Jul 16 14:09:48 2020 +0200

    usb: dwc2: Fix error path in gadget registration
    
    [ Upstream commit 33a06f1300a79cfd461cea0268f05e969d4f34ec ]
    
    When gadget registration fails, one should not call usb_del_gadget_udc().
    Ensure this by setting gadget->udc to NULL. Also in case of a failure
    there is no need to disable low-level hardware, so return immiedetly
    instead of jumping to error_init label.
    
    This fixes the following kernel NULL ptr dereference on gadget failure
    (can be easily triggered with g_mass_storage without any module
    parameters):
    
    dwc2 12480000.hsotg: dwc2_check_params: Invalid parameter besl=1
    dwc2 12480000.hsotg: dwc2_check_params: Invalid parameter g_np_tx_fifo_size=1024
    dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
    Mass Storage Function, version: 2009/09/11
    LUN: removable file: (no medium)
    no file given for LUN0
    g_mass_storage 12480000.hsotg: failed to start g_mass_storage: -22
    8<--- cut here ---
    Unable to handle kernel NULL pointer dereference at virtual address 00000104
    pgd = (ptrval)
    [00000104] *pgd=00000000
    Internal error: Oops: 805 [#1] PREEMPT SMP ARM
    Modules linked in:
    CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.8.0-rc5 #3133
    Hardware name: Samsung Exynos (Flattened Device Tree)
    Workqueue: events deferred_probe_work_func
    PC is at usb_del_gadget_udc+0x38/0xc4
    LR is at __mutex_lock+0x31c/0xb18
    ...
    Process kworker/0:1 (pid: 12, stack limit = 0x(ptrval))
    Stack: (0xef121db0 to 0xef122000)
    ...
    [<c076bf3c>] (usb_del_gadget_udc) from [<c0726bec>] (dwc2_hsotg_remove+0x10/0x20)
    [<c0726bec>] (dwc2_hsotg_remove) from [<c0711208>] (dwc2_driver_probe+0x57c/0x69c)
    [<c0711208>] (dwc2_driver_probe) from [<c06247c0>] (platform_drv_probe+0x6c/0xa4)
    [<c06247c0>] (platform_drv_probe) from [<c0621df4>] (really_probe+0x200/0x48c)
    [<c0621df4>] (really_probe) from [<c06221e8>] (driver_probe_device+0x78/0x1fc)
    [<c06221e8>] (driver_probe_device) from [<c061fcd4>] (bus_for_each_drv+0x74/0xb8)
    [<c061fcd4>] (bus_for_each_drv) from [<c0621b54>] (__device_attach+0xd4/0x16c)
    [<c0621b54>] (__device_attach) from [<c0620c98>] (bus_probe_device+0x88/0x90)
    [<c0620c98>] (bus_probe_device) from [<c06211b0>] (deferred_probe_work_func+0x3c/0xd0)
    [<c06211b0>] (deferred_probe_work_func) from [<c0149280>] (process_one_work+0x234/0x7dc)
    [<c0149280>] (process_one_work) from [<c014986c>] (worker_thread+0x44/0x51c)
    [<c014986c>] (worker_thread) from [<c0150b1c>] (kthread+0x158/0x1a0)
    [<c0150b1c>] (kthread) from [<c0100114>] (ret_from_fork+0x14/0x20)
    Exception stack(0xef121fb0 to 0xef121ff8)
    ...
    ---[ end trace 9724c2fc7cc9c982 ]---
    
    While fixing this also fix the double call to dwc2_lowlevel_hw_disable()
    if dr_mode is set to USB_DR_MODE_PERIPHERAL. In such case low-level
    hardware is already disabled before calling usb_add_gadget_udc(). That
    function correctly preserves low-level hardware state, there is no need
    for the second unconditional dwc2_lowlevel_hw_disable() call.
    
    Fixes: 207324a321a8 ("usb: dwc2: Postponed gadget registration to the udc class driver")
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee5f968a2df9c3880434a8240407355278e40d4f
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Jul 21 21:47:18 2020 +0800

    MIPS: OCTEON: add missing put_device() call in dwc3_octeon_device_init()
    
    [ Upstream commit e8b9fc10f2615b9a525fce56981e40b489528355 ]
    
    if of_find_device_by_node() succeed, dwc3_octeon_device_init() doesn't have
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling for this function implementation.
    
    Fixes: 93e502b3c2d4 ("MIPS: OCTEON: Platform support for OCTEON III USB controller")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93934e5d463b31e9d118c4b52aa8d1266c7f503e
Author: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Date:   Thu Jul 16 11:57:42 2020 -0600

    coresight: tmc: Fix TMC mode read in tmc_read_unprepare_etb()
    
    [ Upstream commit d021f5c5ff679432c5e9faee0fd7350db2efb97c ]
    
    Reading TMC mode register without proper coresight power
    management can lead to exceptions like the one in the call
    trace below in tmc_read_unprepare_etb() when the trace data
    is read after the sink is disabled. So fix this by having
    a check for coresight sysfs mode before reading TMC mode
    management register in tmc_read_unprepare_etb() similar to
    tmc_read_prepare_etb().
    
      SError Interrupt on CPU6, code 0xbe000411 -- SError
      pstate: 80400089 (Nzcv daIf +PAN -UAO)
      pc : tmc_read_unprepare_etb+0x74/0x108
      lr : tmc_read_unprepare_etb+0x54/0x108
      sp : ffffff80d9507c30
      x29: ffffff80d9507c30 x28: ffffff80b3569a0c
      x27: 0000000000000000 x26: 00000000000a0001
      x25: ffffff80cbae9550 x24: 0000000000000010
      x23: ffffffd07296b0f0 x22: ffffffd0109ee028
      x21: 0000000000000000 x20: ffffff80d19e70e0
      x19: ffffff80d19e7080 x18: 0000000000000000
      x17: 0000000000000000 x16: 0000000000000000
      x15: 0000000000000000 x14: 0000000000000000
      x13: 0000000000000000 x12: 0000000000000000
      x11: 0000000000000000 x10: dfffffd000000001
      x9 : 0000000000000000 x8 : 0000000000000002
      x7 : ffffffd071d0fe78 x6 : 0000000000000000
      x5 : 0000000000000080 x4 : 0000000000000001
      x3 : ffffffd071d0fe98 x2 : 0000000000000000
      x1 : 0000000000000004 x0 : 0000000000000001
      Kernel panic - not syncing: Asynchronous SError Interrupt
    
    Fixes: 4525412a5046 ("coresight: tmc: making prepare/unprepare functions generic")
    Reported-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
    Tested-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20200716175746.3338735-14-mathieu.poirier@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de3661a5687b209fdd2803c5c1769aca0f5d2ac6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jun 16 12:19:49 2020 +0300

    thermal: ti-soc-thermal: Fix reversed condition in ti_thermal_expose_sensor()
    
    [ Upstream commit 0f348db01fdf128813fdd659fcc339038fb421a4 ]
    
    This condition is reversed and will cause breakage.
    
    Fixes: 7440f518dad9 ("thermal/drivers/ti-soc-thermal: Avoid dereferencing ERR_PTR")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20200616091949.GA11940@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84e7557dc2217ab10b12b0ac09fd1f95ccc395d5
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Jul 16 10:50:55 2020 +0200

    USB: serial: iuu_phoenix: fix led-activity helpers
    
    [ Upstream commit de37458f8c2bfc465500a1dd0d15dbe96d2a698c ]
    
    The set-led command is eight bytes long and starts with a command byte
    followed by six bytes of RGB data and ends with a byte encoding a
    frequency (see iuu_led() and iuu_rgbf_fill_buffer()).
    
    The led activity helpers had a few long-standing bugs which corrupted
    the command packets by inserting a second command byte and thereby
    offsetting the RGB data and dropping the frequency in non-xmas mode.
    
    In xmas mode, a related off-by-one error left the frequency field
    uninitialised.
    
    Fixes: 60a8fc017103 ("USB: add iuu_phoenix driver")
    Reported-by: George Spelvin <lkml@sdf.org>
    Link: https://lore.kernel.org/r/20200716085056.31471-1-johan@kernel.org
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7491a5bff0b9e4f1c8f24dfcab024a4dc0313c24
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Thu Jun 11 14:43:32 2020 +0200

    drm/imx: tve: fix regulator_disable error path
    
    [ Upstream commit 7bb58b987fee26da2a1665c01033022624986b7c ]
    
    Add missing regulator_disable() as devm_action to avoid dedicated
    unbind() callback and fix the missing error handling.
    
    Fixes: fcbc51e54d2a ("staging: drm/imx: Add support for Television Encoder (TVEv2)")
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 910e33e2f62376b3cd2a1cd25e5d08d3298cc90c
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Fri Jul 17 15:59:25 2020 +0800

    PCI/ASPM: Add missing newline in sysfs 'policy'
    
    [ Upstream commit 3167e3d340c092fd47924bc4d23117a3074ef9a9 ]
    
    When I cat ASPM parameter 'policy' by sysfs, it displays as follows.  Add a
    newline for easy reading.  Other sysfs attributes already include a
    newline.
    
      [root@localhost ~]# cat /sys/module/pcie_aspm/parameters/policy
      [default] performance powersave powersupersave [root@localhost ~]#
    
    Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
    Link: https://lore.kernel.org/r/1594972765-10404-1-git-send-email-wangxiongfeng2@huawei.com
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d548f0f566fc1a3bd8efb58df66d7749476d0b3e
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jul 16 16:47:20 2020 +0100

    staging: rtl8192u: fix a dubious looking mask before a shift
    
    [ Upstream commit c4283950a9a4d3bf4a3f362e406c80ab14f10714 ]
    
    Currently the masking of ret with 0xff and followed by a right shift
    of 8 bits always leaves a zero result.  It appears the mask of 0xff
    is incorrect and should be 0xff00, but I don't have the hardware to
    test this. Fix this to mask the upper 8 bits before shifting.
    
    [ Not tested ]
    
    Addresses-Coverity: ("Operands don't affect result")
    Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20200716154720.1710252-1-colin.king@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 172f9611b745fbda27a46a23af4d381b96eb148f
Author: Milton Miller <miltonm@us.ibm.com>
Date:   Thu Jul 16 09:37:04 2020 +1000

    powerpc/vdso: Fix vdso cpu truncation
    
    [ Upstream commit a9f675f950a07d5c1dbcbb97aabac56f5ed085e3 ]
    
    The code in vdso_cpu_init that exposes the cpu and numa node to
    userspace via SPRG_VDSO incorrctly masks the cpu to 12 bits. This means
    that any kernel running on a box with more than 4096 threads (NR_CPUS
    advertises a limit of of 8192 cpus) would expose userspace to two cpu
    contexts running at the same time with the same cpu number.
    
    Note: I'm not aware of any distro shipping a kernel with support for more
    than 4096 threads today, nor of any system image that currently exceeds
    4096 threads. Found via code browsing.
    
    Fixes: 18ad51dd342a7eb09dbcd059d0b451b616d4dafc ("powerpc: Add VDSO version of getcpu")
    Signed-off-by: Milton Miller <miltonm@us.ibm.com>
    Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200715233704.1352257-1-anton@ozlabs.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 164d80107670adadf8a5de9ffa8e31cee5979e7f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jul 8 14:58:57 2020 +0300

    mwifiex: Prevent memory corruption handling keys
    
    [ Upstream commit e18696786548244914f36ec3c46ac99c53df99c3 ]
    
    The length of the key comes from the network and it's a 16 bit number.  It
    needs to be capped to prevent a buffer overflow.
    
    Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200708115857.GA13729@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4665a815ffe8295d687d4b3ffec0bbdd98b1731a
Author: John Garry <john.garry@huawei.com>
Date:   Thu Jul 9 20:23:19 2020 +0800

    scsi: scsi_debug: Add check for sdebug_max_queue during module init
    
    [ Upstream commit c87bf24cfb60bce27b4d2c7e56ebfd86fb9d16bb ]
    
    sdebug_max_queue should not exceed SDEBUG_CANQUEUE, otherwise crashes like
    this can be triggered by passing an out-of-range value:
    
    Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
     pstate: 20400009 (nzCv daif +PAN -UAO BTYPE=--)
     pc : schedule_resp+0x2a4/0xa70 [scsi_debug]
     lr : schedule_resp+0x52c/0xa70 [scsi_debug]
     sp : ffff800022ab36f0
     x29: ffff800022ab36f0 x28: ffff0023a935a610
     x27: ffff800008e0a648 x26: 0000000000000003
     x25: ffff0023e84f3200 x24: 00000000003d0900
     x23: 0000000000000000 x22: 0000000000000000
     x21: ffff0023be60a320 x20: ffff0023be60b538
     x19: ffff800008e13000 x18: 0000000000000000
     x17: 0000000000000000 x16: 0000000000000000
     x15: 0000000000000000 x14: 0000000000000000
     x13: 0000000000000000 x12: 0000000000000000
     x11: 0000000000000000 x10: 0000000000000000
     x9 : 0000000000000001 x8 : 0000000000000000
     x7 : 0000000000000000 x6 : 00000000000000c1
     x5 : 0000020000200000 x4 : dead0000000000ff
     x3 : 0000000000000200 x2 : 0000000000000200
     x1 : ffff800008e13d88 x0 : 0000000000000000
     Call trace:
    schedule_resp+0x2a4/0xa70 [scsi_debug]
    scsi_debug_queuecommand+0x2c4/0x9e0 [scsi_debug]
    scsi_queue_rq+0x698/0x840
    __blk_mq_try_issue_directly+0x108/0x228
    blk_mq_request_issue_directly+0x58/0x98
    blk_mq_try_issue_list_directly+0x5c/0xf0
    blk_mq_sched_insert_requests+0x18c/0x200
    blk_mq_flush_plug_list+0x11c/0x190
    blk_flush_plug_list+0xdc/0x110
    blk_finish_plug+0x38/0x210
    blkdev_direct_IO+0x450/0x4d8
    generic_file_read_iter+0x84/0x180
    blkdev_read_iter+0x3c/0x50
    aio_read+0xc0/0x170
    io_submit_one+0x5c8/0xc98
    __arm64_sys_io_submit+0x1b0/0x258
    el0_svc_common.constprop.3+0x68/0x170
    do_el0_svc+0x24/0x90
    el0_sync_handler+0x13c/0x1a8
    el0_sync+0x158/0x180
     Code: 528847e0 72a001e0 6b00003f 540018cd (3941c340)
    
    In addition, it should not be less than 1.
    
    So add checks for these, and fail the module init for those cases.
    
    [mkp: changed if condition to match error message]
    
    Link: https://lore.kernel.org/r/1594297400-24756-2-git-send-email-john.garry@huawei.com
    Fixes: c483739430f1 ("scsi_debug: add multiple queue support")
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9bd86777b4b0700ce6ce678d893382813ee09c2f
Author: Tom Rix <trix@redhat.com>
Date:   Sun Jul 12 08:24:53 2020 -0700

    drm/bridge: sil_sii8620: initialize return of sii8620_readb
    
    [ Upstream commit 02cd2d3144653e6e2a0c7ccaa73311e48e2dc686 ]
    
    clang static analysis flags this error
    
    sil-sii8620.c:184:2: warning: Undefined or garbage value
      returned to caller [core.uninitialized.UndefReturn]
            return ret;
            ^~~~~~~~~~
    
    sii8620_readb calls sii8620_read_buf.
    sii8620_read_buf can return without setting its output
    pararmeter 'ret'.
    
    So initialize ret.
    
    Fixes: ce6e153f414a ("drm/bridge: add Silicon Image SiI8620 driver")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200712152453.27510-1-trix@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b0d455389e53f264a601423b6fbc92b11a41a84
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Sun Jul 12 01:53:17 2020 +0300

    drm: panel: simple: Fix bpc for LG LB070WV8 panel
    
    [ Upstream commit a6ae2fe5c9f9fd355a48fb7d21c863e5b20d6c9c ]
    
    The LG LB070WV8 panel incorrectly reports a 16 bits per component value,
    while the panel uses 8 bits per component. Fix it.
    
    Fixes: dd0150026901 ("drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel")
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200711225317.28476-1-laurent.pinchart+renesas@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a14ab85a26751b93d9b0597600e0895488a75730
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Thu Jul 2 13:45:00 2020 +0800

    leds: core: Flush scheduled work for system suspend
    
    [ Upstream commit 302a085c20194bfa7df52e0fe684ee0c41da02e6 ]
    
    Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
    system suspend.
    
    led_set_brightness_nopm() uses schedule_work() to set LED brightness.
    However, there's no guarantee that the scheduled work gets executed
    because no one flushes the work.
    
    So flush the scheduled work to make sure LED gets turned off.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
    Fixes: 81fe8e5b73e3 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7751804f04f3784b59b4812a06458efddd730659
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jun 25 18:14:55 2020 -0500

    PCI: Fix pci_cfg_wait queue locking problem
    
    [ Upstream commit 2a7e32d0547f41c5ce244f84cf5d6ca7fccee7eb ]
    
    The pci_cfg_wait queue is used to prevent user-space config accesses to
    devices while they are recovering from reset.
    
    Previously we used these operations on pci_cfg_wait:
    
      __add_wait_queue(&pci_cfg_wait, ...)
      __remove_wait_queue(&pci_cfg_wait, ...)
      wake_up_all(&pci_cfg_wait)
    
    The wake_up acquires the wait queue lock, but the add and remove do not.
    
    Originally these were all protected by the pci_lock, but cdcb33f98244
    ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock"), moved
    wake_up_all() outside pci_lock, so it could race with add/remove
    operations, which caused occasional kernel panics, e.g., during vfio-pci
    hotplug/unplug testing:
    
      Unable to handle kernel read from unreadable memory at virtual address ffff802dac469000
    
    Resolve this by using wait_event() instead of __add_wait_queue() and
    __remove_wait_queue().  The wait queue lock is held by both wait_event()
    and wake_up_all(), so it provides mutual exclusion.
    
    Fixes: cdcb33f98244 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock")
    Link: https://lore.kernel.org/linux-pci/79827f2f-9b43-4411-1376-b9063b67aee3@huawei.com/T/#u
    Based-on: https://lore.kernel.org/linux-pci/20191210031527.40136-1-zhengxiang9@huawei.com/
    Based-on-patch-by: Xiang Zheng <zhengxiang9@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Xiang Zheng <zhengxiang9@huawei.com>
    Cc: Heyi Guo <guoheyi@huawei.com>
    Cc: Biaoxiang Ye <yebiaoxiang@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c37f37c5b1b6c6fb6d4ac59b97f7316e3cd04c94
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Mon Jun 29 14:47:18 2020 -0700

    xfs: fix reflink quota reservation accounting error
    
    [ Upstream commit 83895227aba1ade33e81f586aa7b6b1e143096a5 ]
    
    Quota reservations are supposed to account for the blocks that might be
    allocated due to a bmap btree split.  Reflink doesn't do this, so fix
    this to make the quota accounting more accurate before we start
    rearranging things.
    
    Fixes: 862bb360ef56 ("xfs: reflink extents from one file to another")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d74cda0cdbc4f75e10a084643bcb31b02ea583b
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Thu May 28 08:41:47 2020 +0200

    media: exynos4-is: Add missed check for pinctrl_lookup_state()
    
    [ Upstream commit 18ffec750578f7447c288647d7282c7d12b1d969 ]
    
    fimc_md_get_pinctrl() misses a check for pinctrl_lookup_state().
    Add the missed check to fix it.
    
    Fixes: 4163851f7b99 ("[media] s5p-fimc: Use pinctrl API for camera ports configuration]")
    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>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit faff4562a4f6b1ded4fee75abeb52c6a23d8cfc8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri May 8 16:40:22 2020 +0200

    media: firewire: Using uninitialized values in node_probe()
    
    [ Upstream commit 2505a210fc126599013aec2be741df20aaacc490 ]
    
    If fw_csr_string() returns -ENOENT, then "name" is uninitialized.  So
    then the "strlen(model_names[i]) <= name_len" is true because strlen()
    is unsigned and -ENOENT is type promoted to a very high positive value.
    Then the "strncmp(name, model_names[i], name_len)" uses uninitialized
    data because "name" is uninitialized.
    
    Fixes: 92374e886c75 ("[media] firedtv: drop obsolete backend abstraction")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    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 ff9e162946e1b8051ffe357994d382077d909b2e
Author: Julian Anastasov <ja@ssi.bg>
Date:   Wed Jul 1 18:17:19 2020 +0300

    ipvs: allow connection reuse for unconfirmed conntrack
    
    [ Upstream commit f0a5e4d7a594e0fe237d3dfafb069bb82f80f42f ]
    
    YangYuxi is reporting that connection reuse
    is causing one-second delay when SYN hits
    existing connection in TIME_WAIT state.
    Such delay was added to give time to expire
    both the IPVS connection and the corresponding
    conntrack. This was considered a rare case
    at that time but it is causing problem for
    some environments such as Kubernetes.
    
    As nf_conntrack_tcp_packet() can decide to
    release the conntrack in TIME_WAIT state and
    to replace it with a fresh NEW conntrack, we
    can use this to allow rescheduling just by
    tuning our check: if the conntrack is
    confirmed we can not schedule it to different
    real server and the one-second delay still
    applies but if new conntrack was created,
    we are free to select new real server without
    any delays.
    
    YangYuxi lists some of the problem reports:
    
    - One second connection delay in masquerading mode:
    https://marc.info/?t=151683118100004&r=1&w=2
    
    - IPVS low throughput #70747
    https://github.com/kubernetes/kubernetes/issues/70747
    
    - Apache Bench can fill up ipvs service proxy in seconds #544
    https://github.com/cloudnativelabs/kube-router/issues/544
    
    - Additional 1s latency in `host -> service IP -> pod`
    https://github.com/kubernetes/kubernetes/issues/90854
    
    Fixes: f719e3754ee2 ("ipvs: drop first packet to redirect conntrack")
    Co-developed-by: YangYuxi <yx.atom1@gmail.com>
    Signed-off-by: YangYuxi <yx.atom1@gmail.com>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Reviewed-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0658ced3cec83be3c4d745ddc2e4d38d450573f
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Jun 26 06:05:53 2020 +0200

    scsi: eesox: Fix different dev_id between request_irq() and free_irq()
    
    [ Upstream commit 86f2da1112ccf744ad9068b1d5d9843faf8ddee6 ]
    
    The dev_id used in request_irq() and free_irq() should match. Use 'info' in
    both cases.
    
    Link: https://lore.kernel.org/r/20200626040553.944352-1-christophe.jaillet@wanadoo.fr
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e050ad8f5316c961033276b4b76c31dc4cd90183
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Jun 26 05:59:48 2020 +0200

    scsi: powertec: Fix different dev_id between request_irq() and free_irq()
    
    [ Upstream commit d179f7c763241c1dc5077fca88ddc3c47d21b763 ]
    
    The dev_id used in request_irq() and free_irq() should match. Use 'info' in
    both cases.
    
    Link: https://lore.kernel.org/r/20200626035948.944148-1-christophe.jaillet@wanadoo.fr
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da89c73f12f6c7cff0581d6a7d260d5ee6cefba8
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Jun 24 13:07:10 2020 +0100

    drm/radeon: fix array out-of-bounds read and write issues
    
    [ Upstream commit 7ee78aff9de13d5dccba133f4a0de5367194b243 ]
    
    There is an off-by-one bounds check on the index into arrays
    table->mc_reg_address and table->mc_reg_table_entry[k].mc_data[j] that
    can lead to reads and writes outside of arrays. Fix the bound checking
    off-by-one error.
    
    Addresses-Coverity: ("Out-of-bounds read/write")
    Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d36d0a898b4d13ba36f66c897dd7e871b3cdef3
Author: Wang Hai <wanghai38@huawei.com>
Date:   Tue Jun 2 20:07:33 2020 +0800

    cxl: Fix kobject memleak
    
    [ Upstream commit 85c5cbeba8f4fb28e6b9bfb3e467718385f78f76 ]
    
    Currently the error return path from kobject_init_and_add() is not
    followed by a call to kobject_put() - which means we are leaking
    the kobject.
    
    Fix it by adding a call to kobject_put() in the error path of
    kobject_init_and_add().
    
    Fixes: b087e6190ddc ("cxl: Export optional AFU configuration record in sysfs")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
    Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Link: https://lore.kernel.org/r/20200602120733.5943-1-wanghai38@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e5271637d74f5d0981a101e59e959d736449e28
Author: Emil Velikov <emil.velikov@collabora.com>
Date:   Tue May 5 17:03:29 2020 +0100

    drm/mipi: use dcs write for mipi_dsi_dcs_set_tear_scanline
    
    [ Upstream commit 7a05c3b6d24b8460b3cec436cf1d33fac43c8450 ]
    
    The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
    using the generic write. This does not look right.
    
    Perhaps some platforms don't distinguish between the two writers?
    
    Cc: Robert Chiras <robert.chiras@nxp.com>
    Cc: Vinay Simha BN <simhavcs@gmail.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Thierry Reding <treding@nvidia.com>
    Fixes: e83950816367 ("drm/dsi: Implement set tear scanline")
    Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200505160329.2976059-3-emil.l.velikov@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c58f4ad2e57893f9dfbf254426ded22d4226f4a
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Jun 25 22:47:30 2020 +0200

    scsi: cumana_2: Fix different dev_id between request_irq() and free_irq()
    
    [ Upstream commit 040ab9c4fd0070cd5fa71ba3a7b95b8470db9b4d ]
    
    The dev_id used in request_irq() and free_irq() should match.  Use 'info'
    in both cases.
    
    Link: https://lore.kernel.org/r/20200625204730.943520-1-christophe.jaillet@wanadoo.fr
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95a6447b0a346b65bfd0e6566b69d7371afd6040
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Jun 25 14:12:55 2020 -0500

    ASoC: Intel: bxt_rt298: add missing .owner field
    
    [ Upstream commit 88cee34b776f80d2da04afb990c2a28c36799c43 ]
    
    This field is required for ASoC cards. Not setting it will result in a
    module->name pointer being NULL and generate problems such as
    
    cat /proc/asound/modules
     0 (efault)
    
    Fixes: 76016322ec56 ('ASoC: Intel: Add Broxton-P machine driver')
    Reported-by: Jaroslav Kysela <perex@perex.cz>
    Suggested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20200625191308.3322-5-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6059d5a8c6217e843f69a38117800b9f26e0c08b
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Wed Jun 3 18:41:22 2020 +0200

    media: omap3isp: Add missed v4l2_ctrl_handler_free() for preview_init_entities()
    
    [ Upstream commit dc7690a73017e1236202022e26a6aa133f239c8c ]
    
    preview_init_entities() does not call v4l2_ctrl_handler_free() when
    it fails.
    Add the missed function to fix it.
    
    Fixes: de1135d44f4f ("[media] omap3isp: CCDC, preview engine and resizer")
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e361b9c851ad749dc4f5dae18c00a6070e946b38
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue May 5 16:19:17 2020 +0200

    leds: lm355x: avoid enum conversion warning
    
    [ Upstream commit 985b1f596f9ed56f42b8c2280005f943e1434c06 ]
    
    clang points out that doing arithmetic between diffent enums is usually
    a mistake:
    
    drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
                    reg_val = pdata->pin_tx2 | pdata->ntc_pin;
                              ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
    drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
                    reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
                              ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
    
    In this driver, it is intentional, so add a cast to hide the false-positive
    warning. It appears to be the only instance of this warning at the moment.
    
    Fixes: b98d13c72592 ("leds: Add new LED driver for lm355x chips")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 325dbbbefbe9cab6842cf67baf23e6521e39f6f2
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jun 18 11:04:00 2020 +0100

    drm/arm: fix unintentional integer overflow on left shift
    
    [ Upstream commit 5f368ddea6fec519bdb93b5368f6a844b6ea27a6 ]
    
    Shifting the integer value 1 is evaluated using 32-bit arithmetic
    and then used in an expression that expects a long value leads to
    a potential integer overflow. Fix this by using the BIT macro to
    perform the shift to avoid the overflow.
    
    Addresses-Coverity: ("Unintentional integer overflow")
    Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Liviu Dudau <liviu.dudau@arm.com>
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200618100400.11464-1-colin.king@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce2f02ca2995159910dba37aa2eab822fde80690
Author: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Date:   Mon Jun 1 18:15:52 2020 +0200

    iio: improve IIO_CONCENTRATION channel type description
    
    [ Upstream commit df16c33a4028159d1ba8a7061c9fa950b58d1a61 ]
    
    IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting
    raw concentrations of pollutants. Raw value should be meaningless
    before being properly scaled. Because of that description shouldn't
    mention raw value unit whatsoever.
    
    Fix this by rephrasing existing description so it follows conventions
    used throughout IIO ABI docs.
    
    Fixes: 8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type")
    Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
    Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 613da0efb4aa7168ce54f0e990c068b7bc2fae28
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Apr 29 10:45:05 2020 +0200

    video: pxafb: Fix the function used to balance a 'dma_alloc_coherent()' call
    
    [ Upstream commit 499a2c41b954518c372873202d5e7714e22010c4 ]
    
    'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()'
    not 'dma_free_wc()'.
    The correct dma_free_ function is already used in the error handling path
    of the probe function.
    
    Fixes: 77e196752bdd ("[ARM] pxafb: allow video memory size to be configurable")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: Sumit Semwal <sumit.semwal@linaro.org>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Jani Nikula <jani.nikula@intel.com>
    cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Cc: Eric Miao <eric.miao@marvell.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200429084505.108897-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93a7e1d1fc4ba3e76ec82bc905a9fc152d73d033
Author: Dejin Zheng <zhengdejin5@gmail.com>
Date:   Fri Apr 24 00:42:51 2020 +0800

    console: newport_con: fix an issue about leak related system resources
    
    [ Upstream commit fd4b8243877250c05bb24af7fea5567110c9720b ]
    
    A call of the function do_take_over_console() can fail here.
    The corresponding system resources were not released then.
    Thus add a call of iounmap() and release_mem_region()
    together with the check of a failure predicate. and also
    add release_mem_region() on device removal.
    
    Fixes: e86bb8acc0fdc ("[PATCH] VT binding: Make newport_con support binding")
    Suggested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200423164251.3349-1-zhengdejin5@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc894cda6fe36838008c4c3dce26fb80698391a8
Author: Dejin Zheng <zhengdejin5@gmail.com>
Date:   Thu Apr 23 00:07:19 2020 +0800

    video: fbdev: sm712fb: fix an issue about iounmap for a wrong address
    
    [ Upstream commit 98bd4f72988646c35569e1e838c0ab80d06c77f6 ]
    
    the sfb->fb->screen_base is not save the value get by iounmap() when
    the chip id is 0x720. so iounmap() for address sfb->fb->screen_base
    is not right.
    
    Fixes: 1461d6672864854 ("staging: sm7xxfb: merge sm712fb with fbdev")
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Cc: Teddy Wang <teddy.wang@siliconmotion.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200422160719.27763-1-zhengdejin5@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3ad6a3db008e4565d97da15c00ef25ee4b5b59a
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Fri May 22 09:34:51 2020 +0100

    agp/intel: Fix a memory leak on module initialisation failure
    
    [ Upstream commit b975abbd382fe442713a4c233549abb90e57c22b ]
    
    In intel_gtt_setup_scratch_page(), pointer "page" is not released if
    pci_dma_mapping_error() return an error, leading to a memory leak on
    module initialisation failure.  Simply fix this issue by freeing "page"
    before return.
    
    Fixes: 0e87d2b06cb46 ("intel-gtt: initialize our own scratch page")
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200522083451.7448-1-chris@chris-wilson.co.uk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57645ea316d0c43b82ea82664f1685e072fd396e
Author: Erik Kaneda <erik.kaneda@intel.com>
Date:   Mon Jul 20 10:31:20 2020 -0700

    ACPICA: Do not increment operation_region reference counts for field units
    
    [ Upstream commit 6a54ebae6d047c988a31f5ac5a64ab5cf83797a2 ]
    
    ACPICA commit e17b28cfcc31918d0db9547b6b274b09c413eb70
    
    Object reference counts are used as a part of ACPICA's garbage
    collection mechanism. This mechanism keeps track of references to
    heap-allocated structures such as the ACPI operand objects.
    
    Recent server firmware has revealed that this reference count can
    overflow on large servers that declare many field units under the
    same operation_region. This occurs because each field unit declaration
    will add a reference count to the source operation_region.
    
    This change solves the reference count overflow for operation_regions
    objects by preventing fieldunits from incrementing their
    operation_region's reference count. Each operation_region's reference
    count will not be changed by named objects declared under the Field
    operator. During namespace deletion, the operation_region namespace
    node will be deleted and each fieldunit will be deleted without
    touching the deleted operation_region object.
    
    Link: https://github.com/acpica/acpica/commit/e17b28cf
    Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4b718cf04a1f8a70e0ad9f0024087cdd4722d9a
Author: Coly Li <colyli@suse.de>
Date:   Sat Jul 25 20:00:26 2020 +0800

    bcache: fix super block seq numbers comparision in register_cache_set()
    
    [ Upstream commit 117f636ea695270fe492d0c0c9dfadc7a662af47 ]
    
    In register_cache_set(), c is pointer to struct cache_set, and ca is
    pointer to struct cache, if ca->sb.seq > c->sb.seq, it means this
    registering cache has up to date version and other members, the in-
    memory version and other members should be updated to the newer value.
    
    But current implementation makes a cache set only has a single cache
    device, so the above assumption works well except for a special case.
    The execption is when a cache device new created and both ca->sb.seq and
    c->sb.seq are 0, because the super block is never flushed out yet. In
    the location for the following if() check,
    2156         if (ca->sb.seq > c->sb.seq) {
    2157                 c->sb.version           = ca->sb.version;
    2158                 memcpy(c->sb.set_uuid, ca->sb.set_uuid, 16);
    2159                 c->sb.flags             = ca->sb.flags;
    2160                 c->sb.seq               = ca->sb.seq;
    2161                 pr_debug("set version = %llu\n", c->sb.version);
    2162         }
    c->sb.version is not initialized yet and valued 0. When ca->sb.seq is 0,
    the if() check will fail (because both values are 0), and the cache set
    version, set_uuid, flags and seq won't be updated.
    
    The above problem is hiden for current code, because the bucket size is
    compatible among different super block version. And the next time when
    running cache set again, ca->sb.seq will be larger than 0 and cache set
    super block version will be updated properly.
    
    But if the large bucket feature is enabled,  sb->bucket_size is the low
    16bits of the bucket size. For a power of 2 value, when the actual
    bucket size exceeds 16bit width, sb->bucket_size will always be 0. Then
    read_super_common() will fail because the if() check to
    is_power_of_2(sb->bucket_size) is false. This is how the long time
    hidden bug is triggered.
    
    This patch modifies the if() check to the following way,
    2156         if (ca->sb.seq > c->sb.seq || c->sb.seq == 0) {
    Then cache set's version, set_uuid, flags and seq will always be updated
    corectly including for a new created cache device.
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 001499d15b0a8929393821d7e9ecc4a8fad8c190
Author: Jim Cromie <jim.cromie@gmail.com>
Date:   Sun Jul 19 17:10:47 2020 -0600

    dyndbg: fix a BUG_ON in ddebug_describe_flags
    
    [ Upstream commit f678ce8cc3cb2ad29df75d8824c74f36398ba871 ]
    
    ddebug_describe_flags() currently fills a caller provided string buffer,
    after testing its size (also passed) in a BUG_ON.  Fix this by
    replacing them with a known-big-enough string buffer wrapped in a
    struct, and passing that instead.
    
    Also simplify ddebug_describe_flags() flags parameter from a struct to
    a member in that struct, and hoist the member deref up to the caller.
    This makes the function reusable (soon) where flags are unpacked.
    
    Acked-by: <jbaron@akamai.com>
    Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
    Link: https://lore.kernel.org/r/20200719231058.1586423-8-jim.cromie@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd0b60b0524920c29a57df1240a62b3a208360ec
Author: Danesh Petigara <danesh.petigara@broadcom.com>
Date:   Wed Jul 22 13:07:45 2020 -0400

    usb: bdc: Halt controller on suspend
    
    [ Upstream commit 5fc453d7de3d0c345812453823a3a56783c5f82c ]
    
    GISB bus error kernel panics have been observed during S2 transition
    tests on the 7271t platform. The errors are a result of the BDC
    interrupt handler trying to access BDC register space after the
    system's suspend callbacks have completed.
    
    Adding a suspend hook to the BDC driver that halts the controller before
    S2 entry thus preventing unwanted access to the BDC register space during
    this transition.
    
    Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
    Signed-off-by: Al Cooper <alcooperx@gmail.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f4c9d91c1aa088dd73d330e752e8a121ac0c52d
Author: Sasi Kumar <sasi.kumar@broadcom.com>
Date:   Wed Jul 22 13:07:42 2020 -0400

    bdc: Fix bug causing crash after multiple disconnects
    
    [ Upstream commit a95bdfd22076497288868c028619bc5995f5cc7f ]
    
    Multiple connects/disconnects can cause a crash on the second
    disconnect. The driver had a problem where it would try to send
    endpoint commands after it was disconnected which is not allowed
    by the hardware. The fix is to only allow the endpoint commands
    when the endpoint is connected. This will also fix issues that
    showed up when using configfs to create gadgets.
    
    Signed-off-by: Sasi Kumar <sasi.kumar@broadcom.com>
    Signed-off-by: Al Cooper <alcooperx@gmail.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f15121bd7ef35c57558d317123aabffc501d434
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Tue Jul 21 23:15:58 2020 +0300

    usb: gadget: net2280: fix memory leak on probe error handling paths
    
    [ Upstream commit 2468c877da428ebfd701142c4cdfefcfb7d4c00e ]
    
    Driver does not release memory for device on error handling paths in
    net2280_probe() when gadget_release() is not registered yet.
    
    The patch fixes the bug like in other similar drivers.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47298eebd502c9b6651a23d72c80384b4de9e99f
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Mon Jun 29 06:18:41 2020 +0300

    gpu: host1x: debug: Fix multiple channels emitting messages simultaneously
    
    [ Upstream commit 35681862808472a0a4b9a8817ae2789c0b5b3edc ]
    
    Once channel's job is hung, it dumps the channel's state into KMSG before
    tearing down the offending job. If multiple channels hang at once, then
    they dump messages simultaneously, making the debug info unreadable, and
    thus, useless. This patch adds mutex which allows only one channel to emit
    debug messages at a time.
    
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eaa75754757e352a5121f5dfca5fa5be5376b3cb
Author: Bolarinwa Olayemi Saheed <refactormyself@gmail.com>
Date:   Mon Jul 13 19:55:27 2020 +0200

    iwlegacy: Check the return value of pcie_capability_read_*()
    
    [ Upstream commit 9018fd7f2a73e9b290f48a56b421558fa31e8b75 ]
    
    On failure pcie_capability_read_dword() sets it's last parameter, val
    to 0. However, with Patch 14/14, it is possible that val is set to ~0 on
    failure. This would introduce a bug because (x & x) == (~0 & x).
    
    This bug can be avoided without changing the function's behaviour if the
    return value of pcie_capability_read_dword is checked to confirm success.
    
    Check the return value of pcie_capability_read_dword() to ensure success.
    
    Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
    Signed-off-by: Bolarinwa Olayemi Saheed <refactormyself@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200713175529.29715-3-refactormyself@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccf28790086cd6b27e33d02f1f185572fa89c07b
Author: Wright Feng <wright.feng@cypress.com>
Date:   Wed Jun 24 04:16:07 2020 -0500

    brcmfmac: set state of hanger slot to FREE when flushing PSQ
    
    [ Upstream commit fcdd7a875def793c38d7369633af3eba6c7cf089 ]
    
    When USB or SDIO device got abnormal bus disconnection, host driver
    tried to clean up the skbs in PSQ and TXQ (The skb's pointer in hanger
    slot linked to PSQ and TSQ), so we should set the state of skb hanger slot
    to BRCMF_FWS_HANGER_ITEM_STATE_FREE before freeing skb.
    In brcmf_fws_bus_txq_cleanup it already sets
    BRCMF_FWS_HANGER_ITEM_STATE_FREE before freeing skb, therefore we add the
    same thing in brcmf_fws_psq_flush to avoid following warning message.
    
       [ 1580.012880] ------------   [ cut here ]------------
       [ 1580.017550] WARNING: CPU: 3 PID: 3065 at
    drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49
    brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil]
       [ 1580.184017] Call Trace:
       [ 1580.186514]  brcmf_fws_cleanup+0x14e/0x190 [brcmfmac]
       [ 1580.191594]  brcmf_fws_del_interface+0x70/0x90 [brcmfmac]
       [ 1580.197029]  brcmf_proto_bcdc_del_if+0xe/0x10 [brcmfmac]
       [ 1580.202418]  brcmf_remove_interface+0x69/0x190 [brcmfmac]
       [ 1580.207888]  brcmf_detach+0x90/0xe0 [brcmfmac]
       [ 1580.212385]  brcmf_usb_disconnect+0x76/0xb0 [brcmfmac]
       [ 1580.217557]  usb_unbind_interface+0x72/0x260
       [ 1580.221857]  device_release_driver_internal+0x141/0x200
       [ 1580.227152]  device_release_driver+0x12/0x20
       [ 1580.231460]  bus_remove_device+0xfd/0x170
       [ 1580.235504]  device_del+0x1d9/0x300
       [ 1580.239041]  usb_disable_device+0x9e/0x270
       [ 1580.243160]  usb_disconnect+0x94/0x270
       [ 1580.246980]  hub_event+0x76d/0x13b0
       [ 1580.250499]  process_one_work+0x144/0x360
       [ 1580.254564]  worker_thread+0x4d/0x3c0
       [ 1580.258247]  kthread+0x109/0x140
       [ 1580.261515]  ? rescuer_thread+0x340/0x340
       [ 1580.265543]  ? kthread_park+0x60/0x60
       [ 1580.269237]  ? SyS_exit_group+0x14/0x20
       [ 1580.273118]  ret_from_fork+0x25/0x30
       [ 1580.300446] ------------   [ cut here ]------------
    
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Wright Feng <wright.feng@cypress.com>
    Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200624091608.25154-2-wright.feng@cypress.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 688c077b341e953df008ce7105df2172bcd661c4
Author: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com>
Date:   Thu Jun 4 02:18:35 2020 -0500

    brcmfmac: To fix Bss Info flag definition Bug
    
    [ Upstream commit fa3266541b13f390eb35bdbc38ff4a03368be004 ]
    
    Bss info flag definition need to be fixed from 0x2 to 0x4
    This flag is for rssi info received on channel.
    All Firmware branches defined as 0x4 and this is bug in brcmfmac.
    
    Signed-off-by: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com>
    Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
    Signed-off-by: Wright Feng <wright.feng@cypress.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200604071835.3842-6-wright.feng@cypress.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c93552d3a243f755306683c89eae404f5ae3e210
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Thu Apr 16 16:46:10 2020 -0700

    mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls
    
    [ Upstream commit 0a3b3c253a1eb2c7fe7f34086d46660c909abeb3 ]
    
    A large process running on a heavily loaded system can encounter the
    following RCU CPU stall warning:
    
      rcu: INFO: rcu_sched self-detected stall on CPU
      rcu:  3-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190
            (t=21013 jiffies g=1005461 q=132576)
      NMI backtrace for cpu 3
      CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1
      Hardware name: Wiwynn   HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016
      Call Trace:
       <IRQ>
       dump_stack+0x46/0x60
       nmi_cpu_backtrace.cold.3+0x13/0x50
       ? lapic_can_unplug_cpu.cold.27+0x34/0x34
       nmi_trigger_cpumask_backtrace+0xba/0xca
       rcu_dump_cpu_stacks+0x99/0xc7
       rcu_sched_clock_irq.cold.87+0x1aa/0x397
       ? tick_sched_do_timer+0x60/0x60
       update_process_times+0x28/0x60
       tick_sched_timer+0x37/0x70
       __hrtimer_run_queues+0xfe/0x270
       hrtimer_interrupt+0xf4/0x210
       smp_apic_timer_interrupt+0x5e/0x120
       apic_timer_interrupt+0xf/0x20
       </IRQ>
      RIP: 0010:kmem_cache_free+0x223/0x300
      Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65
      RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
      RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030
      RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18
      RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff
      R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f
      R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00
       ? remove_vma+0x4f/0x60
       remove_vma+0x4f/0x60
       exit_mmap+0xd6/0x160
       mmput+0x4a/0x110
       do_exit+0x278/0xae0
       ? syscall_trace_enter+0x1d3/0x2b0
       ? handle_mm_fault+0xaa/0x1c0
       do_group_exit+0x3a/0xa0
       __x64_sys_exit_group+0x14/0x20
       do_syscall_64+0x42/0x100
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run
    for a very long time given a large process.  This commit therefore adds
    a cond_resched() to this loop, providing RCU any needed quiescent states.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: <linux-mm@kvack.org>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7987153ab716d2e87dd694926c486c55313c8b3
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Mon Jun 15 09:44:45 2020 +0200

    irqchip/irq-mtk-sysirq: Replace spinlock with raw_spinlock
    
    [ Upstream commit 6eeb997ab5075e770a002c51351fa4ec2c6b5c39 ]
    
    This driver may take a regular spinlock when a raw spinlock
    (irq_desc->lock) is already taken which results in the following
    lockdep splat:
    
    =============================
    [ BUG: Invalid wait context ]
    5.7.0-rc7 #1 Not tainted
    -----------------------------
    swapper/0/0 is trying to lock:
    ffffff800303b798 (&chip_data->lock){....}-{3:3}, at: mtk_sysirq_set_type+0x48/0xc0
    other info that might help us debug this:
    context-{5:5}
    2 locks held by swapper/0/0:
     #0: ffffff800302ee68 (&desc->request_mutex){....}-{4:4}, at: __setup_irq+0xc4/0x8a0
     #1: ffffff800302ecf0 (&irq_desc_lock_class){....}-{2:2}, at: __setup_irq+0xe4/0x8a0
    stack backtrace:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7 #1
    Hardware name: Pumpkin MT8516 (DT)
    Call trace:
     dump_backtrace+0x0/0x180
     show_stack+0x14/0x20
     dump_stack+0xd0/0x118
     __lock_acquire+0x8c8/0x2270
     lock_acquire+0xf8/0x470
     _raw_spin_lock_irqsave+0x50/0x78
     mtk_sysirq_set_type+0x48/0xc0
     __irq_set_trigger+0x58/0x170
     __setup_irq+0x420/0x8a0
     request_threaded_irq+0xd8/0x190
     timer_of_init+0x1e8/0x2c4
     mtk_gpt_init+0x5c/0x1dc
     timer_probe+0x74/0xf4
     time_init+0x14/0x44
     start_kernel+0x394/0x4f0
    
    Replace the spinlock_t with raw_spinlock_t to avoid this warning.
    
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20200615074445.3579-1-brgl@bgdev.pl
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf8d94475a83bf5727aeaeae3b7338462c400ed5
Author: Michael Tretter <m.tretter@pengutronix.de>
Date:   Thu Aug 17 12:43:07 2017 +0200

    drm/debugfs: fix plain echo to connector "force" attribute
    
    [ Upstream commit c704b17071c4dc571dca3af4e4151dac51de081a ]
    
    Using plain echo to set the "force" connector attribute fails with
    -EINVAL, because echo appends a newline to the output.
    
    Replace strcmp with sysfs_streq to also accept strings that end with a
    newline.
    
    v2: use sysfs_streq instead of stripping trailing whitespace
    
    Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170817104307.17124-1-m.tretter@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42479de3daeae1728b3b2d2baef218f109e37361
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 20:41:56 2020 -0500

    drm/nouveau: fix multiple instances of reference count leaks
    
    [ Upstream commit 659fb5f154c3434c90a34586f3b7aa1c39cf6062 ]
    
    On calling pm_runtime_get_sync() the reference count of the device
    is incremented. In case of failure, decrement the
    ref count before returning the error.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 970673cb2e0aaae710528babd1d2783175f4b884
Author: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Date:   Mon Jun 1 08:33:06 2020 +0200

    arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding
    
    [ Upstream commit bbe28fc3cbabbef781bcdf847615d52ce2e26e42 ]
    
    hi3660-hikey960.dts:
      Define a 'ports' node for 'adv7533: adv7533@39' and the
      'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
      binding.
    
      This fills the requirements to meet the binding requirements,
      remote endpoints are not defined.
    
    hi6220-hikey.dts:
      Change property name s/pd-gpio/pd-gpios, gpio properties should be
      plural. This is just a cosmetic change.
    
    Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9b1fa1e361c29e386a02f4be0af46303fca1b60
Author: Zhao Heming <heming.zhao@suse.com>
Date:   Thu Jul 9 11:29:29 2020 +0800

    md-cluster: fix wild pointer of unlock_all_bitmaps()
    
    [ Upstream commit 60f80d6f2d07a6d8aee485a1d1252327eeee0c81 ]
    
    reproduction steps:
    ```
    node1 # mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda
    /dev/sdb
    node2 # mdadm -A /dev/md0 /dev/sda /dev/sdb
    node1 # mdadm -G /dev/md0 -b none
    mdadm: failed to remove clustered bitmap.
    node1 # mdadm -S --scan
    ^C  <==== mdadm hung & kernel crash
    ```
    
    kernel stack:
    ```
    [  335.230657] general protection fault: 0000 [#1] SMP NOPTI
    [...]
    [  335.230848] Call Trace:
    [  335.230873]  ? unlock_all_bitmaps+0x5/0x70 [md_cluster]
    [  335.230886]  unlock_all_bitmaps+0x3d/0x70 [md_cluster]
    [  335.230899]  leave+0x10f/0x190 [md_cluster]
    [  335.230932]  ? md_super_wait+0x93/0xa0 [md_mod]
    [  335.230947]  ? leave+0x5/0x190 [md_cluster]
    [  335.230973]  md_cluster_stop+0x1a/0x30 [md_mod]
    [  335.230999]  md_bitmap_free+0x142/0x150 [md_mod]
    [  335.231013]  ? _cond_resched+0x15/0x40
    [  335.231025]  ? mutex_lock+0xe/0x30
    [  335.231056]  __md_stop+0x1c/0xa0 [md_mod]
    [  335.231083]  do_md_stop+0x160/0x580 [md_mod]
    [  335.231119]  ? 0xffffffffc05fb078
    [  335.231148]  md_ioctl+0xa04/0x1930 [md_mod]
    [  335.231165]  ? filename_lookup+0xf2/0x190
    [  335.231179]  blkdev_ioctl+0x93c/0xa10
    [  335.231205]  ? _cond_resched+0x15/0x40
    [  335.231214]  ? __check_object_size+0xd4/0x1a0
    [  335.231224]  block_ioctl+0x39/0x40
    [  335.231243]  do_vfs_ioctl+0xa0/0x680
    [  335.231253]  ksys_ioctl+0x70/0x80
    [  335.231261]  __x64_sys_ioctl+0x16/0x20
    [  335.231271]  do_syscall_64+0x65/0x1f0
    [  335.231278]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    ```
    
    Signed-off-by: Zhao Heming <heming.zhao@suse.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 471005a0e1df13e3aea6d58c7c405eb28cc0daff
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Tue Jun 30 22:54:51 2020 +0300

    video: fbdev: neofb: fix memory leak in neo_scan_monitor()
    
    [ Upstream commit edcb3895a751c762a18d25c8d9846ce9759ed7e1 ]
    
    neofb_probe() calls neo_scan_monitor() that can successfully allocate a
    memory for info->monspecs.modedb and proceed to case 0x03. There it does
    not free the memory and returns -1. neofb_probe() goes to label
    err_scan_monitor, thus, it does not free this memory through calling
    fb_destroy_modedb() as well. We can not go to label err_init_hw since
    neo_scan_monitor() can fail during memory allocation. So, the patch frees
    the memory directly for case 0x03.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200630195451.18675-1-novikov@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dec0847921c5c9b1ad8fe9bd3fa4ef93f95860e2
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 21:21:22 2020 -0500

    drm/radeon: Fix reference count leaks caused by pm_runtime_get_sync
    
    [ Upstream commit 9fb10671011143d15b6b40d6d5fa9c52c57e9d63 ]
    
    On calling pm_runtime_get_sync() the reference count of the device
    is incremented. In case of failure, decrement the
    reference count before returning the error.
    
    Acked-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad372ce97bf08929af5b174d0329450de0021c32
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Fri May 8 14:15:37 2020 -0700

    fs/btrfs: Add cond_resched() for try_release_extent_mapping() stalls
    
    [ Upstream commit 9f47eb5461aaeb6cb8696f9d11503ae90e4d5cb0 ]
    
    Very large I/Os can cause the following RCU CPU stall warning:
    
    RIP: 0010:rb_prev+0x8/0x50
    Code: 49 89 c0 49 89 d1 48 89 c2 48 89 f8 e9 e5 fd ff ff 4c 89 48 10 c3 4c =
    89 06 c3 4c 89 40 10 c3 0f 1f 00 48 8b 0f 48 39 cf 74 38 <48> 8b 47 10 48 85 c0 74 22 48 8b 50 08 48 85 d2 74 0c 48 89 d0 48
    RSP: 0018:ffffc9002212bab0 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff13
    RAX: ffff888821f93630 RBX: ffff888821f93630 RCX: ffff888821f937e0
    RDX: 0000000000000000 RSI: 0000000000102000 RDI: ffff888821f93630
    RBP: 0000000000103000 R08: 000000000006c000 R09: 0000000000000238
    R10: 0000000000102fff R11: ffffc9002212bac8 R12: 0000000000000001
    R13: ffffffffffffffff R14: 0000000000102000 R15: ffff888821f937e0
     __lookup_extent_mapping+0xa0/0x110
     try_release_extent_mapping+0xdc/0x220
     btrfs_releasepage+0x45/0x70
     shrink_page_list+0xa39/0xb30
     shrink_inactive_list+0x18f/0x3b0
     shrink_lruvec+0x38e/0x6b0
     shrink_node+0x14d/0x690
     do_try_to_free_pages+0xc6/0x3e0
     try_to_free_mem_cgroup_pages+0xe6/0x1e0
     reclaim_high.constprop.73+0x87/0xc0
     mem_cgroup_handle_over_high+0x66/0x150
     exit_to_usermode_loop+0x82/0xd0
     do_syscall_64+0xd4/0x100
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    On a PREEMPT=n kernel, the try_release_extent_mapping() function's
    "while" loop might run for a very long time on a large I/O.  This commit
    therefore adds a cond_resched() to this loop, providing RCU any needed
    quiescent states.
    
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af7122cfbaeef4a854a242b43fa2fa5bb9e4eac9
Author: Lihong Kou <koulihong@huawei.com>
Date:   Tue Jun 23 20:28:41 2020 +0800

    Bluetooth: add a mutex lock to avoid UAF in do_enale_set
    
    [ Upstream commit f9c70bdc279b191da8d60777c627702c06e4a37d ]
    
    In the case we set or free the global value listen_chan in
    different threads, we can encounter the UAF problems because
    the method is not protected by any lock, add one to avoid
    this bug.
    
    BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990
    net/bluetooth/l2cap_core.c:730
    Read of size 8 at addr ffff888096950000 by task kworker/1:102/2868
    
    CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 01/01/2011
    Workqueue: events do_enable_set
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1fb/0x318 lib/dump_stack.c:118
     print_address_description+0x74/0x5c0 mm/kasan/report.c:374
     __kasan_report+0x149/0x1c0 mm/kasan/report.c:506
     kasan_report+0x26/0x50 mm/kasan/common.c:641
     __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
     l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730
     do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074
     process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
     worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
     kthread+0x332/0x350 kernel/kthread.c:255
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    
    Allocated by task 2870:
     save_stack mm/kasan/common.c:72 [inline]
     set_track mm/kasan/common.c:80 [inline]
     __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515
     kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
     kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551
     kmalloc include/linux/slab.h:555 [inline]
     kzalloc include/linux/slab.h:669 [inline]
     l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446
     chan_create net/bluetooth/6lowpan.c:640 [inline]
     bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline]
     do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078
     process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
     worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
     kthread+0x332/0x350 kernel/kthread.c:255
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    
    Freed by task 2870:
     save_stack mm/kasan/common.c:72 [inline]
     set_track mm/kasan/common.c:80 [inline]
     kasan_set_free_info mm/kasan/common.c:337 [inline]
     __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476
     kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
     __cache_free mm/slab.c:3426 [inline]
     kfree+0x10d/0x220 mm/slab.c:3757
     l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline]
     kref_put include/linux/kref.h:65 [inline]
     l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498
     do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075
     process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
     worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
     kthread+0x332/0x350 kernel/kthread.c:255
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    
    The buggy address belongs to the object at ffff888096950000
     which belongs to the cache kmalloc-2k of size 2048
    The buggy address is located 0 bytes inside of
     2048-byte region [ffff888096950000, ffff888096950800)
    The buggy address belongs to the page:
    page:ffffea00025a5400 refcount:1 mapcount:0 mapping:ffff8880aa400e00 index:0x0
    flags: 0xfffe0000000200(slab)
    raw: 00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00
    raw: 0000000000000000 ffff888096950000 0000000100000001 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com
    Signed-off-by: Lihong Kou <koulihong@huawei.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fa182ef2356ebc0f331d724bf5b84a0a22bbb9a
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Wed Apr 29 13:42:32 2020 +0300

    drm/tilcdc: fix leak & null ref in panel_connector_get_modes
    
    [ Upstream commit 3f9c1c872cc97875ddc8d63bc9fe6ee13652b933 ]
    
    If videomode_from_timings() returns true, the mode allocated with
    drm_mode_create will be leaked.
    
    Also, the return value of drm_mode_create() is never checked, and thus
    could cause NULL deref.
    
    Fix these two issues.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-1-tomi.valkeinen@ti.com
    Reviewed-by: Jyri Sarha <jsarha@ti.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02f10f560590a8140df0a0a572afff3c9766e8fd
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Jul 21 21:45:51 2020 +0800

    ARM: socfpga: PM: add missing put_device() call in socfpga_setup_ocram_self_refresh()
    
    [ Upstream commit 3ad7b4e8f89d6bcc9887ca701cf2745a6aedb1a0 ]
    
    if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh
    doesn't have a corresponding put_device(). Thus add a jump target to
    fix the exception handling for this function implementation.
    
    Fixes: 44fd8c7d4005 ("ARM: socfpga: support suspend to ram")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6f0a1ae40359e01a756065fe3046d3e5fff4e92
Author: Dilip Kota <eswara.kota@linux.intel.com>
Date:   Fri Jul 17 14:27:50 2020 +0800

    spi: lantiq: fix: Rx overflow error in full duplex mode
    
    [ Upstream commit 661ccf2b3f1360be50242726f7c26ced6a9e7d52 ]
    
    In full duplex mode, rx overflow error is observed. To overcome the error,
    wait until the complete data got received and proceed further.
    
    Fixes: 17f84b793c01 ("spi: lantiq-ssc: add support for Lantiq SSC SPI controller")
    Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com>
    Link: https://lore.kernel.org/r/efb650b0faa49a00788c4e0ca8ef7196bdba851d.1594957019.git.eswara.kota@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce5a8ad3ad9ecab4544f8352d5a7953321a6ec7e
Author: yu kuai <yukuai3@huawei.com>
Date:   Thu Jun 4 20:33:01 2020 +0800

    ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()
    
    [ Upstream commit f87a4f022c44e5b87e842a9f3e644fba87e8385f ]
    
    if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have
    a corresponding put_device(). Thus add a jump target to fix the exception
    handling for this function implementation.
    
    Fixes: d2e467905596 ("ARM: at91: pm: use the mmio-sram pool to access SRAM")
    Signed-off-by: yu kuai <yukuai3@huawei.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20200604123301.3905837-1-yukuai3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93753a2ccedd2a5191e22eddccab56b04255f0a1
Author: Lu Wei <luwei32@huawei.com>
Date:   Fri Jul 10 17:30:18 2020 +0800

    platform/x86: intel-vbtn: Fix return value check in check_acpi_dev()
    
    [ Upstream commit 64dd4a5a7d214a07e3d9f40227ec30ac8ba8796e ]
    
    In the function check_acpi_dev(), if it fails to create
    platform device, the return value is ERR_PTR() or NULL.
    Thus it must use IS_ERR_OR_NULL() to check return value.
    
    Fixes: 332e081225fc ("intel-vbtn: new driver for Intel Virtual Button")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Lu Wei <luwei32@huawei.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1593a21976f59d832618517b64fe68bdb65eedb6
Author: Lu Wei <luwei32@huawei.com>
Date:   Fri Jul 10 17:30:17 2020 +0800

    platform/x86: intel-hid: Fix return value check in check_acpi_dev()
    
    [ Upstream commit 71fbe886ce6dd0be17f20aded9c63fe58edd2806 ]
    
    In the function check_acpi_dev(), if it fails to create
    platform device, the return value is ERR_PTR() or NULL.
    Thus it must use IS_ERR_OR_NULL() to check return value.
    
    Fixes: ecc83e52b28c ("intel-hid: new hid event driver for hotkeys")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Lu Wei <luwei32@huawei.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06681b8e26c6f03bc7869ac1aedda08ac525f6e3
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Sun May 31 09:12:13 2020 +1000

    m68k: mac: Fix IOP status/control register writes
    
    [ Upstream commit 931fc82a6aaf4e2e4a5490addaa6a090d78c24a7 ]
    
    When writing values to the IOP status/control register make sure those
    values do not have any extraneous bits that will clear interrupt flags.
    
    To place the SCC IOP into bypass mode would be desirable but this is not
    achieved by writing IOP_DMAINACTIVE | IOP_RUN | IOP_AUTOINC | IOP_BYPASS
    to the control register. Drop this ineffective register write.
    
    Remove the flawed and unused iop_bypass() function. Make use of the
    unused iop_stop() function.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Cc: Joshua Thompson <funaho@jurai.org>
    Link: https://lore.kernel.org/r/09bcb7359a1719a18b551ee515da3c4c3cf709e6.1590880333.git.fthain@telegraphics.com.au
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 275ae397e4ef7474d45075813b4383a736443d7e
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Sun May 31 09:12:13 2020 +1000

    m68k: mac: Don't send IOP message until channel is idle
    
    [ Upstream commit aeb445bf2194d83e12e85bf5c65baaf1f093bd8f ]
    
    In the following sequence of calls, iop_do_send() gets called when the
    "send" channel is not in the IOP_MSG_IDLE state:
    
            iop_ism_irq()
                    iop_handle_send()
                            (msg->handler)()
                                    iop_send_message()
                            iop_do_send()
    
    Avoid this by testing the channel state before calling iop_do_send().
    
    When sending, and iop_send_queue is empty, call iop_do_send() because
    the channel is idle. If iop_send_queue is not empty, iop_do_send() will
    get called later by iop_handle_send().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Cc: Joshua Thompson <funaho@jurai.org>
    Link: https://lore.kernel.org/r/6d667c39e53865661fa5a48f16829d18ed8abe54.1590880333.git.fthain@telegraphics.com.au
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed03eb0021b73fc7f4067da3cb71d625bbd75967
Author: Alim Akhtar <alim.akhtar@samsung.com>
Date:   Sun Jul 5 12:39:17 2020 +0530

    arm64: dts: exynos: Fix silent hang after boot on Espresso
    
    [ Upstream commit b072714bfc0e42c984b8fd6e069f3ca17de8137a ]
    
    Once regulators are disabled after kernel boot, on Espresso board silent
    hang observed because of LDO7 being disabled.  LDO7 actually provide
    power to CPU cores and non-cpu blocks circuitries.  Keep this regulator
    always-on to fix this hang.
    
    Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso")
    Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e672bd32482130379ce34dbc4c2af41924762d0
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Fri Jun 5 20:59:14 2020 +0200

    arm64: dts: qcom: msm8916: Replace invalid bias-pull-none property
    
    [ Upstream commit 1b6a1a162defe649c5599d661b58ac64bb6f31b6 ]
    
    msm8916-pins.dtsi specifies "bias-pull-none" for most of the audio
    pin configurations. This was likely copied from the qcom kernel fork
    where the same property was used for these audio pins.
    
    However, "bias-pull-none" actually does not exist at all - not in
    mainline and not in downstream. I can only guess that the original
    intention was to configure "no pull", i.e. bias-disable.
    
    Change it to that instead.
    
    Fixes: 143bb9ad85b7 ("arm64: dts: qcom: add audio pinctrls")
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20200605185916.318494-2-stephan@gerhold.net
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46f7ec5fe967f8cb8e5ce479fa23e5476bbee2c1
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Thu May 28 15:22:37 2020 -0500

    EDAC: Fix reference count leaks
    
    [ Upstream commit 17ed808ad243192fb923e4e653c1338d3ba06207 ]
    
    When kobject_init_and_add() returns an error, it should be handled
    because kobject_init_and_add() takes a 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.
    
    Therefore, replace calling kfree() and call kobject_put() and add a
    missing kobject_put() in the edac_device_register_sysfs_main_kobj()
    error path.
    
     [ bp: Massage and merge into a single patch. ]
    
    Fixes: b2ed215a3338 ("Kobject: change drivers/edac to use kobject_init_and_add")
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20200528202238.18078-1-wu000273@umn.edu
    Link: https://lkml.kernel.org/r/20200528203526.20908-1-wu000273@umn.edu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59b5331268406b08016e6b58d89bae30042d844e
Author: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Date:   Wed Jun 3 15:28:36 2020 +0200

    arm64: dts: rockchip: fix rk3399-puma gmac reset gpio
    
    [ Upstream commit 8a445086f8af0b7b9bd8d1901d6f306bb154f70d ]
    
    The puma gmac node currently uses opposite active-values for the
    gmac phy reset pin. The gpio-declaration uses active-high while the
    separate snps,reset-active-low property marks the pin as active low.
    
    While on the kernel side this works ok, other DT users may get
    confused - as seen with uboot right now.
    
    So bring this in line and make both properties match, similar to the
    other Rockchip board.
    
    Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
    Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20200603132836.362519-1-heiko@sntech.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e97bf96656e126a60451613e0b44474ad7e08327
Author: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Date:   Thu Jun 4 11:12:39 2020 +0200

    arm64: dts: rockchip: fix rk3399-puma vcc5v0-host gpio
    
    [ Upstream commit 7a7184f6cfa9279f1a1c10a1845d247d7fad54ff ]
    
    The puma vcc5v0_host regulator node currently uses opposite active-values
    for the enable pin. The gpio-declaration uses active-high while the
    separate enable-active-low property marks the pin as active low.
    
    While on the kernel side this works ok, other DT users may get
    confused - as seen with uboot right now.
    
    So bring this in line and make both properties match, similar to the
    gmac fix.
    
    Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
    Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20200604091239.424318-1-heiko@sntech.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a51095df01d344ea85c7eb7d10a2f8f660542e80
Author: Peng Liu <iwtbavbm@gmail.com>
Date:   Tue Jun 9 23:09:36 2020 +0800

    sched: correct SD_flags returned by tl->sd_flags()
    
    [ Upstream commit 9b1b234bb86bcdcdb142e900d39b599185465dbb ]
    
    During sched domain init, we check whether non-topological SD_flags are
    returned by tl->sd_flags(), if found, fire a waning and correct the
    violation, but the code failed to correct the violation. Correct this.
    
    Fixes: 143e1e28cb40 ("sched: Rework sched_domain topology definition")
    Signed-off-by: Peng Liu <iwtbavbm@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Link: https://lkml.kernel.org/r/20200609150936.GA13060@iZj6chx1xj0e0buvshuecpZ
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7fcad6aebb04a013270e9d2b34e1ad2cd99e8f9
Author: Zhenzhong Duan <zhenzhong.duan@gmail.com>
Date:   Thu Jun 11 10:32:38 2020 +0800

    x86/mce/inject: Fix a wrong assignment of i_mce.status
    
    [ Upstream commit 5d7f7d1d5e01c22894dee7c9c9266500478dca99 ]
    
    The original code is a nop as i_mce.status is or'ed with part of itself,
    fix it.
    
    Fixes: a1300e505297 ("x86/ras/mce_amd_inj: Trigger deferred and thresholding errors interrupts")
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Link: https://lkml.kernel.org/r/20200611023238.3830-1-zhenzhong.duan@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bfba2f4270c64c912756fc76621bbce959ddf2e
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Aug 13 20:29:16 2020 +0000

    cgroup: add missing skcd->no_refcnt check in cgroup_sk_clone()
    
    Add skcd->no_refcnt check which is missed when backporting
    ad0f75e5f57c ("cgroup: fix cgroup_sk_alloc() for sk_clone_lock()").
    
    This patch is needed in stable-4.9, stable-4.14 and stable-4.19.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d5fdf1588074054c4a50213148cbcd35946a1c9
Author: Grant Likely <grant.likely@secretlab.ca>
Date:   Fri Jul 10 16:19:39 2020 +0100

    HID: input: Fix devices that return multiple bytes in battery report
    
    commit 4f57cace81438cc873a96f9f13f08298815c9b51 upstream.
    
    Some devices, particularly the 3DConnexion Spacemouse wireless 3D
    controllers, return more than just the battery capacity in the battery
    report. The Spacemouse devices return an additional byte with a device
    specific field. However, hidinput_query_battery_capacity() only
    requests a 2 byte transfer.
    
    When a spacemouse is connected via USB (direct wire, no wireless dongle)
    and it returns a 3 byte report instead of the assumed 2 byte battery
    report the larger transfer confuses and frightens the USB subsystem
    which chooses to ignore the transfer. Then after 2 seconds assume the
    device has stopped responding and reset it. This can be reproduced
    easily by using a wired connection with a wireless spacemouse. The
    Spacemouse will enter a loop of resetting every 2 seconds which can be
    observed in dmesg.
    
    This patch solves the problem by increasing the transfer request to 4
    bytes instead of 2. The fix isn't particularly elegant, but it is simple
    and safe to backport to stable kernels. A further patch will follow to
    more elegantly handle battery reports that contain additional data.
    
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Cc: Darren Hart <darren@dvhart.com>
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Cc: stable@vger.kernel.org
    Tested-by: Darren Hart <dvhart@infradead.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25dfa86fe24396cc4b198228735b4a0e13f9a769
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Thu Jul 30 15:45:54 2020 -0700

    tracepoint: Mark __tracepoint_string's __used
    
    commit f3751ad0116fb6881f2c3c957d66a9327f69cefb upstream.
    
    __tracepoint_string's have their string data stored in .rodata, and an
    address to that data stored in the "__tracepoint_str" section. Functions
    that refer to those strings refer to the symbol of the address. Compiler
    optimization can replace those address references with references
    directly to the string data. If the address doesn't appear to have other
    uses, then it appears dead to the compiler and is removed. This can
    break the /tracing/printk_formats sysfs node which iterates the
    addresses stored in the "__tracepoint_str" section.
    
    Like other strings stored in custom sections in this header, mark these
    __used to inform the compiler that there are other non-obvious users of
    the address, so they should still be emitted.
    
    Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Cc: stable@vger.kernel.org
    Fixes: 102c9323c35a8 ("tracing: Add __tracepoint_string() to export string pointers")
    Reported-by: Tim Murray <timmurray@google.com>
    Reported-by: Simon MacMullen <simonmacm@google.com>
    Suggested-by: Greg Hackmann <ghackmann@google.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a963ddc8fffada154a87ca407fdfc850618ba49b
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jul 8 13:15:20 2020 -0700

    Smack: fix use-after-free in smk_write_relabel_self()
    
    commit beb4ee6770a89646659e6a2178538d2b13e2654e upstream.
    
    smk_write_relabel_self() frees memory from the task's credentials with
    no locking, which can easily cause a use-after-free because multiple
    tasks can share the same credentials structure.
    
    Fix this by using prepare_creds() and commit_creds() to correctly modify
    the task's credentials.
    
    Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self":
    
            #include <fcntl.h>
            #include <pthread.h>
            #include <unistd.h>
    
            static void *thrproc(void *arg)
            {
                    int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY);
                    for (;;) write(fd, "foo", 3);
            }
    
            int main()
            {
                    pthread_t t;
                    pthread_create(&t, NULL, thrproc, NULL);
                    thrproc(NULL);
            }
    
    Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com
    Fixes: 38416e53936e ("Smack: limited capability for changing process label")
    Cc: <stable@vger.kernel.org> # v4.4+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aa01b947c3ac40fc62c97a7f53b45a503a6d91b
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jul 29 00:03:56 2020 +0100

    rxrpc: Fix race between recvmsg and sendmsg on immediate call failure
    
    [ Upstream commit 65550098c1c4db528400c73acf3e46bfa78d9264 ]
    
    There's a race between rxrpc_sendmsg setting up a call, but then failing to
    send anything on it due to an error, and recvmsg() seeing the call
    completion occur and trying to return the state to the user.
    
    An assertion fails in rxrpc_recvmsg() because the call has already been
    released from the socket and is about to be released again as recvmsg deals
    with it.  (The recvmsg_q queue on the socket holds a ref, so there's no
    problem with use-after-free.)
    
    We also have to be careful not to end up reporting an error twice, in such
    a way that both returns indicate to userspace that the user ID supplied
    with the call is no longer in use - which could cause the client to
    malfunction if it recycles the user ID fast enough.
    
    Fix this by the following means:
    
     (1) When sendmsg() creates a call after the point that the call has been
         successfully added to the socket, don't return any errors through
         sendmsg(), but rather complete the call and let recvmsg() retrieve
         them.  Make sendmsg() return 0 at this point.  Further calls to
         sendmsg() for that call will fail with ESHUTDOWN.
    
         Note that at this point, we haven't send any packets yet, so the
         server doesn't yet know about the call.
    
     (2) If sendmsg() returns an error when it was expected to create a new
         call, it means that the user ID wasn't used.
    
     (3) Mark the call disconnected before marking it completed to prevent an
         oops in rxrpc_release_call().
    
     (4) recvmsg() will then retrieve the error and set MSG_EOR to indicate
         that the user ID is no longer known by the kernel.
    
    An oops like the following is produced:
    
            kernel BUG at net/rxrpc/recvmsg.c:605!
            ...
            RIP: 0010:rxrpc_recvmsg+0x256/0x5ae
            ...
            Call Trace:
             ? __init_waitqueue_head+0x2f/0x2f
             ____sys_recvmsg+0x8a/0x148
             ? import_iovec+0x69/0x9c
             ? copy_msghdr_from_user+0x5c/0x86
             ___sys_recvmsg+0x72/0xaa
             ? __fget_files+0x22/0x57
             ? __fget_light+0x46/0x51
             ? fdget+0x9/0x1b
             do_recvmmsg+0x15e/0x232
             ? _raw_spin_unlock+0xa/0xb
             ? vtime_delta+0xf/0x25
             __x64_sys_recvmmsg+0x2c/0x2f
             do_syscall_64+0x4c/0x78
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 357f5ef64628 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()")
    Reported-by: syzbot+b54969381df354936d96@syzkaller.appspotmail.com
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 226422a2bfff136455297792bea62470a4f0855c
Author: Rustam Kovhaev <rkovhaev@gmail.com>
Date:   Mon Jul 27 23:42:17 2020 -0700

    usb: hso: check for return value in hso_serial_common_create()
    
    [ Upstream commit e911e99a0770f760377c263bc7bac1b1593c6147 ]
    
    in case of an error tty_register_device_attr() returns ERR_PTR(),
    add IS_ERR() check
    
    Reported-and-tested-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321e
    Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5200f946ca1fe164bde8cadd1a170a728e9ae190
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Aug 5 04:40:45 2020 -0400

    selftests/net: relax cpu affinity requirement in msg_zerocopy test
    
    [ Upstream commit 16f6458f2478b55e2b628797bc81a4455045c74e ]
    
    The msg_zerocopy test pins the sender and receiver threads to separate
    cores to reduce variance between runs.
    
    But it hardcodes the cores and skips core 0, so it fails on machines
    with the selected cores offline, or simply fewer cores.
    
    The test mainly gives code coverage in automated runs. The throughput
    of zerocopy ('-z') and non-zerocopy runs is logged for manual
    inspection.
    
    Continue even when sched_setaffinity fails. Just log to warn anyone
    interpreting the data.
    
    Fixes: 07b65c5b31ce ("test: add msg_zerocopy test")
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cbdf39a899a8028b9cedc13f65c0570ce44479c
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Aug 5 10:41:31 2020 +0800

    Revert "vxlan: fix tos value before xmit"
    
    [ Upstream commit a0dced17ad9dc08b1b25e0065b54c97a318e6e8b ]
    
    This reverts commit 71130f29979c7c7956b040673e6b9d5643003176.
    
    In commit 71130f29979c ("vxlan: fix tos value before xmit") we want to
    make sure the tos value are filtered by RT_TOS() based on RFC1349.
    
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |   PRECEDENCE    |          TOS          | MBZ |
        +-----+-----+-----+-----+-----+-----+-----+-----+
    
    But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like
    
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |          DS FIELD, DSCP           | ECN FIELD |
        +-----+-----+-----+-----+-----+-----+-----+-----+
    
    So with
    
    IPTOS_TOS_MASK          0x1E
    RT_TOS(tos)             ((tos)&IPTOS_TOS_MASK)
    
    the first 3 bits DSCP info will get lost.
    
    To take all the DSCP info in xmit, we should revert the patch and just push
    all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later.
    
    Fixes: 71130f29979c ("vxlan: fix tos value before xmit")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf4c61248445f08fc0e778c1b14f396b1c689b2e
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Fri Jul 31 00:48:38 2020 -0400

    openvswitch: Prevent kernel-infoleak in ovs_ct_put_key()
    
    [ Upstream commit 9aba6c5b49254d5bee927d81593ed4429e91d4ae ]
    
    ovs_ct_put_key() is potentially copying uninitialized kernel stack memory
    into socket buffers, since the compiler may leave a 3-byte hole at the end
    of `struct ovs_key_ct_tuple_ipv4` and `struct ovs_key_ct_tuple_ipv6`. Fix
    it by initializing `orig` with memset().
    
    Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3e3feb569e0c3628b8a0d68459a9318ce5d891e
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Fri Jul 31 20:12:05 2020 +0200

    net: gre: recompute gre csum for sctp over gre tunnels
    
    [ Upstream commit 622e32b7d4a6492cf5c1f759ef833f817418f7b3 ]
    
    The GRE tunnel can be used to transport traffic that does not rely on a
    Internet checksum (e.g. SCTP). The issue can be triggered creating a GRE
    or GRETAP tunnel and transmitting SCTP traffic ontop of it where CRC
    offload has been disabled. In order to fix the issue we need to
    recompute the GRE csum in gre_gso_segment() not relying on the inner
    checksum.
    The issue is still present when we have the CRC offload enabled.
    In this case we need to disable the CRC offload if we require GRE
    checksum since otherwise skb_checksum() will report a wrong value.
    
    Fixes: 90017accff61 ("sctp: Add GSO support")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 236a93cb8a0beae688ccc1146247d81bb2f1114a
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Tue Aug 4 09:54:15 2020 -0700

    hv_netvsc: do not use VF device if link is down
    
    [ Upstream commit 7c9864bbccc23e1812ac82966555d68c13ea4006 ]
    
    If the accelerated networking SRIOV VF device has lost carrier
    use the synthetic network device which is available as backup
    path. This is a rare case since if VF link goes down, normally
    the VMBus device will also loose external connectivity as well.
    But if the communication is between two VM's on the same host
    the VMBus device will still work.
    
    Reported-by: "Shah, Ashish N" <ashish.n.shah@intel.com>
    Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7105bb40072f3f7de6e06e0a52f804b0f20aa634
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jul 28 14:10:31 2020 +0200

    net: lan78xx: replace bogus endpoint lookup
    
    [ Upstream commit ea060b352654a8de1e070140d25fe1b7e4d50310 ]
    
    Drop the bogus endpoint-lookup helper which could end up accepting
    interfaces based on endpoints belonging to unrelated altsettings.
    
    Note that the returned bulk pipes and interrupt endpoint descriptor
    were never actually used. Instead the bulk-endpoint numbers are
    hardcoded to 1 and 2 (matching the specification), while the interrupt-
    endpoint descriptor was assumed to be the third descriptor created by
    USB core.
    
    Try to bring some order to this by dropping the bogus lookup helper and
    adding the missing endpoint sanity checks while keeping the interrupt-
    descriptor assumption for now.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49a3f519e22690d902c7a161eeff1fbb391efd4e
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Wed Jul 29 11:34:36 2020 +0300

    vxlan: Ensure FDB dump is performed under RCU
    
    [ Upstream commit b5141915b5aec3b29a63db869229e3741ebce258 ]
    
    The commit cited below removed the RCU read-side critical section from
    rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
    without RCU protection.
    
    This results in the following warning [1] in the VXLAN driver, which
    relied on the callback being invoked from an RCU read-side critical
    section.
    
    Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
    in the bridge driver.
    
    [1]
    WARNING: suspicious RCU usage
    5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
    -----------------------------
    drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    1 lock held by bridge/166:
     #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
    
    stack backtrace:
    CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
    Call Trace:
     dump_stack+0x100/0x184
     lockdep_rcu_suspicious+0x153/0x15d
     vxlan_fdb_dump+0x51e/0x6d0
     rtnl_fdb_dump+0x4dc/0xad0
     netlink_dump+0x540/0x1090
     __netlink_dump_start+0x695/0x950
     rtnetlink_rcv_msg+0x802/0xbd0
     netlink_rcv_skb+0x17a/0x480
     rtnetlink_rcv+0x22/0x30
     netlink_unicast+0x5ae/0x890
     netlink_sendmsg+0x98a/0xf40
     __sys_sendto+0x279/0x3b0
     __x64_sys_sendto+0xe6/0x1a0
     do_syscall_64+0x54/0xa0
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7fe14fa2ade0
    Code: Bad RIP value.
    RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0
    RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003
    RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    
    Fixes: 5e6d24358799 ("bridge: netlink dump interface at par with brctl")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64ce1286449faf7a3ce066d46e81de1d03ad200b
Author: Landen Chao <landen.chao@mediatek.com>
Date:   Wed Jul 29 10:15:17 2020 +0200

    net: ethernet: mtk_eth_soc: fix MTU warnings
    
    [ Upstream commit 555a893303872e044fb86f0a5834ce78d41ad2e2 ]
    
    in recent kernel versions there are warnings about incorrect MTU size
    like these:
    
    eth0: mtu greater than device maximum
    mtk_soc_eth 1b100000.ethernet eth0: error -22 setting MTU to include DSA overhead
    
    Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
    Fixes: 72579e14a1d3 ("net: dsa: don't fail to probe if we couldn't set the MTU")
    Fixes: 7a4c53bee332 ("net: report invalid mtu value via netlink extack")
    Signed-off-by: Landen Chao <landen.chao@mediatek.com>
    Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da34873e8fb08a306de0c95457de1f63690114ce
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sat Jul 25 15:40:53 2020 -0700

    ipv6: fix memory leaks on IPV6_ADDRFORM path
    
    [ Upstream commit 8c0de6e96c9794cb523a516c465991a70245da1c ]
    
    IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
    to IPv4, particularly struct ipv6_ac_socklist. Similar to
    struct ipv6_mc_socklist, we should just close it on this path.
    
    This bug can be easily reproduced with the following C program:
    
      #include <stdio.h>
      #include <string.h>
      #include <sys/types.h>
      #include <sys/socket.h>
      #include <arpa/inet.h>
    
      int main()
      {
        int s, value;
        struct sockaddr_in6 addr;
        struct ipv6_mreq m6;
    
        s = socket(AF_INET6, SOCK_DGRAM, 0);
        addr.sin6_family = AF_INET6;
        addr.sin6_port = htons(5000);
        inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
        connect(s, (struct sockaddr *)&addr, sizeof(addr));
    
        inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
        m6.ipv6mr_interface = 5;
        setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));
    
        value = AF_INET;
        setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));
    
        close(s);
        return 0;
      }
    
    Reported-by: ch3332xr@gmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc6af908962ad436604d510e4812aabcbc218a48
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Wed Jul 29 11:37:13 2020 +0300

    ipv4: Silence suspicious RCU usage warning
    
    [ Upstream commit 83f3522860f702748143e022f1a546547314c715 ]
    
    fib_trie_unmerge() is called with RTNL held, but not from an RCU
    read-side critical section. This leads to the following warning [1] when
    the FIB alias list in a leaf is traversed with
    hlist_for_each_entry_rcu().
    
    Since the function is always called with RTNL held and since
    modification of the list is protected by RTNL, simply use
    hlist_for_each_entry() and silence the warning.
    
    [1]
    WARNING: suspicious RCU usage
    5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
    -----------------------------
    net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    1 lock held by ip/164:
     #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
    
    stack backtrace:
    CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
    Call Trace:
     dump_stack+0x100/0x184
     lockdep_rcu_suspicious+0x153/0x15d
     fib_trie_unmerge+0x608/0xdb0
     fib_unmerge+0x44/0x360
     fib4_rule_configure+0xc8/0xad0
     fib_nl_newrule+0x37a/0x1dd0
     rtnetlink_rcv_msg+0x4f7/0xbd0
     netlink_rcv_skb+0x17a/0x480
     rtnetlink_rcv+0x22/0x30
     netlink_unicast+0x5ae/0x890
     netlink_sendmsg+0x98a/0xf40
     ____sys_sendmsg+0x879/0xa00
     ___sys_sendmsg+0x122/0x190
     __sys_sendmsg+0x103/0x1d0
     __x64_sys_sendmsg+0x7d/0xb0
     do_syscall_64+0x54/0xa0
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7fc80a234e97
    Code: Bad RIP value.
    RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97
    RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003
    RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000
    R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001
    R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020
    
    Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89f95b8cff15cbf1ef71602da0f6c0465c6d9e73
Author: Frank van der Linden <fllinden@amazon.com>
Date:   Tue Jun 23 22:39:18 2020 +0000

    xattr: break delegations in {set,remove}xattr
    
    commit 08b5d5014a27e717826999ad20e394a8811aae92 upstream.
    
    set/removexattr on an exported filesystem should break NFS delegations.
    This is true in general, but also for the upcoming support for
    RFC 8726 (NFSv4 extended attribute support). Make sure that they do.
    
    Additionally, they need to grow a _locked variant, since callers might
    call this with i_rwsem held (like the NFS server code).
    
    Cc: stable@vger.kernel.org # v4.9+
    Cc: linux-fsdevel@vger.kernel.org
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Frank van der Linden <fllinden@amazon.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 152983b40ccd8a3b6acb1948c87b7fba2edf8707
Author: Dexuan Cui <decui@microsoft.com>
Date:   Sun Jan 19 15:29:22 2020 -0800

    Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)
    
    [ Upstream commit ddc9d357b991838c2d975e8d7e4e9db26f37a7ff ]
    
    When a Linux hv_sock app tries to connect to a Service GUID on which no
    host app is listening, a recent host (RS3+) sends a
    CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such
    a warning:
    
    unknown msgtype=23
    WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc
    
    Actually Linux can safely ignore the message because the Linux app's
    connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT
    and vsock_stream_connect(). We don't bother to make use of the message
    because: 1) it's only supported on recent hosts; 2) a non-trivial effort
    is required to use the message in Linux, but the benefit is small.
    
    So, let's not see the warning by silently ignoring the message.
    
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbeab31912b7118e2238c2dd5eab7d10cdcd7d98
Author: Philippe Duplessis-Guindon <pduplessis@efficios.com>
Date:   Thu Jul 30 11:02:36 2020 -0400

    tools lib traceevent: Fix memory leak in process_dynamic_array_len
    
    [ Upstream commit e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ]
    
    I compiled with AddressSanitizer and I had these memory leaks while I
    was using the tep_parse_format function:
    
        Direct leak of 28 byte(s) in 4 object(s) allocated from:
            #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
            #1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
            #2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
            #3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
            #4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
            #5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
            #6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
            #7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
            #8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
            #9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
            #10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
            #11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
            #12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
            #13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
            #14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
            #15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
            #16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
            #17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
            #18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
            #19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
            #20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
            #21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
            #22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
            #23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
            #24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
            #25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
            #26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    
    The token variable in the process_dynamic_array_len function is
    allocated in the read_expect_type function, but is not freed before
    calling the read_token function.
    
    Free the token variable before calling read_token in order to plug the
    leak.
    
    Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55939b710b1e35869af18983039559d04af3e0aa
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Wed Jul 29 21:06:59 2020 +0800

    atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent
    
    [ Upstream commit 51875dad43b44241b46a569493f1e4bfa0386d86 ]
    
    atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
    reference of atm_dev with increased refcount or NULL if fails.
    
    The refcount leaks issues occur in two error handling paths. If
    dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
    returns 0 without decreasing the refcount kept by a local variable,
    resulting in refcount leaks.
    
    Fix the issue by adding atm_dev_put() before returning 0 both when
    dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.
    
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccc98c7861e20035025b5db05a9bb302c8e385eb
Author: Francesco Ruggeri <fruggeri@arista.com>
Date:   Thu Jul 2 15:39:06 2020 -0700

    igb: reinit_locked() should be called with rtnl_lock
    
    [ Upstream commit 024a8168b749db7a4aa40a5fbdfa04bf7e77c1c0 ]
    
    We observed two panics involving races with igb_reset_task.
    The first panic is caused by this race condition:
    
            kworker                 reboot -f
    
            igb_reset_task
            igb_reinit_locked
            igb_down
            napi_synchronize
                                    __igb_shutdown
                                    igb_clear_interrupt_scheme
                                    igb_free_q_vectors
                                    igb_free_q_vector
                                    adapter->q_vector[v_idx] = NULL;
            napi_disable
            Panics trying to access
            adapter->q_vector[v_idx].napi_state
    
    The second panic (a divide error) is caused by this race:
    
    kworker         reboot -f       tx packet
    
    igb_reset_task
                    __igb_shutdown
                    rtnl_lock()
                    ...
                    igb_clear_interrupt_scheme
                    igb_free_q_vectors
                    adapter->num_tx_queues = 0
                    ...
                    rtnl_unlock()
    rtnl_lock()
    igb_reinit_locked
    igb_down
    igb_up
    netif_tx_start_all_queues
                                    dev_hard_start_xmit
                                    igb_xmit_frame
                                    igb_tx_queue_mapping
                                    Panics on
                                    r_idx % adapter->num_tx_queues
    
    This commit applies to igb_reset_task the same changes that
    were applied to ixgbe in commit 2f90b8657ec9 ("ixgbe: this patch
    adds support for DCB to the kernel and ixgbe driver"),
    commit 8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
    rtnl_lock") and commit 88adce4ea8f9 ("ixgbe: fix possible race in
    reset subtask").
    
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df1a89577ebbb6165f3f1d9e1da84fda80dd7e01
Author: Julian Squires <julian@cipht.net>
Date:   Mon Jul 6 17:13:53 2020 -0400

    cfg80211: check vendor command doit pointer before use
    
    [ Upstream commit 4052d3d2e8f47a15053320bbcbe365d15610437d ]
    
    In the case where a vendor command does not implement doit, and has no
    flags set, doit would not be validated and a NULL pointer dereference
    would occur, for example when invoking the vendor command via iw.
    
    I encountered this while developing new vendor commands.  Perhaps in
    practice it is advisable to always implement doit along with dumpit,
    but it seems reasonable to me to always check doit anyway, not just
    when NEED_WDEV.
    
    Signed-off-by: Julian Squires <julian@cipht.net>
    Link: https://lore.kernel.org/r/20200706211353.2366470-1-julian@cipht.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59822dace1c9258c22ebf16adb1b49a6eff0bdf2
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sat Jul 25 21:50:53 2020 +0200

    i2c: slave: add sanity check when unregistering
    
    [ Upstream commit 8808981baf96e1b3dea1f08461e4d958aa0dbde1 ]
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Alain Volmat <alain.volmat@st.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb49251695b1e735860b5fd953d691f6cf817873
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sat Jul 25 21:50:52 2020 +0200

    i2c: slave: improve sanity check when registering
    
    [ Upstream commit 1b1be3bf27b62f5abcf85c6f3214bdb9c7526685 ]
    
    Add check for ERR_PTR and simplify code while here.
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Alain Volmat <alain.volmat@st.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a284881b0e66537a185973d72a54c5e7b4df47f
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri Jul 24 17:02:48 2020 +1000

    drm/nouveau/fbcon: zero-initialise the mode_cmd2 structure
    
    [ Upstream commit 15fbc3b938534cc8eaac584a7b0c1183fc968b86 ]
    
    This is tripping up the format modifier patches.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3793c4c127e34d1fded7e64158c1795b7f7d1983
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri Jul 24 17:01:39 2020 +1000

    drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason
    
    [ Upstream commit 498595abf5bd51f0ae074cec565d888778ea558f ]
    
    Stale pointer was tripping up the unload path.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e48afaff38159b7ca000bb9f00dcf1d0b277264d
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jul 10 10:57:22 2020 +0200

    net/9p: validate fds in p9_fd_open
    
    [ Upstream commit a39c46067c845a8a2d7144836e9468b7f072343e ]
    
    p9_fd_open just fgets file descriptors passed in from userspace, but
    doesn't verify that they are valid for read or writing.  This gets
    cought down in the VFS when actually attempting a read or write, but
    a new warning added in linux-next upsets syzcaller.
    
    Fix this by just verifying the fds early on.
    
    Link: http://lkml.kernel.org/r/20200710085722.435850-1-hch@lst.de
    Reported-by: syzbot+e6f77e16ff68b2434a2c@syzkaller.appspotmail.com
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    [Dominique: amend goto as per Doug Nazar's review]
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efe1c042fa521dcce374ca23560480ff6927a58e
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jun 1 15:39:45 2020 +0200

    leds: 88pm860x: fix use-after-free on unbind
    
    commit eca21c2d8655387823d695b26e6fe78cf3975c05 upstream.
    
    Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.
    
    Fixes: 375446df95ee ("leds: 88pm860x: Use devm_led_classdev_register")
    Cc: stable <stable@vger.kernel.org>     # 4.6
    Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 661926601c318c4cf30272ac93ed2bf1c80ff778
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jun 1 15:39:47 2020 +0200

    leds: lm3533: fix use-after-free on unbind
    
    commit d584221e683bbd173738603b83a315f27d27d043 upstream.
    
    Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.
    
    Fixes: 50154e29e5cc ("leds: lm3533: Use devm_led_classdev_register")
    Cc: stable <stable@vger.kernel.org>     # 4.6
    Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1452c5ffe79f34ded327310a84a67d653a00e68e
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jun 1 15:39:46 2020 +0200

    leds: da903x: fix use-after-free on unbind
    
    commit 6f4aa35744f69ed9b0bf5a736c9ca9b44bc1dcea upstream.
    
    Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.
    
    Fixes: eed16255d66b ("leds: da903x: Use devm_led_classdev_register")
    Cc: stable <stable@vger.kernel.org>     # 4.6
    Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbe4aa36c940dc309133e5d10a5771f3d0bf2d28
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jun 1 15:39:49 2020 +0200

    leds: wm831x-status: fix use-after-free on unbind
    
    commit 47a459ecc800a17109d0c496a4e21e478806ee40 upstream.
    
    Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.
    
    Fixes: 8d3b6a4001ce ("leds: wm831x-status: Use devm_led_classdev_register")
    Cc: stable <stable@vger.kernel.org>     # 4.6
    Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 389c74c218d3b182e9cd767e98cee0e0fd0dabaa
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 16 13:53:46 2020 +0200

    mtd: properly check all write ioctls for permissions
    
    commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream.
    
    When doing a "write" ioctl call, properly check that we have permissions
    to do so before copying anything from userspace or anything else so we
    can "fail fast".  This includes also covering the MEMWRITE ioctl which
    previously missed checking for this.
    
    Cc: Miquel Raynal <miquel.raynal@bootlin.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Vignesh Raghavendra <vigneshr@ti.com>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [rw: Fixed locking issue]
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 041a5a238a1e31992b5f22ef4f9792729d3b46ca
Author: Yunhai Zhang <zhangyunhai@nsfocus.com>
Date:   Tue Jul 28 09:58:03 2020 +0800

    vgacon: Fix for missing check in scrollback handling
    
    commit ebfdfeeae8c01fcb2b3b74ffaf03876e20835d2d upstream.
    
    vgacon_scrollback_update() always leaves enbough room in the scrollback
    buffer for the next call, but if the console size changed that room
    might not actually be enough, and so we need to re-check.
    
    The check should be in the loop since vgacon_scrollback_cur->tail is
    updated in the loop and count may be more than 1 when triggered by CSI M,
    as Jiri's PoC:
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <sys/ioctl.h>
    #include <fcntl.h>
    
    int main(int argc, char** argv)
    {
            int fd = open("/dev/tty1", O_RDWR);
            unsigned short size[3] = {25, 200, 0};
            ioctl(fd, 0x5609, size); // VT_RESIZE
    
            write(fd, "\e[1;1H", 6);
            for (int i = 0; i < 30; i++)
                    write(fd, "\e[10M", 5);
    }
    
    It leads to various crashes as vgacon_scrollback_update writes out of
    the buffer:
     BUG: unable to handle page fault for address: ffffc900001752a0
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     RIP: 0010:mutex_unlock+0x13/0x30
    ...
     Call Trace:
      n_tty_write+0x1a0/0x4d0
      tty_write+0x1a0/0x2e0
    
    Or to KASAN reports:
    BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
    
    This fixes CVE-2020-14331.
    
    Reported-by: 张云海 <zhangyunhai@nsfocus.com>
    Reported-by: Yang Yingliang <yangyingliang@huawei.com>
    Reported-by: Kyungtae Kim <kt0755@gmail.com>
    Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
    Cc: stable@vger.kernel.org
    Cc: linux-fbdev@vger.kernel.org
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Solar Designer <solar@openwall.com>
    Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
    Cc: Anthony Liguori <aliguori@amazon.com>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Yunhai Zhang <zhangyunhai@nsfocus.com>
    Link: https://lore.kernel.org/r/9fb43895-ca91-9b07-ebfd-808cf854ca95@nsfocus.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f40f289b96bf856e1613f17bf9426140e8b89393
Author: Jann Horn <jannh@google.com>
Date:   Mon Jul 27 14:04:24 2020 +0200

    binder: Prevent context manager from incrementing ref 0
    
    commit 4b836a1426cb0f1ef2a6e211d7e553221594f8fc upstream.
    
    Binder is designed such that a binder_proc never has references to
    itself. If this rule is violated, memory corruption can occur when a
    process sends a transaction to itself; see e.g.
    <https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
    
    There is a remaining edgecase through which such a transaction-to-self
    can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
    access:
    
     - task A opens /dev/binder twice, creating binder_proc instances P1
       and P2
     - P1 becomes context manager
     - P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
       handle table
     - P1 dies (by closing the /dev/binder fd and waiting a bit)
     - P2 becomes context manager
     - P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
       handle table
       [this triggers a warning: "binder: 1974:1974 tried to acquire
       reference to desc 0, got 1 instead"]
     - task B opens /dev/binder once, creating binder_proc instance P3
     - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
       transaction)
     - P2 receives the handle and uses it to call P3 (two-way transaction)
     - P3 calls P2 (via magic handle 0) (two-way transaction)
     - P2 calls P2 (via handle 1) (two-way transaction)
    
    And then, if P2 does *NOT* accept the incoming transaction work, but
    instead closes the binder fd, we get a crash.
    
    Solve it by preventing the context manager from using ACQUIRE on ref 0.
    There shouldn't be any legitimate reason for the context manager to do
    that.
    
    Additionally, print a warning if someone manages to find another way to
    trigger a transaction-to-self bug in the future.
    
    Cc: stable@vger.kernel.org
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Acked-by: Todd Kjos <tkjos@google.com>
    Signed-off-by: Jann Horn <jannh@google.com>
    Reviewed-by: Martijn Coenen <maco@android.com>
    Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a0cb0a6bc88bc4684d7b1e8e8fc3892bb921ed1
Author: Adam Ford <aford173@gmail.com>
Date:   Tue Jun 30 13:26:36 2020 -0500

    omapfb: dss: Fix max fclk divider for omap36xx
    
    commit 254503a2b186caa668a188dbbd7ab0d25149c0a5 upstream.
    
    The drm/omap driver was fixed to correct an issue where using a
    divider of 32 breaks the DSS despite the TRM stating 32 is a valid
    number.  Through experimentation, it appears that 31 works, and
    it is consistent with the value used by the drm/omap driver.
    
    This patch fixes the divider for fbdev driver instead of the drm.
    
    Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
    Cc: <stable@vger.kernel.org> #4.5+
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Dave Airlie <airlied@gmail.com>
    Cc: Rob Clark <robdclark@gmail.com>
    [b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)]
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200630182636.439015-1-aford173@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68bb9eddbf5da767131079325b2097341ab05dca
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Fri Jul 10 17:45:26 2020 -0400

    Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_with_rssi_evt()
    
    commit 629b49c848ee71244203934347bd7730b0ddee8d upstream.
    
    Check `num_rsp` before using it as for-loop counter. Add `unlock` label.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b0861f956f65f063662f9553a4dcad574a95b37
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Fri Jul 10 17:39:18 2020 -0400

    Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt()
    
    commit 75bbd2ea50ba1c5d9da878a17e92eac02fe0fd3a upstream.
    
    Check `num_rsp` before using it as for-loop counter.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d91299b8382b129156708708d69876e753b9ade6
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Fri Jul 10 12:09:15 2020 -0400

    Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt()
    
    commit 51c19bf3d5cfaa66571e4b88ba2a6f6295311101 upstream.
    
    Check upon `num_rsp` is insufficient. A malformed event packet with a
    large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
    of bounds. Fix it.
    
    This patch fixes the following syzbot bug:
    
        https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2
    
    Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79c70607e5403d31d267e31a1a34e5334318326d
Author: Suren Baghdasaryan <surenb@google.com>
Date:   Thu Jul 30 12:26:32 2020 -0700

    staging: android: ashmem: Fix lockdep warning for write operation
    
    commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.
    
    syzbot report [1] describes a deadlock when write operation against an
    ashmem fd executed at the time when ashmem is shrinking its cache results
    in the following lock sequence:
    
    Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(fs_reclaim);
                                    lock(&sb->s_type->i_mutex_key#13);
                                    lock(fs_reclaim);
       lock(&sb->s_type->i_mutex_key#13);
    
    kswapd takes fs_reclaim and then inode_lock while generic_perform_write
    takes inode_lock and then fs_reclaim. However ashmem does not support
    writing into backing shmem with a write syscall. The only way to change
    its content is to mmap it and operate on mapped memory. Therefore the race
    that lockdep is warning about is not valid. Resolve this by introducing a
    separate lockdep class for the backing shmem inodes.
    
    [1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/
    
    Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
    Signed-off-by: Suren Baghdasaryan <surenb@google.com>
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccafbed8b2f6a9d9298534b39e76da9cb40ff717
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 4 20:58:15 2020 +0200

    ALSA: seq: oss: Serialize ioctls
    
    commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
    
    Some ioctls via OSS sequencer API may race and lead to UAF when the
    port create and delete are performed concurrently, as spotted by a
    couple of syzkaller cases.  This patch is an attempt to address it by
    serializing the ioctls with the existing register_mutex.
    
    Basically OSS sequencer API is an obsoleted interface and was designed
    without much consideration of the concurrency.  There are very few
    applications with it, and the concurrent performance isn't asked,
    hence this "big hammer" approach should be good enough.
    
    Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com
    Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com
    Suggested-by: Hillf Danton <hdanton@sina.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5021d4fa888ad248b4168947eb1e569de75fdb1
Author: Forest Crossman <cyrozap@gmail.com>
Date:   Mon Jul 27 23:24:08 2020 -0500

    usb: xhci: Fix ASMedia ASM1142 DMA addressing
    
    commit ec37198acca7b4c17b96247697406e47aafe0605 upstream.
    
    I've confirmed that the ASMedia ASM1142 has the same problem as the
    ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA
    addresses when in fact it does not. As with the ASM2142/ASM3142, this
    can cause problems on systems where the upper bits matter, and adding
    the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue.
    
    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Forest Crossman <cyrozap@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5eed80ea8f60cc3935f46ec848fa1677b5e1a31a
Author: Forest Crossman <cyrozap@gmail.com>
Date:   Mon Jul 27 23:24:07 2020 -0500

    usb: xhci: define IDs for various ASMedia host controllers
    
    commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream.
    
    Not all ASMedia host controllers have a device ID that matches its part
    number. #define some of these IDs to make it clearer at a glance which
    chips require what quirks.
    
    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Forest Crossman <cyrozap@gmail.com>
    Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad9db0326bc4516980b0f6fd85724561bca5e474
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jul 26 11:49:39 2020 +0200

    USB: iowarrior: fix up report size handling for some devices
    
    commit 17a82716587e9d7c3b246a789add490b2b5dcab6 upstream.
    
    In previous patches that added support for new iowarrior devices, the
    handling of the report size was not done correct.
    
    Fix that up and update the copyright date for the driver
    
    Reworked from an original patch written by Christoph Jung.
    
    Fixes: bab5417f5f01 ("USB: misc: iowarrior: add support for the 100 device")
    Fixes: 5f6f8da2d7b5 ("USB: misc: iowarrior: add support for the 28 and 28L devices")
    Fixes: 461d8deb26a7 ("USB: misc: iowarrior: add support for 2 OEMed devices")
    Cc: stable <stable@kernel.org>
    Reported-by: Christoph Jung <jung@codemercs.com>
    Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec2cbe4b8abf949a16574ba81d8255e52980186c
Author: Roi Dayan <roid@mellanox.com>
Date:   Thu Aug 6 19:05:42 2020 -0700

    net/mlx5e: Don't support phys switch id if not in switchdev mode
    
    Support for phys switch id ndo added for representors and if
    we do not have representors there is no need to support it.
    Since each port return different switch id supporting this
    block support for creating bond over PFs and attaching to bridge
    in legacy mode.
    
    This bug doesn't exist upstream as the code got refactored and the
    netdev api is totally different.
    
    Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors")
    Signed-off-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bad105bad58122fbb7bf7a67ae7730c3fd9443e
Author: Erik Ekman <erik@kryo.se>
Date:   Fri Jul 17 20:51:18 2020 +0200

    USB: serial: qcserial: add EM7305 QDL product ID
    
    commit d2a4309c1ab6df424b2239fe2920d6f26f808d17 upstream.
    
    When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba
    laptop, it changed product ID to 0x9062 when entering QDL mode:
    
    usb 2-4: new high-speed USB device number 78 using xhci_hcd
    usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00
    usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 2-4: Product: EM7305
    usb 2-4: Manufacturer: Sierra Wireless, Incorporated
    
    The upgrade could complete after running
     # echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id
    
    qcserial 2-4:1.0: Qualcomm USB modem converter detected
    usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0
    
    Signed-off-by: Erik Ekman <erik@kryo.se>
    Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>