commit 245f15a48cdc4d5a90902e140392dc151e528ab8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 15 09:47:41 2021 +0200

    Linux 5.4.146
    
    Link: https://lore.kernel.org/r/20210913131047.974309396@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b40facee46db042de2e594ba67fe4964b6340478
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sun Aug 15 01:55:14 2021 +0200

    clk: kirkwood: Fix a clocking boot regression
    
    commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream.
    
    Since a few kernel releases the Pogoplug 4 has crashed like this
    during boot:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000002
    (...)
    [<c04116ec>] (strlen) from [<c00ead80>] (kstrdup+0x1c/0x4c)
    [<c00ead80>] (kstrdup) from [<c04591d8>] (__clk_register+0x44/0x37c)
    [<c04591d8>] (__clk_register) from [<c04595ec>] (clk_hw_register+0x20/0x44)
    [<c04595ec>] (clk_hw_register) from [<c045bfa8>] (__clk_hw_register_mux+0x198/0x1e4)
    [<c045bfa8>] (__clk_hw_register_mux) from [<c045c050>] (clk_register_mux_table+0x5c/0x6c)
    [<c045c050>] (clk_register_mux_table) from [<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac)
    [<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0) from [<c0aceae0>] (of_clk_init+0x12c/0x214)
    [<c0aceae0>] (of_clk_init) from [<c0ab576c>] (time_init+0x20/0x2c)
    [<c0ab576c>] (time_init) from [<c0ab3d18>] (start_kernel+0x3dc/0x56c)
    [<c0ab3d18>] (start_kernel) from [<00000000>] (0x0)
    Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000)
    
    This is because the "powersave" mux clock 0 was provided in an unterminated
    array, which is required by the loop in the driver:
    
            /* Count, allocate, and register clock muxes */
            for (n = 0; desc[n].name;)
                    n++;
    
    Here n will go out of bounds and then call clk_register_mux() on random
    memory contents after the mux clock.
    
    Fix this by terminating the array with a blank entry.
    
    Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer")
    Cc: stable@vger.kernel.org
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
    Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8810c51077b0c11717c90cd7b4857a64a221579d
Author: Daniel Thompson <daniel.thompson@linaro.org>
Date:   Thu Jul 22 15:46:23 2021 +0100

    backlight: pwm_bl: Improve bootloader/kernel device handover
    
    commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream.
    
    Currently there are (at least) two problems in the way pwm_bl starts
    managing the enable_gpio pin. Both occur when the backlight is initially
    off and the driver finds the pin not already in output mode and, as a
    result, unconditionally switches it to output-mode and asserts the signal.
    
    Problem 1: This could cause the backlight to flicker since, at this stage
    in driver initialisation, we have no idea what the PWM and regulator are
    doing (an unconfigured PWM could easily "rest" at 100% duty cycle).
    
    Problem 2: This will cause us not to correctly honour the
    post_pwm_on_delay (which also risks flickers).
    
    Fix this by moving the code to configure the GPIO output mode until after
    we have examines the handover state. That allows us to initialize
    enable_gpio to off if the backlight is currently off and on if the
    backlight is on.
    
    Cc: stable@vger.kernel.org
    Reported-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Acked-by: Marek Vasut <marex@denx.de>
    Tested-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5de2ee621bc48fc527f0ed51265eea4bed8b769a
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Wed Sep 8 19:27:49 2021 +0900

    fbmem: don't allow too huge resolutions
    
    commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream.
    
    syzbot is reporting page fault at vga16fb_fillrect() [1], for
    vga16fb_check_var() is failing to detect multiplication overflow.
    
      if (vxres * vyres > maxmem) {
        vyres = maxmem / vxres;
        if (vyres < yres)
          return -ENOMEM;
      }
    
    Since no module would accept too huge resolutions where multiplication
    overflow happens, let's reject in the common path.
    
    Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
    Reported-by: syzbot <syzbot+04168c8063cfdde1db5e@syzkaller.appspotmail.com>
    Debugged-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a95b04afab55ecac3f4b71a61e7ef6dcbfb892f
Author: THOBY Simon <Simon.THOBY@viveris.fr>
Date:   Mon Aug 16 08:10:59 2021 +0000

    IMA: remove the dependency on CRYPTO_MD5
    
    commit 8510505d55e194d3f6c9644c9f9d12c4f6b0395a upstream.
    
    MD5 is a weak digest algorithm that shouldn't be used for cryptographic
    operation. It hinders the efficiency of a patch set that aims to limit
    the digests allowed for the extended file attribute namely security.ima.
    MD5 is no longer a requirement for IMA, nor should it be used there.
    
    The sole place where we still use the MD5 algorithm inside IMA is setting
    the ima_hash algorithm to MD5, if the user supplies 'ima_hash=md5'
    parameter on the command line.  With commit ab60368ab6a4 ("ima: Fallback
    to the builtin hash algorithm"), setting "ima_hash=md5" fails gracefully
    when CRYPTO_MD5 is not set:
            ima: Can not allocate md5 (reason: -2)
            ima: Allocating md5 failed, going to use default hash algorithm sha256
    
    Remove the CRYPTO_MD5 dependency for IMA.
    
    Signed-off-by: THOBY Simon <Simon.THOBY@viveris.fr>
    Reviewed-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
    [zohar@linux.ibm.com: include commit number in patch description for
    stable.]
    Cc: stable@vger.kernel.org # 4.17
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c69935f0b0aa763fd2095e9a65945f5527059757
Author: Austin Kim <austin.kim@lge.com>
Date:   Tue Jun 29 14:50:50 2021 +0100

    IMA: remove -Wmissing-prototypes warning
    
    commit a32ad90426a9c8eb3915eed26e08ce133bd9e0da upstream.
    
    With W=1 build, the compiler throws warning message as below:
    
       security/integrity/ima/ima_mok.c:24:12: warning:
       no previous prototype for ‘ima_mok_init’ [-Wmissing-prototypes]
           __init int ima_mok_init(void)
    
    Silence the warning by adding static keyword to ima_mok_init().
    
    Signed-off-by: Austin Kim <austin.kim@lge.com>
    Fixes: 41c89b64d718 ("IMA: create machine owner and blacklist keyrings")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85b0726d5bd714fd968b434d46cdaea60c29131c
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Aug 31 14:18:08 2021 +0200

    fuse: flush extending writes
    
    commit 59bda8ecee2ffc6a602b7bf2b9e43ca669cdbdcd upstream.
    
    Callers of fuse_writeback_range() assume that the file is ready for
    modification by the server in the supplied byte range after the call
    returns.
    
    If there's a write that extends the file beyond the end of the supplied
    range, then the file needs to be extended to at least the end of the range,
    but currently that's not done.
    
    There are at least two cases where this can cause problems:
    
     - copy_file_range() will return short count if the file is not extended
       up to end of the source range.
    
     - FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE will not extend the file,
       hence the region may not be fully allocated.
    
    Fix by flushing writes from the start of the range up to the end of the
    file.  This could be optimized if the writes are non-extending, etc, but
    it's probably not worth the trouble.
    
    Fixes: a2bc92362941 ("fuse: fix copy_file_range() in the writeback case")
    Fixes: 6b1bdb56b17c ("fuse: allow fallocate(FALLOC_FL_ZERO_RANGE)")
    Cc: <stable@vger.kernel.org>  # v5.2
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a98ced6e1c812e28340080739505bffe0a0cf4c
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Aug 17 21:05:16 2021 +0200

    fuse: truncate pagecache on atomic_o_trunc
    
    commit 76224355db7570cbe6b6f75c8929a1558828dd55 upstream.
    
    fuse_finish_open() will be called with FUSE_NOWRITE in case of atomic
    O_TRUNC.  This can deadlock with fuse_wait_on_page_writeback() in
    fuse_launder_page() triggered by invalidate_inode_pages2().
    
    Fix by replacing invalidate_inode_pages2() in fuse_finish_open() with a
    truncate_pagecache() call.  This makes sense regardless of FOPEN_KEEP_CACHE
    or fc->writeback cache, so do it unconditionally.
    
    Reported-by: Xie Yongji <xieyongji@bytedance.com>
    Reported-and-tested-by: syzbot+bea44a5189836d956894@syzkaller.appspotmail.com
    Fixes: e4648309b85a ("fuse: truncate pending writes on O_TRUNC")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06dad664d4eae136e8dfa9eea955b154213f3f2e
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Aug 10 07:45:26 2021 -0700

    KVM: nVMX: Unconditionally clear nested.pi_pending on nested VM-Enter
    
    commit f7782bb8d818d8f47c26b22079db10599922787a upstream.
    
    Clear nested.pi_pending on nested VM-Enter even if L2 will run without
    posted interrupts enabled.  If nested.pi_pending is left set from a
    previous L2, vmx_complete_nested_posted_interrupt() will pick up the
    stale flag and exit to userspace with an "internal emulation error" due
    the new L2 not having a valid nested.pi_desc.
    
    Arguably, vmx_complete_nested_posted_interrupt() should first check for
    posted interrupts being enabled, but it's also completely reasonable that
    KVM wouldn't screw up a fundamental flag.  Not to mention that the mere
    existence of nested.pi_pending is a long-standing bug as KVM shouldn't
    move the posted interrupt out of the IRR until it's actually processed,
    e.g. KVM effectively drops an interrupt when it performs a nested VM-Exit
    with a "pending" posted interrupt.  Fixing the mess is a future problem.
    
    Prior to vmx_complete_nested_posted_interrupt() interpreting a null PI
    descriptor as an error, this was a benign bug as the null PI descriptor
    effectively served as a check on PI not being enabled.  Even then, the
    new flow did not become problematic until KVM started checking the result
    of kvm_check_nested_events().
    
    Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing")
    Fixes: 966eefb89657 ("KVM: nVMX: Disable vmcs02 posted interrupts if vmcs12 PID isn't mappable")
    Fixes: 47d3530f86c0 ("KVM: x86: Exit to userspace when kvm_check_nested_events fails")
    Cc: stable@vger.kernel.org
    Cc: Jim Mattson <jmattson@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210810144526.2662272-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1735cec1e83c5e1b93de47c07d74d706644394ad
Author: Zelin Deng <zelin.deng@linux.alibaba.com>
Date:   Wed Apr 28 10:22:01 2021 +0800

    KVM: x86: Update vCPU's hv_clock before back to guest when tsc_offset is adjusted
    
    commit d9130a2dfdd4b21736c91b818f87dbc0ccd1e757 upstream.
    
    When MSR_IA32_TSC_ADJUST is written by guest due to TSC ADJUST feature
    especially there's a big tsc warp (like a new vCPU is hot-added into VM
    which has been up for a long time), tsc_offset is added by a large value
    then go back to guest. This causes system time jump as tsc_timestamp is
    not adjusted in the meantime and pvclock monotonic character.
    To fix this, just notify kvm to update vCPU's guest time before back to
    guest.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Zelin Deng <zelin.deng@linux.alibaba.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Message-Id: <1619576521-81399-2-git-send-email-zelin.deng@linux.alibaba.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20fff3ef33b225cbb666600de014c43fad75f839
Author: Halil Pasic <pasic@linux.ibm.com>
Date:   Fri Aug 27 14:54:29 2021 +0200

    KVM: s390: index kvm->arch.idle_mask by vcpu_idx
    
    commit a3e03bc1368c1bc16e19b001fc96dc7430573cc8 upstream.
    
    While in practice vcpu->vcpu_idx ==  vcpu->vcp_id is often true, it may
    not always be, and we must not rely on this. Reason is that KVM decides
    the vcpu_idx, userspace decides the vcpu_id, thus the two might not
    match.
    
    Currently kvm->arch.idle_mask is indexed by vcpu_id, which implies
    that code like
    for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) {
                    vcpu = kvm_get_vcpu(kvm, vcpu_id);
                    do_stuff(vcpu);
    }
    is not legit. Reason is that kvm_get_vcpu expects an vcpu_idx, not an
    vcpu_id.  The trouble is, we do actually use kvm->arch.idle_mask like
    this. To fix this problem we have two options. Either use
    kvm_get_vcpu_by_id(vcpu_id), which would loop to find the right vcpu_id,
    or switch to indexing via vcpu_idx. The latter is preferable for obvious
    reasons.
    
    Let us make switch from indexing kvm->arch.idle_mask by vcpu_id to
    indexing it by vcpu_idx.  To keep gisa_int.kicked_mask indexed by the
    same index as idle_mask lets make the same change for it as well.
    
    Fixes: 1ee0bc559dc3 ("KVM: s390: get rid of local_int array")
    Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
    Reviewed-by: Christian Bornträger <borntraeger@de.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Cc: <stable@vger.kernel.org> # 3.15+
    Link: https://lore.kernel.org/r/20210827125429.1912577-1-pasic@linux.ibm.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0323ab5b254e05a5f84051afb61ad7e646d840f3
Author: Babu Moger <babu.moger@amd.com>
Date:   Fri Aug 20 16:52:42 2021 -0500

    x86/resctrl: Fix a maybe-uninitialized build warning treated as error
    
    commit 527f721478bce3f49b513a733bacd19d6f34b08c upstream.
    
    The recent commit
    
      064855a69003 ("x86/resctrl: Fix default monitoring groups reporting")
    
    caused a RHEL build failure with an uninitialized variable warning
    treated as an error because it removed the default case snippet.
    
    The RHEL Makefile uses '-Werror=maybe-uninitialized' to force possibly
    uninitialized variable warnings to be treated as errors. This is also
    reported by smatch via the 0day robot.
    
    The error from the RHEL build is:
    
      arch/x86/kernel/cpu/resctrl/monitor.c: In function ‘__mon_event_count’:
      arch/x86/kernel/cpu/resctrl/monitor.c:261:12: error: ‘m’ may be used
      uninitialized in this function [-Werror=maybe-uninitialized]
        m->chunks += chunks;
                  ^~
    
    The upstream Makefile does not build using '-Werror=maybe-uninitialized'.
    So, the problem is not seen there. Fix the problem by putting back the
    default case snippet.
    
     [ bp: note that there's nothing wrong with the code and other compilers
       do not trigger this warning - this is being done just so the RHEL compiler
       is happy. ]
    
    Fixes: 064855a69003 ("x86/resctrl: Fix default monitoring groups reporting")
    Reported-by: Terry Bowman <Terry.Bowman@amd.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Babu Moger <babu.moger@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/162949631908.23903.17090272726012848523.stgit@bmoger-ubuntu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51f4575ca182071218cc709c13827d96c52a2d8f
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Tue Aug 17 17:10:41 2021 -0500

    perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op
    
    commit f11dd0d80555cdc8eaf5cfc9e19c9e198217f9f1 upstream.
    
    Commit:
    
       2ff40250691e ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs")
    
    neglected to do so.
    
    Fixes: 2ff40250691e ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs")
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210817221048.88063-2-kim.phillips@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03c3e977eeacbaa9929d5e15fe6908523909543c
Author: Nguyen Dinh Phi <phind.uet@gmail.com>
Date:   Mon Aug 23 08:06:41 2021 +0800

    tty: Fix data race between tiocsti() and flush_to_ldisc()
    
    commit bb2853a6a421a052268eee00fd5d3f6b3504b2b1 upstream.
    
    The ops->receive_buf() may be accessed concurrently from these two
    functions.  If the driver flushes data to the line discipline
    receive_buf() method while tiocsti() is waiting for the
    ops->receive_buf() to finish its work, the data race will happen.
    
    For example:
    tty_ioctl                       |tty_ldisc_receive_buf
     ->tioctsi                      | ->tty_port_default_receive_buf
                                    |  ->tty_ldisc_receive_buf
       ->hci_uart_tty_receive       |   ->hci_uart_tty_receive
        ->h4_recv                   |    ->h4_recv
    
    In this case, the h4 receive buffer will be overwritten by the
    latecomer, and we will lost the data.
    
    Hence, change tioctsi() function to use the exclusive lock interface
    from tty_buffer to avoid the data race.
    
    Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
    Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a25a0a94c8b49759582ac6141c06af4f3e8ae8f
Author: Lukas Hannen <lukas.hannen@opensource.tttech-industrial.com>
Date:   Wed Aug 25 10:12:43 2021 +0000

    time: Handle negative seconds correctly in timespec64_to_ns()
    
    commit 39ff83f2f6cc5cc1458dfcea9697f96338210beb upstream.
    
    timespec64_ns() prevents multiplication overflows by comparing the seconds
    value of the timespec to KTIME_SEC_MAX. If the value is greater or equal it
    returns KTIME_MAX.
    
    But that check casts the signed seconds value to unsigned which makes the
    comparision true for all negative values and therefore return wrongly
    KTIME_MAX.
    
    Negative second values are perfectly valid and required in some places,
    e.g. ptp_clock_adjtime().
    
    Remove the cast and add a check for the negative boundary which is required
    to prevent undefined behaviour due to multiplication underflow.
    
    Fixes: cb47755725da ("time: Prevent undefined behaviour in timespec64_to_ns()")'
    Signed-off-by: Lukas Hannen <lukas.hannen@opensource.tttech-industrial.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/AM6PR01MB541637BD6F336B8FFB72AF80EEC69@AM6PR01MB5416.eurprd01.prod.exchangelabs.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae968e270f2e3427f2f24d6ef463fcb0351e2f37
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Sep 7 16:17:01 2021 +0300

    bpf: Fix pointer arithmetic mask tightening under state pruning
    
    commit e042aa532c84d18ff13291d00620502ce7a38dda upstream.
    
    In 7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask") we
    narrowed the offset mask for unprivileged pointer arithmetic in order to
    mitigate a corner case where in the speculative domain it is possible to
    advance, for example, the map value pointer by up to value_size-1 out-of-
    bounds in order to leak kernel memory via side-channel to user space.
    
    The verifier's state pruning for scalars leaves one corner case open
    where in the first verification path R_x holds an unknown scalar with an
    aux->alu_limit of e.g. 7, and in a second verification path that same
    register R_x, here denoted as R_x', holds an unknown scalar which has
    tighter bounds and would thus satisfy range_within(R_x, R_x') as well as
    tnum_in(R_x, R_x') for state pruning, yielding an aux->alu_limit of 3:
    Given the second path fits the register constraints for pruning, the final
    generated mask from aux->alu_limit will remain at 7. While technically
    not wrong for the non-speculative domain, it would however be possible
    to craft similar cases where the mask would be too wide as in 7fedb63a8307.
    
    One way to fix it is to detect the presence of unknown scalar map pointer
    arithmetic and force a deeper search on unknown scalars to ensure that
    we do not run into a masking mismatch.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [OP: adjusted context in include/linux/bpf_verifier.h for 5.4]
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a4778feae1a435ef2d03006cc434db40cfa311
Author: Lorenz Bauer <lmb@cloudflare.com>
Date:   Tue Sep 7 16:17:00 2021 +0300

    bpf: verifier: Allocate idmap scratch in verifier env
    
    commit c9e73e3d2b1eb1ea7ff068e05007eec3bd8ef1c9 upstream.
    
    func_states_equal makes a very short lived allocation for idmap,
    probably because it's too large to fit on the stack. However the
    function is called quite often, leading to a lot of alloc / free
    churn. Replace the temporary allocation with dedicated scratch
    space in struct bpf_verifier_env.
    
    Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Edward Cree <ecree.xilinx@gmail.com>
    Link: https://lore.kernel.org/bpf/20210429134656.122225-4-lmb@cloudflare.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [OP: adjusted context for 5.4]
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5893af2704eb763eb982f01d573f5b19f06b623
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Sep 7 16:16:59 2021 +0300

    bpf: Fix leakage due to insufficient speculative store bypass mitigation
    
    commit 2039f26f3aca5b0e419b98f65dd36481337b86ee upstream.
    
    Spectre v4 gadgets make use of memory disambiguation, which is a set of
    techniques that execute memory access instructions, that is, loads and
    stores, out of program order; Intel's optimization manual, section 2.4.4.5:
    
      A load instruction micro-op may depend on a preceding store. Many
      microarchitectures block loads until all preceding store addresses are
      known. The memory disambiguator predicts which loads will not depend on
      any previous stores. When the disambiguator predicts that a load does
      not have such a dependency, the load takes its data from the L1 data
      cache. Eventually, the prediction is verified. If an actual conflict is
      detected, the load and all succeeding instructions are re-executed.
    
    af86ca4e3088 ("bpf: Prevent memory disambiguation attack") tried to mitigate
    this attack by sanitizing the memory locations through preemptive "fast"
    (low latency) stores of zero prior to the actual "slow" (high latency) store
    of a pointer value such that upon dependency misprediction the CPU then
    speculatively executes the load of the pointer value and retrieves the zero
    value instead of the attacker controlled scalar value previously stored at
    that location, meaning, subsequent access in the speculative domain is then
    redirected to the "zero page".
    
    The sanitized preemptive store of zero prior to the actual "slow" store is
    done through a simple ST instruction based on r10 (frame pointer) with
    relative offset to the stack location that the verifier has been tracking
    on the original used register for STX, which does not have to be r10. Thus,
    there are no memory dependencies for this store, since it's only using r10
    and immediate constant of zero; hence af86ca4e3088 /assumed/ a low latency
    operation.
    
    However, a recent attack demonstrated that this mitigation is not sufficient
    since the preemptive store of zero could also be turned into a "slow" store
    and is thus bypassed as well:
    
      [...]
      // r2 = oob address (e.g. scalar)
      // r7 = pointer to map value
      31: (7b) *(u64 *)(r10 -16) = r2
      // r9 will remain "fast" register, r10 will become "slow" register below
      32: (bf) r9 = r10
      // JIT maps BPF reg to x86 reg:
      //  r9  -> r15 (callee saved)
      //  r10 -> rbp
      // train store forward prediction to break dependency link between both r9
      // and r10 by evicting them from the predictor's LRU table.
      33: (61) r0 = *(u32 *)(r7 +24576)
      34: (63) *(u32 *)(r7 +29696) = r0
      35: (61) r0 = *(u32 *)(r7 +24580)
      36: (63) *(u32 *)(r7 +29700) = r0
      37: (61) r0 = *(u32 *)(r7 +24584)
      38: (63) *(u32 *)(r7 +29704) = r0
      39: (61) r0 = *(u32 *)(r7 +24588)
      40: (63) *(u32 *)(r7 +29708) = r0
      [...]
      543: (61) r0 = *(u32 *)(r7 +25596)
      544: (63) *(u32 *)(r7 +30716) = r0
      // prepare call to bpf_ringbuf_output() helper. the latter will cause rbp
      // to spill to stack memory while r13/r14/r15 (all callee saved regs) remain
      // in hardware registers. rbp becomes slow due to push/pop latency. below is
      // disasm of bpf_ringbuf_output() helper for better visual context:
      //
      // ffffffff8117ee20: 41 54                 push   r12
      // ffffffff8117ee22: 55                    push   rbp
      // ffffffff8117ee23: 53                    push   rbx
      // ffffffff8117ee24: 48 f7 c1 fc ff ff ff  test   rcx,0xfffffffffffffffc
      // ffffffff8117ee2b: 0f 85 af 00 00 00     jne    ffffffff8117eee0 <-- jump taken
      // [...]
      // ffffffff8117eee0: 49 c7 c4 ea ff ff ff  mov    r12,0xffffffffffffffea
      // ffffffff8117eee7: 5b                    pop    rbx
      // ffffffff8117eee8: 5d                    pop    rbp
      // ffffffff8117eee9: 4c 89 e0              mov    rax,r12
      // ffffffff8117eeec: 41 5c                 pop    r12
      // ffffffff8117eeee: c3                    ret
      545: (18) r1 = map[id:4]
      547: (bf) r2 = r7
      548: (b7) r3 = 0
      549: (b7) r4 = 4
      550: (85) call bpf_ringbuf_output#194288
      // instruction 551 inserted by verifier    \
      551: (7a) *(u64 *)(r10 -16) = 0            | /both/ are now slow stores here
      // storing map value pointer r7 at fp-16   | since value of r10 is "slow".
      552: (7b) *(u64 *)(r10 -16) = r7           /
      // following "fast" read to the same memory location, but due to dependency
      // misprediction it will speculatively execute before insn 551/552 completes.
      553: (79) r2 = *(u64 *)(r9 -16)
      // in speculative domain contains attacker controlled r2. in non-speculative
      // domain this contains r7, and thus accesses r7 +0 below.
      554: (71) r3 = *(u8 *)(r2 +0)
      // leak r3
    
    As can be seen, the current speculative store bypass mitigation which the
    verifier inserts at line 551 is insufficient since /both/, the write of
    the zero sanitation as well as the map value pointer are a high latency
    instruction due to prior memory access via push/pop of r10 (rbp) in contrast
    to the low latency read in line 553 as r9 (r15) which stays in hardware
    registers. Thus, architecturally, fp-16 is r7, however, microarchitecturally,
    fp-16 can still be r2.
    
    Initial thoughts to address this issue was to track spilled pointer loads
    from stack and enforce their load via LDX through r10 as well so that /both/
    the preemptive store of zero /as well as/ the load use the /same/ register
    such that a dependency is created between the store and load. However, this
    option is not sufficient either since it can be bypassed as well under
    speculation. An updated attack with pointer spill/fills now _all_ based on
    r10 would look as follows:
    
      [...]
      // r2 = oob address (e.g. scalar)
      // r7 = pointer to map value
      [...]
      // longer store forward prediction training sequence than before.
      2062: (61) r0 = *(u32 *)(r7 +25588)
      2063: (63) *(u32 *)(r7 +30708) = r0
      2064: (61) r0 = *(u32 *)(r7 +25592)
      2065: (63) *(u32 *)(r7 +30712) = r0
      2066: (61) r0 = *(u32 *)(r7 +25596)
      2067: (63) *(u32 *)(r7 +30716) = r0
      // store the speculative load address (scalar) this time after the store
      // forward prediction training.
      2068: (7b) *(u64 *)(r10 -16) = r2
      // preoccupy the CPU store port by running sequence of dummy stores.
      2069: (63) *(u32 *)(r7 +29696) = r0
      2070: (63) *(u32 *)(r7 +29700) = r0
      2071: (63) *(u32 *)(r7 +29704) = r0
      2072: (63) *(u32 *)(r7 +29708) = r0
      2073: (63) *(u32 *)(r7 +29712) = r0
      2074: (63) *(u32 *)(r7 +29716) = r0
      2075: (63) *(u32 *)(r7 +29720) = r0
      2076: (63) *(u32 *)(r7 +29724) = r0
      2077: (63) *(u32 *)(r7 +29728) = r0
      2078: (63) *(u32 *)(r7 +29732) = r0
      2079: (63) *(u32 *)(r7 +29736) = r0
      2080: (63) *(u32 *)(r7 +29740) = r0
      2081: (63) *(u32 *)(r7 +29744) = r0
      2082: (63) *(u32 *)(r7 +29748) = r0
      2083: (63) *(u32 *)(r7 +29752) = r0
      2084: (63) *(u32 *)(r7 +29756) = r0
      2085: (63) *(u32 *)(r7 +29760) = r0
      2086: (63) *(u32 *)(r7 +29764) = r0
      2087: (63) *(u32 *)(r7 +29768) = r0
      2088: (63) *(u32 *)(r7 +29772) = r0
      2089: (63) *(u32 *)(r7 +29776) = r0
      2090: (63) *(u32 *)(r7 +29780) = r0
      2091: (63) *(u32 *)(r7 +29784) = r0
      2092: (63) *(u32 *)(r7 +29788) = r0
      2093: (63) *(u32 *)(r7 +29792) = r0
      2094: (63) *(u32 *)(r7 +29796) = r0
      2095: (63) *(u32 *)(r7 +29800) = r0
      2096: (63) *(u32 *)(r7 +29804) = r0
      2097: (63) *(u32 *)(r7 +29808) = r0
      2098: (63) *(u32 *)(r7 +29812) = r0
      // overwrite scalar with dummy pointer; same as before, also including the
      // sanitation store with 0 from the current mitigation by the verifier.
      2099: (7a) *(u64 *)(r10 -16) = 0         | /both/ are now slow stores here
      2100: (7b) *(u64 *)(r10 -16) = r7        | since store unit is still busy.
      // load from stack intended to bypass stores.
      2101: (79) r2 = *(u64 *)(r10 -16)
      2102: (71) r3 = *(u8 *)(r2 +0)
      // leak r3
      [...]
    
    Looking at the CPU microarchitecture, the scheduler might issue loads (such
    as seen in line 2101) before stores (line 2099,2100) because the load execution
    units become available while the store execution unit is still busy with the
    sequence of dummy stores (line 2069-2098). And so the load may use the prior
    stored scalar from r2 at address r10 -16 for speculation. The updated attack
    may work less reliable on CPU microarchitectures where loads and stores share
    execution resources.
    
    This concludes that the sanitizing with zero stores from af86ca4e3088 ("bpf:
    Prevent memory disambiguation attack") is insufficient. Moreover, the detection
    of stack reuse from af86ca4e3088 where previously data (STACK_MISC) has been
    written to a given stack slot where a pointer value is now to be stored does
    not have sufficient coverage as precondition for the mitigation either; for
    several reasons outlined as follows:
    
     1) Stack content from prior program runs could still be preserved and is
        therefore not "random", best example is to split a speculative store
        bypass attack between tail calls, program A would prepare and store the
        oob address at a given stack slot and then tail call into program B which
        does the "slow" store of a pointer to the stack with subsequent "fast"
        read. From program B PoV such stack slot type is STACK_INVALID, and
        therefore also must be subject to mitigation.
    
     2) The STACK_SPILL must not be coupled to register_is_const(&stack->spilled_ptr)
        condition, for example, the previous content of that memory location could
        also be a pointer to map or map value. Without the fix, a speculative
        store bypass is not mitigated in such precondition and can then lead to
        a type confusion in the speculative domain leaking kernel memory near
        these pointer types.
    
    While brainstorming on various alternative mitigation possibilities, we also
    stumbled upon a retrospective from Chrome developers [0]:
    
      [...] For variant 4, we implemented a mitigation to zero the unused memory
      of the heap prior to allocation, which cost about 1% when done concurrently
      and 4% for scavenging. Variant 4 defeats everything we could think of. We
      explored more mitigations for variant 4 but the threat proved to be more
      pervasive and dangerous than we anticipated. For example, stack slots used
      by the register allocator in the optimizing compiler could be subject to
      type confusion, leading to pointer crafting. Mitigating type confusion for
      stack slots alone would have required a complete redesign of the backend of
      the optimizing compiler, perhaps man years of work, without a guarantee of
      completeness. [...]
    
    >From BPF side, the problem space is reduced, however, options are rather
    limited. One idea that has been explored was to xor-obfuscate pointer spills
    to the BPF stack:
    
      [...]
      // preoccupy the CPU store port by running sequence of dummy stores.
      [...]
      2106: (63) *(u32 *)(r7 +29796) = r0
      2107: (63) *(u32 *)(r7 +29800) = r0
      2108: (63) *(u32 *)(r7 +29804) = r0
      2109: (63) *(u32 *)(r7 +29808) = r0
      2110: (63) *(u32 *)(r7 +29812) = r0
      // overwrite scalar with dummy pointer; xored with random 'secret' value
      // of 943576462 before store ...
      2111: (b4) w11 = 943576462
      2112: (af) r11 ^= r7
      2113: (7b) *(u64 *)(r10 -16) = r11
      2114: (79) r11 = *(u64 *)(r10 -16)
      2115: (b4) w2 = 943576462
      2116: (af) r2 ^= r11
      // ... and restored with the same 'secret' value with the help of AX reg.
      2117: (71) r3 = *(u8 *)(r2 +0)
      [...]
    
    While the above would not prevent speculation, it would make data leakage
    infeasible by directing it to random locations. In order to be effective
    and prevent type confusion under speculation, such random secret would have
    to be regenerated for each store. The additional complexity involved for a
    tracking mechanism that prevents jumps such that restoring spilled pointers
    would not get corrupted is not worth the gain for unprivileged. Hence, the
    fix in here eventually opted for emitting a non-public BPF_ST | BPF_NOSPEC
    instruction which the x86 JIT translates into a lfence opcode. Inserting the
    latter in between the store and load instruction is one of the mitigations
    options [1]. The x86 instruction manual notes:
    
      [...] An LFENCE that follows an instruction that stores to memory might
      complete before the data being stored have become globally visible. [...]
    
    The latter meaning that the preceding store instruction finished execution
    and the store is at minimum guaranteed to be in the CPU's store queue, but
    it's not guaranteed to be in that CPU's L1 cache at that point (globally
    visible). The latter would only be guaranteed via sfence. So the load which
    is guaranteed to execute after the lfence for that local CPU would have to
    rely on store-to-load forwarding. [2], in section 2.3 on store buffers says:
    
      [...] For every store operation that is added to the ROB, an entry is
      allocated in the store buffer. This entry requires both the virtual and
      physical address of the target. Only if there is no free entry in the store
      buffer, the frontend stalls until there is an empty slot available in the
      store buffer again. Otherwise, the CPU can immediately continue adding
      subsequent instructions to the ROB and execute them out of order. On Intel
      CPUs, the store buffer has up to 56 entries. [...]
    
    One small upside on the fix is that it lifts constraints from af86ca4e3088
    where the sanitize_stack_off relative to r10 must be the same when coming
    from different paths. The BPF_ST | BPF_NOSPEC gets emitted after a BPF_STX
    or BPF_ST instruction. This happens either when we store a pointer or data
    value to the BPF stack for the first time, or upon later pointer spills.
    The former needs to be enforced since otherwise stale stack data could be
    leaked under speculation as outlined earlier. For non-x86 JITs the BPF_ST |
    BPF_NOSPEC mapping is currently optimized away, but others could emit a
    speculation barrier as well if necessary. For real-world unprivileged
    programs e.g. generated by LLVM, pointer spill/fill is only generated upon
    register pressure and LLVM only tries to do that for pointers which are not
    used often. The program main impact will be the initial BPF_ST | BPF_NOSPEC
    sanitation for the STACK_INVALID case when the first write to a stack slot
    occurs e.g. upon map lookup. In future we might refine ways to mitigate
    the latter cost.
    
      [0] https://arxiv.org/pdf/1902.05178.pdf
      [1] https://msrc-blog.microsoft.com/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/
      [2] https://arxiv.org/pdf/1905.05725.pdf
    
    Fixes: af86ca4e3088 ("bpf: Prevent memory disambiguation attack")
    Fixes: f7cf25b2026d ("bpf: track spill/fill of constants")
    Co-developed-by: Piotr Krysiuk <piotras@gmail.com>
    Co-developed-by: Benedict Schlueter <benedict.schlueter@rub.de>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
    Signed-off-by: Benedict Schlueter <benedict.schlueter@rub.de>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [OP: - apply check_stack_write_fixed_off() changes in check_stack_write()
         - replace env->bypass_spec_v4 -> env->allow_ptr_leaks]
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e80c3533c354ede56146ab0e4fbb8304d0c1209f
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Sep 7 16:16:58 2021 +0300

    bpf: Introduce BPF nospec instruction for mitigating Spectre v4
    
    commit f5e81d1117501546b7be050c5fbafa6efd2c722c upstream.
    
    In case of JITs, each of the JIT backends compiles the BPF nospec instruction
    /either/ to a machine instruction which emits a speculation barrier /or/ to
    /no/ machine instruction in case the underlying architecture is not affected
    by Speculative Store Bypass or has different mitigations in place already.
    
    This covers both x86 and (implicitly) arm64: In case of x86, we use 'lfence'
    instruction for mitigation. In case of arm64, we rely on the firmware mitigation
    as controlled via the ssbd kernel parameter. Whenever the mitigation is enabled,
    it works for all of the kernel code with no need to provide any additional
    instructions here (hence only comment in arm64 JIT). Other archs can follow
    as needed. The BPF nospec instruction is specifically targeting Spectre v4
    since i) we don't use a serialization barrier for the Spectre v1 case, and
    ii) mitigation instructions for v1 and v4 might be different on some archs.
    
    The BPF nospec is required for a future commit, where the BPF verifier does
    annotate intermediate BPF programs with speculation barriers.
    
    Co-developed-by: Piotr Krysiuk <piotras@gmail.com>
    Co-developed-by: Benedict Schlueter <benedict.schlueter@rub.de>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
    Signed-off-by: Benedict Schlueter <benedict.schlueter@rub.de>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [OP: - adjusted context for 5.4
         - apply riscv changes to /arch/riscv/net/bpf_jit_comp.c]
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c9424a765afa20c023d42018d1f5c3d9158a9c3
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 30 19:02:10 2021 -0700

    ipv4: fix endianness issue in inet_rtm_getroute_build_skb()
    
    [ Upstream commit 92548b0ee220e000d81c27ac9a80e0ede895a881 ]
    
    The UDP length field should be in network order.
    This removes the following sparse error:
    
    net/ipv4/route.c:3173:27: warning: incorrect type in assignment (different base types)
    net/ipv4/route.c:3173:27:    expected restricted __be16 [usertype] len
    net/ipv4/route.c:3173:27:    got unsigned long
    
    Fixes: 404eb77ea766 ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Roopa Prabhu <roopa@nvidia.com>
    Cc: David Ahern <dsahern@kernel.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3fe6d19212660b14e8bdc327aee7b0e337b2fb8
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Mon Aug 30 23:30:43 2021 +0530

    octeontx2-af: Fix loop in free and unmap counter
    
    [ Upstream commit 6537e96d743b89294b397b4865c6c061abae31b0 ]
    
    When the given counter does not belong to the entry
    then code ends up in infinite loop because the loop
    cursor, entry is not getting updated further. This
    patch fixes that by updating entry for every iteration.
    
    Fixes: a958dd59f9ce ("octeontx2-af: Map or unmap NPC MCAM entry and counter")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8216d7157bcf50f492a63caef1293cf8dd937a79
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Sat Aug 28 16:23:15 2021 +0200

    net: qualcomm: fix QCA7000 checksum handling
    
    [ Upstream commit 429205da6c834447a57279af128bdd56ccd5225e ]
    
    Based on tests the QCA7000 doesn't support checksum offloading. So assume
    ip_summed is CHECKSUM_NONE and let the kernel take care of the checksum
    handling. This fixes data transfer issues in noisy environments.
    
    Reported-by: Michael Heimpold <michael.heimpold@in-tech.com>
    Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4648917e499c93e228e72bce36fa68a9244bac94
Author: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Date:   Sun Aug 29 23:58:01 2021 +0800

    net: sched: Fix qdisc_rate_table refcount leak when get tcf_block failed
    
    [ Upstream commit c66070125837900163b81a03063ddd657a7e9bfb ]
    
    The reference counting issue happens in one exception handling path of
    cbq_change_class(). When failing to get tcf_block, the function forgets
    to decrease the refcount of "rtab" increased by qdisc_put_rtab(),
    causing a refcount leak.
    
    Fix this issue by jumping to "failure" label when get tcf_block failed.
    
    Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Link: https://lore.kernel.org/r/1630252681-71588-1-git-send-email-xiyuyang19@fudan.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e46e23c289f62ccd8e2230d9ce652072d777ff30
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Aug 29 15:16:15 2021 -0700

    ipv4: make exception cache less predictible
    
    [ Upstream commit 67d6d681e15b578c1725bad8ad079e05d1c48a8e ]
    
    Even after commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in
    fnhe_hashfun()"), an attacker can still use brute force to learn
    some secrets from a victim linux host.
    
    One way to defeat these attacks is to make the max depth of the hash
    table bucket a random value.
    
    Before this patch, each bucket of the hash table used to store exceptions
    could contain 6 items under attack.
    
    After the patch, each bucket would contains a random number of items,
    between 6 and 10. The attacker can no longer infer secrets.
    
    This is slightly increasing memory size used by the hash table,
    by 50% in average, we do not expect this to be a problem.
    
    This patch is more complex than the prior one (IPv6 equivalent),
    because IPv4 was reusing the oldest entry.
    Since we need to be able to evict more than one entry per
    update_or_create_fnhe() call, I had to replace
    fnhe_oldest() with fnhe_remove_oldest().
    
    Also note that we will queue extra kfree_rcu() calls under stress,
    which hopefully wont be a too big issue.
    
    Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Keyu Man <kman001@ucr.edu>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Tested-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f73cbdd1b8e7ea32c66138426f826c8734b70c18
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Aug 29 15:16:14 2021 -0700

    ipv6: make exception cache less predictible
    
    [ Upstream commit a00df2caffed3883c341d5685f830434312e4a43 ]
    
    Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"),
    an attacker can still use brute force to learn some secrets from a victim
    linux host.
    
    One way to defeat these attacks is to make the max depth of the hash
    table bucket a random value.
    
    Before this patch, each bucket of the hash table used to store exceptions
    could contain 6 items under attack.
    
    After the patch, each bucket would contains a random number of items,
    between 6 and 10. The attacker can no longer infer secrets.
    
    This is slightly increasing memory size used by the hash table,
    we do not expect this to be a problem.
    
    Following patch is dealing with the same issue in IPv4.
    
    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Keyu Man <kman001@ucr.edu>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa167dcde4c78a7670c5c8992074d3cbec4e18e7
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Tue Aug 17 08:35:22 2021 +0200

    brcmfmac: pcie: fix oops on failure to resume and reprobe
    
    [ Upstream commit d745ca4f2c4ae9f1bd8cf7d8ac6e22d739bffd19 ]
    
    When resuming from suspend, brcmf_pcie_pm_leave_D3 will first attempt a
    hot resume and then fall back to removing the PCI device and then
    reprobing. If this probe fails, the kernel will oops, because brcmf_err,
    which is called to report the failure will dereference the stale bus
    pointer. Open code and use the default bus-less brcmf_err to avoid this.
    
    Fixes: 8602e62441ab ("brcmfmac: pass bus to the __brcmf_err() in pcie.c")
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210817063521.22450-1-a.fatoum@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5debec63a28fbdd654753c86c8ea42f1df34fc2c
Author: Zenghui Yu <yuzenghui@huawei.com>
Date:   Tue Jul 27 10:52:31 2021 +0800

    bcma: Fix memory leak for internally-handled cores
    
    [ Upstream commit b63aed3ff195130fef12e0af590f4838cf0201d8 ]
    
    kmemleak reported that dev_name() of internally-handled cores were leaked
    on driver unbinding. Let's use device_initialize() to take refcounts for
    them and put_device() to properly free the related stuff.
    
    While looking at it, there's another potential issue for those which should
    be *registered* into driver core. If device_register() failed, we put
    device once and freed bcma_device structures. In bcma_unregister_cores(),
    they're treated as unregistered and we hit both UAF and double-free. That
    smells not good and has also been fixed now.
    
    Fixes: ab54bc8460b5 ("bcma: fill core details for every device")
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210727025232.663-2-yuzenghui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 574e563649ecaf437002b0b793474f11f97af0cb
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 13 14:34:38 2021 +0300

    ath6kl: wmi: fix an error code in ath6kl_wmi_sync_point()
    
    [ Upstream commit fd6729ec534cffbbeb3917761e6d1fe6a412d3fe ]
    
    This error path is unlikely because of it checked for NULL and
    returned -ENOMEM earlier in the function.  But it should return
    an error code here as well if we ever do hit it because of a
    race condition or something.
    
    Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210813113438.GB30697@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d946e685d6b7aaa9f827c89c353a0661822eba4a
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Aug 16 07:25:28 2021 +0200

    ASoC: wcd9335: Disable irq on slave ports in the remove function
    
    [ Upstream commit d3efd26af2e044ff2b48d38bb871630282d77e60 ]
    
    The probe calls 'wcd9335_setup_irqs()' to enable interrupts on all slave
    ports.
    This must be undone in the remove function.
    
    Add a 'wcd9335_teardown_irqs()' function that undoes 'wcd9335_setup_irqs()'
    function, and call it from the remove function.
    
    Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Message-Id: <8f761244d79bd4c098af8a482be9121d3a486d1b.1629091028.git.christophe.jaillet@wanadoo.fr>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3ec07f832bb6b48d4584ac8b26e1e30a685011c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Aug 16 07:25:20 2021 +0200

    ASoC: wcd9335: Fix a memory leak in the error handling path of the probe function
    
    [ Upstream commit fc6fc81caa63900cef9ebb8b2e365c3ed5a9effb ]
    
    If 'wcd9335_setup_irqs()' fails, me must release the memory allocated in
    'wcd_clsh_ctrl_alloc()', as already done in the remove function.
    
    Add an error handling path and the missing 'wcd_clsh_ctrl_free()' call.
    
    Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Message-Id: <6dc12372f09fabb70bf05941dbe6a1382dc93e43.1629091028.git.christophe.jaillet@wanadoo.fr>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6088f4ed3fc5a443dcaeb5ee2cfbb29ef22500f
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Aug 16 07:25:10 2021 +0200

    ASoC: wcd9335: Fix a double irq free in the remove function
    
    [ Upstream commit 7a6a723e98aa45f393e6add18f7309dfffa1b0e2 ]
    
    There is no point in calling 'free_irq()' explicitly for
    'WCD9335_IRQ_SLIMBUS' in the remove function.
    
    The irqs are requested in 'wcd9335_setup_irqs()' using a resource managed
    function (i.e. 'devm_request_threaded_irq()').
    'wcd9335_setup_irqs()' requests all what is defined in the 'wcd9335_irqs'
    structure.
    This structure has only one entry for 'WCD9335_IRQ_SLIMBUS'.
    
    So 'devm_request...irq()' + explicit 'free_irq()' would lead to a double
    free.
    
    Remove the unneeded 'free_irq()' from the remove function.
    
    Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Message-Id: <0614d63bc00edd7e81dd367504128f3d84f72efa.1629091028.git.christophe.jaillet@wanadoo.fr>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bfa680f3b478e699ba96f9809384502d6f386e7
Author: Andy Duan <fugang.duan@nxp.com>
Date:   Thu Aug 19 10:10:33 2021 +0800

    tty: serial: fsl_lpuart: fix the wrong mapbase value
    
    [ Upstream commit d5c38948448abc2bb6b36dbf85a554bf4748885e ]
    
    Register offset needs to be applied on mapbase also.
    dma_tx/rx_request use the physical address of UARTDATA.
    Register offset is currently only applied to membase (the
    corresponding virtual addr) but not on mapbase.
    
    Fixes: 24b1e5f0e83c ("tty: serial: lpuart: add imx7ulp support")
    Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
    Signed-off-by: Adriana Reus <adriana.reus@nxp.com>
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Signed-off-by: Andy Duan <fugang.duan@nxp.com>
    Link: https://lore.kernel.org/r/20210819021033.32606-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f1375fa693b5c64253e71b843ebd4847706b77c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Aug 18 21:32:38 2021 +0200

    usb: bdc: Fix an error handling path in 'bdc_probe()' when no suitable DMA config is available
    
    [ Upstream commit d2f42e09393c774ab79088d8e3afcc62b3328fc9 ]
    
    If no suitable DMA configuration is available, a previous 'bdc_phy_init()'
    call must be undone by a corresponding 'bdc_phy_exit()' call.
    
    Branch to the existing error handling path instead of returning
    directly.
    
    Fixes: cc29d4f67757 ("usb: bdc: Add support for USB phy")
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/0c5910979f39225d5d8fe68c9ab1c147c68ddee1.1629314734.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06203abb72752d403edab644d0283f9a3c6497a9
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Wed Aug 25 20:09:02 2021 +0300

    usb: ehci-orion: Handle errors of clk_prepare_enable() in probe
    
    [ Upstream commit 4720f1bf4ee4a784d9ece05420ba33c9222a3004 ]
    
    ehci_orion_drv_probe() did not account for possible errors of
    clk_prepare_enable() that in particular could cause invocation of
    clk_disable_unprepare() on clocks that were not prepared/enabled yet,
    e.g. in remove or on handling errors of usb_add_hcd() in probe. Though,
    there were several patches fixing different issues with clocks in this
    driver, they did not solve this problem.
    
    Add handling of errors of clk_prepare_enable() in ehci_orion_drv_probe()
    to avoid calls of clk_disable_unprepare() without previous successful
    invocation of clk_prepare_enable().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: 8c869edaee07 ("ARM: Orion: EHCI: Add support for enabling clocks")
    Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
    Link: https://lore.kernel.org/r/20210825170902.11234-1-novikov@ispras.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0a9ecca2dc4d97f122fcdb26f737d7d67c655b8
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sun Jul 4 17:38:45 2021 +0300

    i2c: mt65xx: fix IRQ check
    
    [ Upstream commit 58fb7c643d346e2364404554f531cfa6a1a3917c ]
    
    Iff platform_get_irq() returns 0, the driver's probe() method will return 0
    early (as if the method's call was successful).  Let's consider IRQ0 valid
    for simplicity -- devm_request_irq() can always override that decision...
    
    Fixes: ce38815d39ea ("I2C: mediatek: Add driver for MediaTek I2C controller")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
    Reviewed-by: Qii Wang <qii.wang@mediatek.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b444064a0e0ef64491b8739a9ae05a952b5f8974
Author: Len Baker <len.baker@gmx.com>
Date:   Tue Aug 17 12:27:09 2021 +0200

    CIFS: Fix a potencially linear read overflow
    
    [ Upstream commit f980d055a0f858d73d9467bb0b570721bbfcdfb8 ]
    
    strlcpy() reads the entire source buffer first. This read may exceed the
    destination size limit. This is both inefficient and can lead to linear
    read overflows if a source string is not NUL-terminated.
    
    Also, the strnlen() call does not avoid the read overflow in the strlcpy
    function when a not NUL-terminated string is passed.
    
    So, replace this block by a call to kstrndup() that avoids this type of
    overflow and does the same.
    
    Fixes: 066ce6899484d ("cifs: rename cifs_strlcpy_to_host and make it use new functions")
    Signed-off-by: Len Baker <len.baker@gmx.com>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e37eeaf9506c543e43c2a503720ecd6ba1270747
Author: Andrey Ignatov <rdna@fb.com>
Date:   Fri Aug 20 09:39:35 2021 -0700

    bpf: Fix possible out of bound write in narrow load handling
    
    [ Upstream commit d7af7e497f0308bc97809cc48b58e8e0f13887e1 ]
    
    Fix a verifier bug found by smatch static checker in [0].
    
    This problem has never been seen in prod to my best knowledge. Fixing it
    still seems to be a good idea since it's hard to say for sure whether
    it's possible or not to have a scenario where a combination of
    convert_ctx_access() and a narrow load would lead to an out of bound
    write.
    
    When narrow load is handled, one or two new instructions are added to
    insn_buf array, but before it was only checked that
    
            cnt >= ARRAY_SIZE(insn_buf)
    
    And it's safe to add a new instruction to insn_buf[cnt++] only once. The
    second try will lead to out of bound write. And this is what can happen
    if `shift` is set.
    
    Fix it by making sure that if the BPF_RSH instruction has to be added in
    addition to BPF_AND then there is enough space for two more instructions
    in insn_buf.
    
    The full report [0] is below:
    
    kernel/bpf/verifier.c:12304 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array
    kernel/bpf/verifier.c:12311 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array
    
    kernel/bpf/verifier.c
        12282
        12283                       insn->off = off & ~(size_default - 1);
        12284                       insn->code = BPF_LDX | BPF_MEM | size_code;
        12285               }
        12286
        12287               target_size = 0;
        12288               cnt = convert_ctx_access(type, insn, insn_buf, env->prog,
        12289                                        &target_size);
        12290               if (cnt == 0 || cnt >= ARRAY_SIZE(insn_buf) ||
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Bounds check.
    
        12291                   (ctx_field_size && !target_size)) {
        12292                       verbose(env, "bpf verifier is misconfigured\n");
        12293                       return -EINVAL;
        12294               }
        12295
        12296               if (is_narrower_load && size < target_size) {
        12297                       u8 shift = bpf_ctx_narrow_access_offset(
        12298                               off, size, size_default) * 8;
        12299                       if (ctx_field_size <= 4) {
        12300                               if (shift)
        12301                                       insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
                                                             ^^^^^
    increment beyond end of array
    
        12302                                                                       insn->dst_reg,
        12303                                                                       shift);
    --> 12304                               insn_buf[cnt++] = BPF_ALU32_IMM(BPF_AND, insn->dst_reg,
                                                     ^^^^^
    out of bounds write
    
        12305                                                               (1 << size * 8) - 1);
        12306                       } else {
        12307                               if (shift)
        12308                                       insn_buf[cnt++] = BPF_ALU64_IMM(BPF_RSH,
        12309                                                                       insn->dst_reg,
        12310                                                                       shift);
        12311                               insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg,
                                            ^^^^^^^^^^^^^^^
    Same.
    
        12312                                                               (1ULL << size * 8) - 1);
        12313                       }
        12314               }
        12315
        12316               new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
        12317               if (!new_prog)
        12318                       return -ENOMEM;
        12319
        12320               delta += cnt - 1;
        12321
        12322               /* keep walking new program and skip insns we just inserted */
        12323               env->prog = new_prog;
        12324               insn      = new_prog->insnsi + i + delta;
        12325       }
        12326
        12327       return 0;
        12328 }
    
    [0] https://lore.kernel.org/bpf/20210817050843.GA21456@kili/
    
    v1->v2:
    - clarify that problem was only seen by static checker but not in prod;
    
    Fixes: 46f53a65d2de ("bpf: Allow narrow loads with offset > 0")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Andrey Ignatov <rdna@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20210820163935.1902398-1-rdna@fb.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb8e695e9cfa47864c5df8f1c15c2a4b8cf753f2
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Aug 10 11:16:44 2021 +0300

    mmc: moxart: Fix issue with uninitialized dma_slave_config
    
    [ Upstream commit ee5165354d498e5bceb0b386e480ac84c5f8c28c ]
    
    Depending on the DMA driver being used, the struct dma_slave_config may
    need to be initialized to zero for the unused data.
    
    For example, we have three DMA drivers using src_port_window_size and
    dst_port_window_size. If these are left uninitialized, it can cause DMA
    failures.
    
    For moxart, this is probably not currently an issue but is still good to
    fix though.
    
    Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
    Cc: Jonas Jensen <jonas.jensen@gmail.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210810081644.19353-3-tony@atomide.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48b1f117e8d0a049135e178c11beb7c08fcd81c3
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Aug 10 11:16:43 2021 +0300

    mmc: dw_mmc: Fix issue with uninitialized dma_slave_config
    
    [ Upstream commit c3ff0189d3bc9c03845fe37472c140f0fefd0c79 ]
    
    Depending on the DMA driver being used, the struct dma_slave_config may
    need to be initialized to zero for the unused data.
    
    For example, we have three DMA drivers using src_port_window_size and
    dst_port_window_size. If these are left uninitialized, it can cause DMA
    failures.
    
    For dw_mmc, this is probably not currently an issue but is still good to
    fix though.
    
    Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support")
    Cc: Shawn Lin <shawn.lin@rock-chips.com>
    Cc: Jaehoon Chung <jh80.chung@samsung.com>
    Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210810081644.19353-2-tony@atomide.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57314d8414d1e489110c7e8827a637e88c1d3869
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Wed Aug 18 09:57:35 2021 +0200

    ASoC: Intel: Skylake: Fix module resource and format selection
    
    [ Upstream commit e8b374b649afe756c2470e0e6668022e90bf8518 ]
    
    Module configuration may differ between its instances depending on
    resources required and input and output audio format. Available
    parameters to select from are stored in module resource and interface
    (format) lists. These come from topology, together with description of
    each of pipe's modules.
    
    Ignoring index value provided by topology and relying always on 0th
    entry leads to unexpected module behavior due to under/overbudged
    resources assigned or impropper format selection. Fix by taking entry at
    index specified by topology.
    
    Fixes: f6fa56e22559 ("ASoC: Intel: Skylake: Parse and update module config structure")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Tested-by: Lukasz Majczak <lma@semihalf.com>
    Link: https://lore.kernel.org/r/20210818075742.1515155-5-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92397571c2434b271be10b9eba37a2b5f98f9471
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Wed Aug 18 09:57:33 2021 +0200

    ASoC: Intel: Skylake: Leave data as is when invoking TLV IPCs
    
    [ Upstream commit 126b3422adc80f29d2129db7f61e0113a8a526c6 ]
    
    Advancing pointer initially fixed issue for some users but caused
    regression for others. Leave data as it to make it easier for end users
    to adjust their topology files if needed.
    
    Fixes: a8cd7066f042 ("ASoC: Intel: Skylake: Strip T and L from TLV IPCs")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Tested-by: Lukasz Majczak <lma@semihalf.com>
    Link: https://lore.kernel.org/r/20210818075742.1515155-3-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b58cf18e384d8af26f316ddb4b3ad9c08befa70d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Aug 16 21:39:47 2021 +0300

    rsi: fix an error code in rsi_probe()
    
    [ Upstream commit 9adcdf6758d7c4c9bdaf22d78eb9fcae260ed113 ]
    
    Return -ENODEV instead of success for unsupported devices.
    
    Fixes: 54fdb318c111 ("rsi: add new device model for 9116")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210816183947.GA2119@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d82fe3dd0b0f1d386261aba9ec1ed025368b403c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 5 13:37:46 2021 +0300

    rsi: fix error code in rsi_load_9116_firmware()
    
    [ Upstream commit d0f8430332a16c7baa80ce2886339182c5d85f37 ]
    
    This code returns success if the kmemdup() fails, but obviously it
    should return -ENOMEM instead.
    
    Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210805103746.GA26417@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4be8deab6f0d0e42ab85f9dda7c32eb29d82d815
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sun Jul 4 17:45:25 2021 +0300

    i2c: s3c2410: fix IRQ check
    
    [ Upstream commit d6840a5e370b7ea4fde16ce2caf431bcc87f9a75 ]
    
    Iff platform_get_irq() returns 0, the driver's probe() method will return 0
    early (as if the method's call was successful).  Let's consider IRQ0 valid
    for simplicity -- devm_request_irq() can always override that decision...
    
    Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da3e5f32049a30b90b70f1bf3635376611cc6e5d
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Thu Aug 12 23:35:09 2021 +0300

    i2c: iop3xx: fix deferred probing
    
    [ Upstream commit a1299505162ad00def3573260c2c68b9c8e8d697 ]
    
    When adding the code to handle platform_get_irq*() errors in the commit
    489447380a29 ("handle errors returned by platform_get_irq*()"), the
    actual error code was enforced to be -ENXIO in the driver for some
    strange reason.  This didn't matter much until the deferred probing was
    introduced -- which requires an actual error code to be propagated
    upstream from the failure site.
    
    While fixing this, also stop overriding the errors from request_irq() to
    -EIO (done since the pre-git era).
    
    Fixes: 489447380a29 ("[PATCH] handle errors returned by platform_get_irq*()")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2da3272ae0ea12658e39fd2ddc5691474627f25f
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Aug 19 18:15:21 2021 +0300

    Bluetooth: add timeout sanity check to hci_inquiry
    
    [ Upstream commit f41a4b2b5eb7872109723dab8ae1603bdd9d9ec1 ]
    
    Syzbot hit "task hung" bug in hci_req_sync(). The problem was in
    unreasonable huge inquiry timeout passed from userspace.
    Fix it by adding sanity check for timeout value to hci_inquiry().
    
    Since hci_inquiry() is the only user of hci_req_sync() with user
    controlled timeout value, it makes sense to check timeout value in
    hci_inquiry() and don't touch hci_req_sync().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: syzbot+be2baed593ea56c6a84c@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70d71611eb839d1345e8ce75e67b78e55169e365
Author: Xu Yu <xuyu@linux.alibaba.com>
Date:   Wed Aug 18 12:47:52 2021 -0700

    mm/swap: consider max pages in iomap_swapfile_add_extent
    
    [ Upstream commit 36ca7943ac18aebf8aad4c50829eb2ea5ec847df ]
    
    When the max pages (last_page in the swap header + 1) is smaller than
    the total pages (inode size) of the swapfile, iomap_swapfile_activate
    overwrites sis->max with total pages.
    
    However, frontswap_map is a swap page state bitmap allocated using the
    initial sis->max page count read from the swap header.  If swapfile
    activation increases sis->max, it's possible for the frontswap code to
    walk off the end of the bitmap, thereby corrupting kernel memory.
    
    [djwong: modify the description a bit; the original paragraph reads:
    
    "However, frontswap_map is allocated using max pages. When test and clear
    the sis offset, which is larger than max pages, of frontswap_map in
    __frontswap_invalidate_page(), neighbors of frontswap_map may be
    overwritten, i.e., slab is polluted."
    
    Note also that this bug resulted in a behavioral change: activating a
    swap file that was formatted and later extended results in all pages
    being activated, not the number of pages recorded in the swap header.]
    
    This fixes the issue by considering the limitation of max pages of swap
    info in iomap_swapfile_add_extent().
    
    To reproduce the case, compile kernel with slub RED ZONE, then run test:
    $ sudo stress-ng -a 1 -x softlockup,resources -t 72h --metrics --times \
     --verify -v -Y /root/tmpdir/stress-ng/stress-statistic-12.yaml \
     --log-file /root/tmpdir/stress-ng/stress-logfile-12.txt \
     --temp-path /root/tmpdir/stress-ng/
    
    We'll get the error log as below:
    
    [ 1151.015141] =============================================================================
    [ 1151.016489] BUG kmalloc-16 (Not tainted): Right Redzone overwritten
    [ 1151.017486] -----------------------------------------------------------------------------
    [ 1151.017486]
    [ 1151.018997] Disabling lock debugging due to kernel taint
    [ 1151.019873] INFO: 0x0000000084e43932-0x0000000098d17cae @offset=7392. First byte 0x0 instead of 0xcc
    [ 1151.021303] INFO: Allocated in __do_sys_swapon+0xcf6/0x1170 age=43417 cpu=9 pid=3816
    [ 1151.022538]  __slab_alloc+0xe/0x20
    [ 1151.023069]  __kmalloc_node+0xfd/0x4b0
    [ 1151.023704]  __do_sys_swapon+0xcf6/0x1170
    [ 1151.024346]  do_syscall_64+0x33/0x40
    [ 1151.024925]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1151.025749] INFO: Freed in put_cred_rcu+0xa1/0xc0 age=43424 cpu=3 pid=2041
    [ 1151.026889]  kfree+0x276/0x2b0
    [ 1151.027405]  put_cred_rcu+0xa1/0xc0
    [ 1151.027949]  rcu_do_batch+0x17d/0x410
    [ 1151.028566]  rcu_core+0x14e/0x2b0
    [ 1151.029084]  __do_softirq+0x101/0x29e
    [ 1151.029645]  asm_call_irq_on_stack+0x12/0x20
    [ 1151.030381]  do_softirq_own_stack+0x37/0x40
    [ 1151.031037]  do_softirq.part.15+0x2b/0x30
    [ 1151.031710]  __local_bh_enable_ip+0x4b/0x50
    [ 1151.032412]  copy_fpstate_to_sigframe+0x111/0x360
    [ 1151.033197]  __setup_rt_frame+0xce/0x480
    [ 1151.033809]  arch_do_signal+0x1a3/0x250
    [ 1151.034463]  exit_to_user_mode_prepare+0xcf/0x110
    [ 1151.035242]  syscall_exit_to_user_mode+0x27/0x190
    [ 1151.035970]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1151.036795] INFO: Slab 0x000000003b9de4dc objects=44 used=9 fp=0x00000000539e349e flags=0xfffffc0010201
    [ 1151.038323] INFO: Object 0x000000004855ba01 @offset=7376 fp=0x0000000000000000
    [ 1151.038323]
    [ 1151.039683] Redzone  000000008d0afd3d: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    [ 1151.041180] Object   000000004855ba01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    [ 1151.042714] Redzone  0000000084e43932: 00 00 00 c0 cc cc cc cc                          ........
    [ 1151.044120] Padding  000000000864c042: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
    [ 1151.045615] CPU: 5 PID: 3816 Comm: stress-ng Tainted: G    B             5.10.50+ #7
    [ 1151.046846] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
    [ 1151.048633] Call Trace:
    [ 1151.049072]  dump_stack+0x57/0x6a
    [ 1151.049585]  check_bytes_and_report+0xed/0x110
    [ 1151.050320]  check_object+0x1eb/0x290
    [ 1151.050924]  ? __x64_sys_swapoff+0x39a/0x540
    [ 1151.051646]  free_debug_processing+0x151/0x350
    [ 1151.052333]  __slab_free+0x21a/0x3a0
    [ 1151.052938]  ? _cond_resched+0x2d/0x40
    [ 1151.053529]  ? __vunmap+0x1de/0x220
    [ 1151.054139]  ? __x64_sys_swapoff+0x39a/0x540
    [ 1151.054796]  ? kfree+0x276/0x2b0
    [ 1151.055307]  kfree+0x276/0x2b0
    [ 1151.055832]  __x64_sys_swapoff+0x39a/0x540
    [ 1151.056466]  do_syscall_64+0x33/0x40
    [ 1151.057084]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1151.057866] RIP: 0033:0x150340b0ffb7
    [ 1151.058481] Code: Unable to access opcode bytes at RIP 0x150340b0ff8d.
    [ 1151.059537] RSP: 002b:00007fff7f4ee238 EFLAGS: 00000246 ORIG_RAX: 00000000000000a8
    [ 1151.060768] RAX: ffffffffffffffda RBX: 00007fff7f4ee66c RCX: 0000150340b0ffb7
    [ 1151.061904] RDX: 000000000000000a RSI: 0000000000018094 RDI: 00007fff7f4ee860
    [ 1151.063033] RBP: 00007fff7f4ef980 R08: 0000000000000000 R09: 0000150340a672bd
    [ 1151.064135] R10: 00007fff7f4edca0 R11: 0000000000000246 R12: 0000000000018094
    [ 1151.065253] R13: 0000000000000005 R14: 000000000160d930 R15: 00007fff7f4ee66c
    [ 1151.066413] FIX kmalloc-16: Restoring 0x0000000084e43932-0x0000000098d17cae=0xcc
    [ 1151.066413]
    [ 1151.067890] FIX kmalloc-16: Object at 0x000000004855ba01 not freed
    
    Fixes: 67482129cdab ("iomap: add a swapfile activation function")
    Fixes: a45c0eccc564 ("iomap: move the swapfile code into a separate file")
    Signed-off-by: Gang Deng <gavin.dg@linux.alibaba.com>
    Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f5e26053c464429540bf4ffc34c66052c45b699
Author: Nadezda Lutovinova <lutovinova@ispras.ru>
Date:   Wed Aug 18 17:12:47 2021 +0300

    usb: gadget: mv_u3d: request_irq() after initializing UDC
    
    [ Upstream commit 2af0c5ffadaf9d13eca28409d4238b4e672942d3 ]
    
    If IRQ occurs between calling  request_irq() and  mv_u3d_eps_init(),
    then null pointer dereference occurs since u3d->eps[] wasn't
    initialized yet but used in mv_u3d_nuke().
    
    The patch puts registration of the interrupt handler after
    initializing of neccesery data.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
    Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb3c6a25012fa2b55f71c583cd143a747aaa3361
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Aug 12 16:41:43 2021 -0400

    nfsd4: Fix forced-expiry locking
    
    [ Upstream commit f7104cc1a9159cd0d3e8526cb638ae0301de4b61 ]
    
    This should use the network-namespace-wide client_lock, not the
    per-client cl_lock.
    
    You shouldn't see any bugs unless you're actually using the
    forced-expiry interface introduced by 89c905beccbb.
    
    Fixes: 89c905beccbb "nfsd: allow forced expiration of NFSv4 clients"
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81e69d3fdd9e47287a0f3705c154263fe08fa2a7
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Mon Jul 26 09:33:28 2021 -0400

    lockd: Fix invalid lockowner cast after vfs_test_lock
    
    [ Upstream commit cd2d644ddba183ec7b451b7c20d5c7cc06fcf0d7 ]
    
    After calling vfs_test_lock() the pointer to a conflicting lock can be
    returned, and that lock is not guarunteed to be owned by nlm.  In that
    case, we cannot cast it to struct nlm_lockowner.  Instead return the pid
    of that conflicting lock.
    
    Fixes: 646d73e91b42 ("lockd: Show pid of lockd for remote locks")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1c02e2e6a7ad0d65dd7f5ecc23a33a02eb10a54
Author: Chih-Kang Chang <gary.chang@realtek.com>
Date:   Mon Aug 16 16:51:28 2021 +0800

    mac80211: Fix insufficient headroom issue for AMSDU
    
    [ Upstream commit f50d2ff8f016b79a2ff4acd5943a1eda40c545d4 ]
    
    ieee80211_amsdu_realloc_pad() fails to account for extra_tx_headroom,
    the original reserved headroom might be eaten. Add the necessary
    extra_tx_headroom.
    
    Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
    Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://lore.kernel.org/r/20210816085128.10931-2-pkshih@realtek.com
    [fix indentation]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 606668e24a0d7fd262e2326d76bb60b965fe713f
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Fri Aug 13 23:32:38 2021 +0300

    usb: phy: tahvo: add IRQ check
    
    [ Upstream commit 0d45a1373e669880b8beaecc8765f44cb0241e47 ]
    
    The driver neglects to check the result of platform_get_irq()'s call and
    blithely passes the negative error codes to request_threaded_irq() (which
    takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an
    original error code.  Stop calling request_threaded_irq() with the invalid
    IRQ #s.
    
    Fixes: 9ba96ae5074c ("usb: omap1: Tahvo USB transceiver driver")
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/8280d6a4-8e9a-7cfe-1aa9-db586dc9afdf@omp.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecf18ac8ff7601b4670a24e640b041e0fbb0d254
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Fri Aug 13 23:30:18 2021 +0300

    usb: host: ohci-tmio: add IRQ check
    
    [ Upstream commit 4ac5132e8a4300637a2da8f5d6bc7650db735b8a ]
    
    The driver neglects to check the  result of platform_get_irq()'s call and
    blithely passes the negative error codes to usb_add_hcd() (which takes
    *unsigned* IRQ #), causing request_irq() that it calls to fail with
    -EINVAL, overriding an original error code. Stop calling usb_add_hcd()
    with the invalid IRQ #s.
    
    Fixes: 78c73414f4f6 ("USB: ohci: add support for tmio-ohci cell")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/402e1a45-a0a4-0e08-566a-7ca1331506b1@omp.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abbcd61d091f69ec98013dc0ae9c992e152fc303
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Aug 10 12:53:15 2021 +0800

    Bluetooth: Move shutdown callback before flushing tx and rx queue
    
    [ Upstream commit 0ea53674d07fb6db2dd7a7ec2fdc85a12eb246c2 ]
    
    Commit 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues
    are flushed or cancelled") introduced a regression that makes mtkbtsdio
    driver stops working:
    [   36.593956] Bluetooth: hci0: Firmware already downloaded
    [   46.814613] Bluetooth: hci0: Execution of wmt command timed out
    [   46.814619] Bluetooth: hci0: Failed to send wmt func ctrl (-110)
    
    The shutdown callback depends on the result of hdev->rx_work, so we
    should call it before flushing rx_work:
    -> btmtksdio_shutdown()
     -> mtk_hci_wmt_sync()
      -> __hci_cmd_send()
       -> wait for BTMTKSDIO_TX_WAIT_VND_EVT gets cleared
    
    -> btmtksdio_recv_event()
     -> hci_recv_frame()
      -> queue_work(hdev->workqueue, &hdev->rx_work)
       -> clears BTMTKSDIO_TX_WAIT_VND_EVT
    
    So move the shutdown callback before flushing TX/RX queue to resolve the
    issue.
    
    Reported-and-tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Fixes: 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues are flushed or cancelled")
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93ec1fd04f0f792e96f52bf60d501677fa0ad2dd
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Aug 11 17:52:54 2021 +0200

    usb: gadget: udc: renesas_usb3: Fix soc_device_match() abuse
    
    [ Upstream commit cea45a3bd2dd4d9c35581328f571afd32b3c9f48 ]
    
    soc_device_match() is intended as a last resort, to handle e.g. quirks
    that cannot be handled by matching based on a compatible value.
    
    As the device nodes for the Renesas USB 3.0 Peripheral Controller on
    R-Car E3 and RZ/G2E do have SoC-specific compatible values, the latter
    can and should be used to match against these devices.
    
    This also fixes support for the USB 3.0 Peripheral Controller on the
    R-Car E3e (R8A779M6) SoC, which is a different grading of the R-Car E3
    (R8A77990) SoC, using the same SoC-specific compatible value.
    
    Fixes: 30025efa8b5e75f5 ("usb: gadget: udc: renesas_usb3: add support for r8a77990")
    Fixes: 546970fdab1da5fe ("usb: gadget: udc: renesas_usb3: add support for r8a774c0")
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/760981fb4cd110d7cbfc9dcffa365e7c8b25c6e5.1628696960.git.geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30d9607bcd739c4e746060460ae80732e486856e
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Mon Aug 9 23:53:16 2021 +0300

    usb: phy: twl6030: add IRQ checks
    
    [ Upstream commit 0881e22c06e66af0b64773c91c8868ead3d01aa1 ]
    
    The driver neglects to check the result of platform_get_irq()'s calls and
    blithely passes the negative error codes to request_threaded_irq() (which
    takes *unsigned* IRQ #), causing them both to fail with -EINVAL, overriding
    an original error code.  Stop calling request_threaded_irq() with the
    invalid IRQ #s.
    
    Fixes: c33fad0c3748 ("usb: otg: Adding twl6030-usb transceiver driver for OMAP4430")
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/9507f50b-50f1-6dc4-f57c-3ed4e53a1c25@omp.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1473ac28563b0afd5fdf849a6f82b24c48d1467
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Mon Aug 9 23:50:18 2021 +0300

    usb: phy: fsl-usb: add IRQ check
    
    [ Upstream commit ecc2f30dbb25969908115c81ec23650ed982b004 ]
    
    The driver neglects to check the result of platform_get_irq()'s call and
    blithely passes the negative error codes to request_irq() (which takes
    *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
    error code. Stop calling request_irq() with the invalid IRQ #s.
    
    Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver")
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/b0a86089-8b8b-122e-fd6d-73e8c2304964@omp.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9535f55d0cba9313222dac546b76088e1848472a
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Mon Aug 9 23:27:28 2021 +0300

    usb: gadget: udc: at91: add IRQ check
    
    [ Upstream commit 50855c31573b02963f0aa2aacfd4ea41c31ae0e0 ]
    
    The driver neglects to check the result of platform_get_irq()'s call and
    blithely passes the negative error codes to devm_request_irq() (which takes
    *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
    error code. Stop calling devm_request_irq() with the invalid IRQ #s.
    
    Fixes: 8b2e76687b39 ("USB: AT91 UDC updates, mostly power management")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Link: https://lore.kernel.org/r/6654a224-739a-1a80-12f0-76d920f87b6c@omp.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05e5b16b79dc97d64044d8c35fd3fd5e4bec27ed
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Aug 6 11:15:13 2021 +0200

    drm/msm/dsi: Fix some reference counted resource leaks
    
    [ Upstream commit 6977cc89c87506ff17e6c05f0e37f46752256e82 ]
    
    'of_find_device_by_node()' takes a reference that must be released when
    not needed anymore.
    This is expected to be done in 'dsi_destroy()'.
    
    However, there are 2 issues in 'dsi_get_phy()'.
    
    First, if 'of_find_device_by_node()' succeeds but 'platform_get_drvdata()'
    returns NULL, 'msm_dsi->phy_dev' will still be NULL, and the reference
    won't be released in 'dsi_destroy()'.
    
    Secondly, as 'of_find_device_by_node()' already takes a reference, there is
    no need for an additional 'get_device()'.
    
    Move the assignment to 'msm_dsi->phy_dev' a few lines above and remove the
    unneeded 'get_device()' to solve both issues.
    
    Fixes: ec31abf6684e ("drm/msm/dsi: Separate PHY to another platform device")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/f15bc57648a00e7c99f943903468a04639d50596.1628241097.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ccb04c6e1fb7b97fa2e1785b67c3a1cb3527ef7
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date:   Tue Aug 10 12:14:10 2021 +0800

    Bluetooth: fix repeated calls to sco_sock_kill
    
    [ Upstream commit e1dee2c1de2b4dd00eb44004a4bda6326ed07b59 ]
    
    In commit 4e1a720d0312 ("Bluetooth: avoid killing an already killed
    socket"), a check was added to sco_sock_kill to skip killing a socket
    if the SOCK_DEAD flag was set.
    
    This was done after a trace for a use-after-free bug showed that the
    same sock pointer was being killed twice.
    
    Unfortunately, this check prevents sco_sock_kill from running on any
    socket. sco_sock_kill kills a socket only if it's zapped and orphaned,
    however sock_orphan announces that the socket is dead before detaching
    it. i.e., orphaned sockets have the SOCK_DEAD flag set.
    
    To fix this, we remove the check for SOCK_DEAD, and avoid repeated
    calls to sco_sock_kill by removing incorrect calls in:
    
    1. sco_sock_timeout. The socket should not be killed on timeout as
    further processing is expected to be done. For example,
    sco_sock_connect sets the timer then waits for the socket to be
    connected or for an error to be returned.
    
    2. sco_conn_del. This function should clean up resources for the
    connection, but the socket itself should be cleaned up in
    sco_sock_release.
    
    3. sco_sock_close. Calls to sco_sock_close in sco_sock_cleanup_listen
    and sco_sock_release are followed by sco_sock_kill. Hence the
    duplicated call should be removed.
    
    Fixes: 4e1a720d0312 ("Bluetooth: avoid killing an already killed socket")
    Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2451d5439d08ff351a6d07d51ec35d354a3d2df
Author: William Breathitt Gray <vilhelm.gray@gmail.com>
Date:   Tue Aug 3 21:06:11 2021 +0900

    counter: 104-quad-8: Return error when invalid mode during ceiling_write
    
    [ Upstream commit 728246e8f7269ecd35a2c6e6795323e6d8f48db7 ]
    
    The 104-QUAD-8 only has two count modes where a ceiling value makes
    sense: Range Limit and Modulo-N. Outside of these two modes, setting a
    ceiling value is an invalid operation -- so let's report it as such by
    returning -EINVAL.
    
    Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic interface")
    Acked-by: Syed Nayyar Waris <syednwaris@gmail.com>
    Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Link: https://lore.kernel.org/r/a2147f022829b66839a1db5530a7fada47856847.1627990337.git.vilhelm.gray@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1194b805c900a0f5fdc077614bec5c471cddb3b
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Thu Aug 5 09:21:10 2021 +0200

    arm64: dts: exynos: correct GIC CPU interfaces address range on Exynos7
    
    [ Upstream commit 01c72cad790cb6cd3ccbe4c1402b6cb6c6bbffd0 ]
    
    The GIC-400 CPU interfaces address range is defined as 0x2000-0x3FFF (by
    ARM).
    
    Reported-by: Sam Protsenko <semen.protsenko@linaro.org>
    Reported-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7")
    Link: https://lore.kernel.org/r/20210805072110.4730-1-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b6fcd10375a9e69c5d546b3edcbefec902615e4
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Jul 5 02:05:19 2021 +0300

    drm/msm/dpu: make dpu_hw_ctl_clear_all_blendstages clear necessary LMs
    
    [ Upstream commit a41cdb693595ae1904dd793fc15d6954f4295e27 ]
    
    dpu_hw_ctl_clear_all_blendstages() clears settings for the few first LMs
    instead of mixers actually used for the CTL. Change it to clear
    necessary data, using provided mixer ids.
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20210704230519.4081467-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 156eaacba3d22cb145fbc1062b652b3f969aa40c
Author: Lukasz Luba <lukasz.luba@arm.com>
Date:   Tue Aug 3 11:27:43 2021 +0100

    PM: EM: Increase energy calculation precision
    
    [ Upstream commit 7fcc17d0cb12938d2b3507973a6f93fc9ed2c7a1 ]
    
    The Energy Model (EM) provides useful information about device power in
    each performance state to other subsystems like: Energy Aware Scheduler
    (EAS). The energy calculation in EAS does arithmetic operation based on
    the EM em_cpu_energy(). Current implementation of that function uses
    em_perf_state::cost as a pre-computed cost coefficient equal to:
    cost = power * max_frequency / frequency.
    The 'power' is expressed in milli-Watts (or in abstract scale).
    
    There are corner cases when the EAS energy calculation for two Performance
    Domains (PDs) return the same value. The EAS compares these values to
    choose smaller one. It might happen that this values are equal due to
    rounding error. In such scenario, we need better resolution, e.g. 1000
    times better. To provide this possibility increase the resolution in the
    em_perf_state::cost for 64-bit architectures. The cost of increasing
    resolution on 32-bit is pretty high (64-bit division) and is not justified
    since there are no new 32bit big.LITTLE EAS systems expected which would
    benefit from this higher resolution.
    
    This patch allows to avoid the rounding to milli-Watt errors, which might
    occur in EAS energy estimation for each PD. The rounding error is common
    for small tasks which have small utilization value.
    
    There are two places in the code where it makes a difference:
    1. In the find_energy_efficient_cpu() where we are searching for
    best_delta. We might suffer there when two PDs return the same result,
    like in the example below.
    
    Scenario:
    Low utilized system e.g. ~200 sum_util for PD0 and ~220 for PD1. There
    are quite a few small tasks ~10-15 util. These tasks would suffer for
    the rounding error. These utilization values are typical when running games
    on Android. One of our partners has reported 5..10mA less battery drain
    when running with increased resolution.
    
    Some details:
    We have two PDs: PD0 (big) and PD1 (little)
    Let's compare w/o patch set ('old') and w/ patch set ('new')
    We are comparing energy w/ task and w/o task placed in the PDs
    
    a) 'old' w/o patch set, PD0
    task_util = 13
    cost = 480
    sum_util_w/o_task = 215
    sum_util_w_task = 228
    scale_cpu = 1024
    energy_w/o_task = 480 * 215 / 1024 = 100.78 => 100
    energy_w_task = 480 * 228 / 1024 = 106.87 => 106
    energy_diff = 106 - 100 = 6
    (this is equal to 'old' PD1's energy_diff in 'c)')
    
    b) 'new' w/ patch set, PD0
    task_util = 13
    cost = 480 * 1000 = 480000
    sum_util_w/o_task = 215
    sum_util_w_task = 228
    energy_w/o_task = 480000 * 215 / 1024 = 100781
    energy_w_task = 480000 * 228 / 1024  = 106875
    energy_diff = 106875 - 100781 = 6094
    (this is not equal to 'new' PD1's energy_diff in 'd)')
    
    c) 'old' w/o patch set, PD1
    task_util = 13
    cost = 160
    sum_util_w/o_task = 283
    sum_util_w_task = 293
    scale_cpu = 355
    energy_w/o_task = 160 * 283 / 355 = 127.55 => 127
    energy_w_task = 160 * 296 / 355 = 133.41 => 133
    energy_diff = 133 - 127 = 6
    (this is equal to 'old' PD0's energy_diff in 'a)')
    
    d) 'new' w/ patch set, PD1
    task_util = 13
    cost = 160 * 1000 = 160000
    sum_util_w/o_task = 283
    sum_util_w_task = 293
    scale_cpu = 355
    energy_w/o_task = 160000 * 283 / 355 = 127549
    energy_w_task = 160000 * 296 / 355 =   133408
    energy_diff = 133408 - 127549 = 5859
    (this is not equal to 'new' PD0's energy_diff in 'b)')
    
    2. Difference in the 6% energy margin filter at the end of
    find_energy_efficient_cpu(). With this patch the margin comparison also
    has better resolution, so it's possible to have better task placement
    thanks to that.
    
    Fixes: 27871f7a8a341ef ("PM: Introduce an Energy Model management framework")
    Reported-by: CCJ Yeh <CCj.Yeh@mediatek.com>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5537dc810b2abf95eea37d96dfe16419c7760ea4
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Aug 4 16:09:51 2021 +0100

    Bluetooth: increase BTNAMSIZ to 21 chars to fix potential buffer overflow
    
    [ Upstream commit 713baf3dae8f45dc8ada4ed2f5fdcbf94a5c274d ]
    
    An earlier commit replaced using batostr to using %pMR sprintf for the
    construction of session->name. Static analysis detected that this new
    method can use a total of 21 characters (including the trailing '\0')
    so we need to increase the BTNAMSIZ from 18 to 21 to fix potential
    buffer overflows.
    
    Addresses-Coverity: ("Out-of-bounds write")
    Fixes: fcb73338ed53 ("Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0faa638f016caca324c8d2bec84fcde658f5472
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Aug 2 18:24:44 2021 +0200

    debugfs: Return error during {full/open}_proxy_open() on rmmod
    
    [ Upstream commit 112cedc8e600b668688eb809bf11817adec58ddc ]
    
    If a kernel module gets unloaded then it printed report about a leak before
    commit 275678e7a9be ("debugfs: Check module state before warning in
    {full/open}_proxy_open()"). An additional check was added in this commit to
    avoid this printing. But it was forgotten that the function must return an
    error in this case because it was not actually opened.
    
    As result, the systems started to crash or to hang when a module was
    unloaded while something was trying to open a file.
    
    Fixes: 275678e7a9be ("debugfs: Check module state before warning in {full/open}_proxy_open()")
    Cc: Taehee Yoo <ap420073@gmail.com>
    Reported-by: Mário Lopes <ml@simonwunderlich.de>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Link: https://lore.kernel.org/r/20210802162444.7848-1-sven@narfation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f44714b4eb2ad2d40f8fecefccd347960a68b112
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon Jul 12 15:57:03 2021 +0200

    soc: qcom: smsm: Fix missed interrupts if state changes while masked
    
    [ Upstream commit e3d4571955050736bbf3eda0a9538a09d9fcfce8 ]
    
    The SMSM driver detects interrupt edges by tracking the last state
    it has seen (and has triggered the interrupt handler for). This works
    fine, but only if the interrupt does not change state while masked.
    
    For example, if an interrupt is unmasked while the state is HIGH,
    the stored last_value for that interrupt might still be LOW. Then,
    when the remote processor triggers smsm_intr() we assume that nothing
    has changed, even though the state might have changed from HIGH to LOW.
    
    Attempt to fix this by checking the current remote state before
    unmasking an IRQ. Use atomic operations to avoid the interrupt handler
    from interfering with the unmask function.
    
    This fixes modem crashes in some edge cases with the BAM-DMUX driver.
    Specifically, the BAM-DMUX interrupt handler is not called for the
    HIGH -> LOW smsm state transition if the BAM-DMUX driver is loaded
    (and therefore unmasks the interrupt) after the modem was already started:
    
    qcom-q6v5-mss 4080000.remoteproc: fatal error received: a2_task.c:3188:
      Assert FALSE failed: A2 DL PER deadlock timer expired waiting for Apps ACK
    
    Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20210712135703.324748-2-stephan@gerhold.net
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7997fe3e9cafb48621a88567c649530643e1a05
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jul 29 16:49:10 2021 +0200

    PCI: PM: Enable PME if it can be signaled from D3cold
    
    [ Upstream commit 0e00392a895c95c6d12d42158236c8862a2f43f2 ]
    
    PME signaling is only enabled by __pci_enable_wake() if the target
    device can signal PME from the given target power state (to avoid
    pointless reconfiguration of the device), but if the hierarchy above
    the device goes into D3cold, the device itself will end up in D3cold
    too, so if it can signal PME from D3cold, it should be enabled to
    do so in __pci_enable_wake().
    
    [Note that if the device does not end up in D3cold and it cannot
     signal PME from the original target power state, it will not signal
     PME, so in that case the behavior does not change.]
    
    Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/
    Fixes: 5bcc2fb4e815 ("PCI PM: Simplify PCI wake-up code")
    Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
    Reported-by: Koba Ko <koba.ko@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e570f3d477739ad9d75a260a01d180d7334bb13
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jul 29 17:54:28 2021 +0200

    PCI: PM: Avoid forcing PCI_D0 for wakeup reasons inconsistently
    
    [ Upstream commit da9f2150684ea684a7ddd6d7f0e38b2bdf43dcd8 ]
    
    It is inconsistent to return PCI_D0 from pci_target_state() instead
    of the original target state if 'wakeup' is true and the device
    cannot signal PME from D0.
    
    This only happens when the device cannot signal PME from the original
    target state and any shallower power states (including D0) and that
    case is effectively equivalent to the one in which PME singaling is
    not supported at all.  Since the original target state is returned in
    the latter case, make the function do that in the former one too.
    
    Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/
    Fixes: 666ff6f83e1d ("PCI/PM: Avoid using device_may_wakeup() for runtime PM")
    Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
    Reported-by: Koba Ko <koba.ko@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f865b316ccc6abed1191a3f940c9524b15e7c4ce
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Jul 9 14:30:25 2021 +0200

    media: venus: venc: Fix potential null pointer dereference on pointer fmt
    
    [ Upstream commit 09ea9719a423fc675d40dd05407165e161ea0c48 ]
    
    Currently the call to find_format can potentially return a NULL to
    fmt and the nullpointer is later dereferenced on the assignment of
    pixmp->num_planes = fmt->num_planes.  Fix this by adding a NULL pointer
    check and returning NULL for the failure case.
    
    Addresses-Coverity: ("Dereference null return")
    
    Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2ea2f0725cccaf0bc7294a30fc546bc48637cb4
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Wed Jul 7 11:34:09 2021 +0200

    media: em28xx-input: fix refcount bug in em28xx_usb_disconnect
    
    [ Upstream commit 6fa54bc713c262e1cfbc5613377ef52280d7311f ]
    
    If em28xx_ir_init fails, it would decrease the refcount of dev. However,
    in the em28xx_ir_fini, when ir is NULL, it goes to ref_put and decrease
    the refcount of dev. This will lead to a refcount bug.
    
    Fix this bug by removing the kref_put in the error handling code
    of em28xx_ir_init.
    
    refcount_t: underflow; use-after-free.
    WARNING: CPU: 0 PID: 7 at lib/refcount.c:28 refcount_warn_saturate+0x18e/0x1a0 lib/refcount.c:28
    Modules linked in:
    CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.13.0 #3
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:refcount_warn_saturate+0x18e/0x1a0 lib/refcount.c:28
    Call Trace:
      kref_put.constprop.0+0x60/0x85 include/linux/kref.h:69
      em28xx_usb_disconnect.cold+0xd7/0xdc drivers/media/usb/em28xx/em28xx-cards.c:4150
      usb_unbind_interface+0xbf/0x3a0 drivers/usb/core/driver.c:458
      __device_release_driver drivers/base/dd.c:1201 [inline]
      device_release_driver_internal+0x22a/0x230 drivers/base/dd.c:1232
      bus_remove_device+0x108/0x160 drivers/base/bus.c:529
      device_del+0x1fe/0x510 drivers/base/core.c:3540
      usb_disable_device+0xd1/0x1d0 drivers/usb/core/message.c:1419
      usb_disconnect+0x109/0x330 drivers/usb/core/hub.c:2221
      hub_port_connect drivers/usb/core/hub.c:5151 [inline]
      hub_port_connect_change drivers/usb/core/hub.c:5440 [inline]
      port_event drivers/usb/core/hub.c:5586 [inline]
      hub_event+0xf81/0x1d40 drivers/usb/core/hub.c:5668
      process_one_work+0x2c9/0x610 kernel/workqueue.c:2276
      process_scheduled_works kernel/workqueue.c:2338 [inline]
      worker_thread+0x333/0x5b0 kernel/workqueue.c:2424
      kthread+0x188/0x1d0 kernel/kthread.c:319
      ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
    
    Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Fixes: ac5688637144 ("media: em28xx: Fix possible memory leak of em28xx struct")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebf570042b5f9614f53f02848d9c0e93485c71f8
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Feb 21 12:52:08 2021 +0100

    leds: trigger: audio: Add an activate callback to ensure the initial brightness is set
    
    [ Upstream commit 64f67b5240db79eceb0bd57dae8e591fd3103ba0 ]
    
    Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in
    the speaker- and/or mic-mute keys on the keyboard.
    
    Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock)
    and the HP x2 10 series.
    
    The detachable nature of these keyboards means that the keyboard and
    thus the mute LEDs may show up after the user (or userspace restoring
    old mixer settings) has muted the speaker and/or mic.
    
    Current LED-class devices with a default_trigger of "audio-mute" or
    "audio-micmute" initialize the brightness member of led_classdev with
    ledtrig_audio_get() before registering the LED.
    
    This makes the software state after attaching the keyboard match the
    actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will
    show the right value.
    
    But before this commit nothing was actually calling the led_classdev's
    brightness_set[_blocking] callback so the value returned by
    ledtrig_audio_get() was never actually being sent to the hw, leading
    to the mute LEDs staying in their default power-on state, after
    attaching the keyboard, even if ledtrig_audio_get() returned a different
    state.
    
    This could be fixed by having the individual LED drivers call
    brightness_set[_blocking] themselves after registering the LED,
    but this really is something which should be done by a led-trigger
    activate callback.
    
    Add an activate callback for this, fixing the issue of the
    mute LEDs being out of sync after (re)attaching the keyboard.
    
    Cc: Takashi Iwai <tiwai@suse.de>
    Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger")
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a01dc77662cfb3c15aea7cbf153c985b65cc6da
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sat May 29 14:19:33 2021 +0300

    leds: lt3593: Put fwnode in any case during ->probe()
    
    [ Upstream commit 7e1baaaa2407a642ea19b58e214fab9a69cda1d7 ]
    
    device_get_next_child_node() bumps a reference counting of a returned variable.
    We have to balance it whenever we return to the caller.
    
    Fixes: 8cd7d6daba93 ("leds: lt3593: Add device tree probing glue")
    Cc: Daniel Mack <daniel@zonque.org>
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e39c73563a381eefdc283ac797f40da4583b1d30
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sun May 30 22:13:45 2021 +0300

    i2c: highlander: add IRQ check
    
    [ Upstream commit f16a3bb69aa6baabf8f0aca982c8cf21e2a4f6bc ]
    
    The driver is written as if platform_get_irq() returns 0 on errors (while
    actually it returns a negative error code), blithely passing these error
    codes to request_irq() (which takes *unsigned* IRQ #) -- which fails with
    -EINVAL. Add the necessary error check to the pre-existing *if* statement
    forcing the driver into the polling mode...
    
    Fixes: 4ad48e6ab18c ("i2c: Renesas Highlander FPGA SMBus support")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fba783ddd945aa9f424b2409e73e12e046b529f2
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Jul 27 19:35:30 2021 +0300

    net: cipso: fix warnings in netlbl_cipsov4_add_std
    
    [ Upstream commit 8ca34a13f7f9b3fa2c464160ffe8cc1a72088204 ]
    
    Syzbot reported warning in netlbl_cipsov4_add(). The
    problem was in too big doi_def->map.std->lvl.local_size
    passed to kcalloc(). Since this value comes from userpace there is
    no need to warn if value is not correct.
    
    The same problem may occur with other kcalloc() calls in
    this function, so, I've added __GFP_NOWARN flag to all
    kcalloc() calls there.
    
    Reported-and-tested-by: syzbot+cdd51ee2e6b0b2e18c0d@syzkaller.appspotmail.com
    Fixes: 96cb8e3313c7 ("[NetLabel]: CIPSOv4 and Unlabeled packet integration")
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fdac650c41314ae02095bdebc5f7bc6ce8a4452
Author: Waiman Long <longman@redhat.com>
Date:   Tue Jul 20 10:18:27 2021 -0400

    cgroup/cpuset: Fix a partition bug with hotplug
    
    [ Upstream commit 15d428e6fe77fffc3f4fff923336036f5496ef17 ]
    
    In cpuset_hotplug_workfn(), the detection of whether the cpu list
    has been changed is done by comparing the effective cpus of the top
    cpuset with the cpu_active_mask. However, in the rare case that just
    all the CPUs in the subparts_cpus are offlined, the detection fails
    and the partition states are not updated correctly. Fix it by forcing
    the cpus_updated flag to true in this particular case.
    
    Fixes: 4b842da276a8 ("cpuset: Make CPU hotplug work with partition")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffde0581995372cd0322388c99809e07f3c1592a
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Thu Apr 8 17:20:04 2021 +0300

    net/mlx5e: Prohibit inner indir TIRs in IPoIB
    
    [ Upstream commit 9c43f3865c2a03be104f1c1d5e9129c2a2bdba88 ]
    
    TIR's rx_hash_field_selector_inner can be enabled only when
    tunneled_offload_en = 1. tunneled_offload_en is filled according to the
    tunneled_offload_en field in struct mlx5e_params, which is false in the
    IPoIB profile. On the other hand, the IPoIB profile passes inner_ttc =
    true to mlx5e_create_indirect_tirs, which potentially allows the latter
    function to attempt to create inner indirect TIRs without having
    tunneled_offload_en set.
    
    This commit prohibits this behavior by passing inner_ttc = false to
    mlx5e_create_indirect_tirs. The latter function won't attempt to create
    inner indirect TIRs.
    
    As inner indirect TIRs are not created in the IPoIB profile (this commit
    blocks it explicitly, and even before they would have failed to be
    created), the call to mlx5e_create_inner_ttc_table in
    mlx5i_create_flow_steering is a no-op and can be removed.
    
    Fixes: 46dc933cee82 ("net/mlx5e: Provide explicit directive if to create inner indirect tirs")
    Fixes: 458821c72bd0 ("net/mlx5e: IPoIB, Add inner TTC table to IPoIB flow steering")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87f817c560e63b4b857281e8e5dd8c6be2eb0f34
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Mon Jul 5 11:23:55 2021 +0000

    ARM: dts: meson8b: ec100: Fix the pwm regulator supply properties
    
    [ Upstream commit 72ccc373b064ae3ac0c5b5f2306069b60ca118df ]
    
    After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs.
    Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply
    instead of dummy regulator.
    
    [    7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree
    [    7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed
    [    7.117184] VCCK: supplied by regulator-dummy
    [    7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT
    [    7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled
    [    7.118498] VDDEE: will resolve supply early: pwm
    [    7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree
    [    7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed
    [    7.118553] VDDEE: supplied by regulator-dummy
    [    7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT
    
    Fixes: 087a1d8b4e4c ("ARM: dts: meson8b: ec100: add the VDDEE regulator")
    Fixes: 3e7db1c1b7a3 ("ARM: dts: meson8b: ec100: improve the description of the regulators")
    
    Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210705112358.3554-4-linux.amoon@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e55d7cbe1fe2404bdf5c696bb2ec4db4eecebc09
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Mon Jul 5 11:23:54 2021 +0000

    ARM: dts: meson8b: mxq: Fix the pwm regulator supply properties
    
    [ Upstream commit 632062e540becbbcb067523ec8bcadb1239d9578 ]
    
    After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs.
    Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply
    instead of dummy regulator.
    Add missing pwm-supply for regulator-vcck regulator node.
    
    [    7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree
    [    7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed
    [    7.117184] VCCK: supplied by regulator-dummy
    [    7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT
    [    7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled
    [    7.118498] VDDEE: will resolve supply early: pwm
    [    7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree
    [    7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed
    [    7.118553] VDDEE: supplied by regulator-dummy
    [    7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT
    
    Fixes: dee51cd0d2e8 ("ARM: dts: meson8b: mxq: add the VDDEE regulator")
    Fixes: d94f60e3dfa0 ("ARM: dts: meson8b: mxq: improve support for the TRONFY MXQ S805")
    
    Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210705112358.3554-3-linux.amoon@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b0bbc412b510b0668f02f259941468a2e93662f
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Mon Jul 5 11:23:53 2021 +0000

    ARM: dts: meson8b: odroidc1: Fix the pwm regulator supply properties
    
    [ Upstream commit 876228e9f935f19c7afc7ba394d17e2ec9143b65 ]
    
    After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs.
    Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply
    instead of dummy regulator.
    
    [    7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree
    [    7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed
    [    7.117184] VCCK: supplied by regulator-dummy
    [    7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT
    [    7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled
    [    7.118498] VDDEE: will resolve supply early: pwm
    [    7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree
    [    7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed
    [    7.118553] VDDEE: supplied by regulator-dummy
    [    7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT
    
    Fixes: 524d96083b66 ("ARM: dts: meson8b: odroidc1: add the CPU voltage regulator")
    Fixes: 8bdf38be712d ("ARM: dts: meson8b: odroidc1: add the VDDEE regulator")
    
    Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    [narmstrong: fixed typo in commit s/observer/observe/]
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210705112358.3554-2-linux.amoon@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7058060c01bd3a48ded0300b0f6398e70e1017d
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun Jul 11 23:40:23 2021 +0200

    ARM: dts: meson8: Use a higher default GPU clock frequency
    
    [ Upstream commit 44cf630bcb8c5ec78125805c9447dd5766792224 ]
    
    We are seeing "imprecise external abort (0x1406)" errors during boot
    (which then cause the whole board to hang) on Meson8 (but not Meson8m2).
    These are observed while trying to access the GPU's registers when the
    MALI clock is running at it's default setting of 24MHz. The 3.10 vendor
    kernel uses 318.75MHz as "default" GPU frequency. Using that makes the
    "imprecise external aborts" go away.
    Add the assigned-clocks and assigned-clock-rates properties to also bump
    the MALI clock to 318.75MHz before accessing any of it's registers.
    
    Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
    Reported-by: Demetris Ierokipides <ierokipides.dem@gmail.com>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210711214023.2163565-1-martin.blumenstingl@googlemail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37ed461b52e97591fb83449640929a4b2ad4a0c9
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Thu Jul 1 13:05:41 2021 -0700

    tcp: seq_file: Avoid skipping sk during tcp_seek_last_pos
    
    [ Upstream commit 525e2f9fd0229eb10cb460a9e6d978257f24804e ]
    
    st->bucket stores the current bucket number.
    st->offset stores the offset within this bucket that is the sk to be
    seq_show().  Thus, st->offset only makes sense within the same
    st->bucket.
    
    These two variables are an optimization for the common no-lseek case.
    When resuming the seq_file iteration (i.e. seq_start()),
    tcp_seek_last_pos() tries to continue from the st->offset
    at bucket st->bucket.
    
    However, it is possible that the bucket pointed by st->bucket
    has changed and st->offset may end up skipping the whole st->bucket
    without finding a sk.  In this case, tcp_seek_last_pos() currently
    continues to satisfy the offset condition in the next (and incorrect)
    bucket.  Instead, regardless of the offset value, the first sk of the
    next bucket should be returned.  Thus, "bucket == st->bucket" check is
    added to tcp_seek_last_pos().
    
    The chance of hitting this is small and the issue is a decade old,
    so targeting for the next tree.
    
    Fixes: a8b690f98baf ("tcp: Fix slowness in read /proc/net/tcp")
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20210701200541.1033917-1-kafai@fb.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 952136275367a77eb2281b9a84da40f7eb58f9fd
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Jul 21 01:22:15 2021 +0800

    drm/amdgpu/acp: Make PM domain really work
    
    [ Upstream commit aff890288de2d818e4f83ec40c9315e2d735df07 ]
    
    Devices created by mfd_add_hotplug_devices() don't really increase the
    index of its name, so get_mfd_cell_dev() cannot find any device, hence a
    NULL dev is passed to pm_genpd_add_device():
    [   56.974926] (NULL device *): amdgpu: device acp_audio_dma.0.auto added to pm domain
    [   56.974933] (NULL device *): amdgpu: Failed to add dev to genpd
    [   56.974941] [drm:amdgpu_device_ip_init [amdgpu]] *ERROR* hw_init of IP block <acp_ip> failed -22
    [   56.975810] amdgpu 0000:00:01.0: amdgpu: amdgpu_device_ip_init failed
    [   56.975839] amdgpu 0000:00:01.0: amdgpu: Fatal error during GPU init
    [   56.977136] ------------[ cut here ]------------
    [   56.977143] kernel BUG at mm/slub.c:4206!
    [   56.977158] invalid opcode: 0000 [#1] SMP NOPTI
    [   56.977167] CPU: 1 PID: 1648 Comm: modprobe Not tainted 5.12.0-051200rc8-generic #202104182230
    [   56.977175] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A68M-HD+, BIOS P5.20 02/13/2019
    [   56.977180] RIP: 0010:kfree+0x3bf/0x410
    [   56.977195] Code: 89 e7 48 d3 e2 f7 da e8 5f 0d 02 00 80 e7 02 75 3e 44 89 ee 4c 89 e7 e8 ef 5f fd ff e9 fa fe ff ff 49 8b 44 24 08 a8 01 75 b7 <0f> 0b 4c 8b 4d b0 48 8b 4d a8 48 89 da 4c 89 e6 41 b8 01 00 00 00
    [   56.977202] RSP: 0018:ffffa48640ff79f0 EFLAGS: 00010246
    [   56.977210] RAX: 0000000000000000 RBX: ffff9286127d5608 RCX: 0000000000000000
    [   56.977215] RDX: 0000000000000000 RSI: ffffffffc099d0fb RDI: ffff9286127d5608
    [   56.977220] RBP: ffffa48640ff7a48 R08: 0000000000000001 R09: 0000000000000001
    [   56.977224] R10: 0000000000000000 R11: ffff9286087d8458 R12: fffff3ae0449f540
    [   56.977229] R13: 0000000000000000 R14: dead000000000122 R15: dead000000000100
    [   56.977234] FS:  00007f9de5929540(0000) GS:ffff928612e80000(0000) knlGS:0000000000000000
    [   56.977240] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   56.977245] CR2: 00007f697dd97160 CR3: 00000001110f0000 CR4: 00000000001506e0
    [   56.977251] Call Trace:
    [   56.977261]  amdgpu_dm_encoder_destroy+0x1b/0x30 [amdgpu]
    [   56.978056]  drm_mode_config_cleanup+0x4f/0x2e0 [drm]
    [   56.978147]  ? kfree+0x3dd/0x410
    [   56.978157]  ? drm_managed_release+0xc8/0x100 [drm]
    [   56.978232]  drm_mode_config_init_release+0xe/0x10 [drm]
    [   56.978311]  drm_managed_release+0x9d/0x100 [drm]
    [   56.978388]  devm_drm_dev_init_release+0x4d/0x70 [drm]
    [   56.978450]  devm_action_release+0x15/0x20
    [   56.978459]  release_nodes+0x77/0xc0
    [   56.978469]  devres_release_all+0x3f/0x50
    [   56.978477]  really_probe+0x245/0x460
    [   56.978485]  driver_probe_device+0xe9/0x160
    [   56.978492]  device_driver_attach+0xab/0xb0
    [   56.978499]  __driver_attach+0x8f/0x150
    [   56.978506]  ? device_driver_attach+0xb0/0xb0
    [   56.978513]  bus_for_each_dev+0x7e/0xc0
    [   56.978521]  driver_attach+0x1e/0x20
    [   56.978528]  bus_add_driver+0x135/0x1f0
    [   56.978534]  driver_register+0x91/0xf0
    [   56.978540]  __pci_register_driver+0x54/0x60
    [   56.978549]  amdgpu_init+0x77/0x1000 [amdgpu]
    [   56.979246]  ? 0xffffffffc0dbc000
    [   56.979254]  do_one_initcall+0x48/0x1d0
    [   56.979265]  ? kmem_cache_alloc_trace+0x120/0x230
    [   56.979274]  ? do_init_module+0x28/0x280
    [   56.979282]  do_init_module+0x62/0x280
    [   56.979288]  load_module+0x71c/0x7a0
    [   56.979296]  __do_sys_finit_module+0xc2/0x120
    [   56.979305]  __x64_sys_finit_module+0x1a/0x20
    [   56.979311]  do_syscall_64+0x38/0x90
    [   56.979319]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   56.979328] RIP: 0033:0x7f9de54f989d
    [   56.979335] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 f5 0c 00 f7 d8 64 89 01 48
    [   56.979342] RSP: 002b:00007ffe3c395a28 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    [   56.979350] RAX: ffffffffffffffda RBX: 0000560df3ef4330 RCX: 00007f9de54f989d
    [   56.979355] RDX: 0000000000000000 RSI: 0000560df3a07358 RDI: 000000000000000f
    [   56.979360] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000
    [   56.979365] R10: 000000000000000f R11: 0000000000000246 R12: 0000560df3a07358
    [   56.979369] R13: 0000000000000000 R14: 0000560df3ef4460 R15: 0000560df3ef4330
    [   56.979377] Modules linked in: amdgpu(+) iommu_v2 gpu_sched drm_ttm_helper ttm drm_kms_helper cec rc_core i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt nft_counter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set nf_tables libcrc32c nfnetlink ip6_tables iptable_filter bpfilter input_leds binfmt_misc edac_mce_amd kvm_amd ccp kvm snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul snd_hda_codec_hdmi ledtrig_audio ghash_clmulni_intel aesni_intel snd_hda_intel snd_intel_dspcfg snd_seq_midi crypto_simd snd_intel_sdw_acpi cryptd snd_hda_codec snd_seq_midi_event snd_rawmidi snd_hda_core snd_hwdep snd_seq fam15h_power k10temp snd_pcm snd_seq_device snd_timer snd mac_hid soundcore sch_fq_codel nct6775 hwmon_vid drm ip_tables x_tables autofs4 dm_mirror dm_region_hash dm_log hid_generic usbhid hid uas usb_storage r8169 crc32_pclmul realtek ahci xhci_pci i2c_piix4
    [   56.979521]  xhci_pci_renesas libahci video
    [   56.979541] ---[ end trace cb8f6a346f18da7b ]---
    
    Instead of finding MFD hotplugged device by its name, simply iterate
    over the child devices to avoid the issue.
    
    Squash in unused variable removal (Alex)
    
    BugLink: https://bugs.launchpad.net/bugs/1920674
    Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks")
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 252fad3d023484d3f258ebb29979960c345b9e80
Author: Guillaume Nault <gnault@redhat.com>
Date:   Mon Jan 13 22:39:22 2020 +0100

    netns: protect netns ID lookups with RCU
    
    commit 2dce224f469f060b9998a5a869151ef83c08ce77 upstream.
    
    __peernet2id() can be protected by RCU as it only calls idr_for_each(),
    which is RCU-safe, and never modifies the nsid table.
    
    rtnl_net_dumpid() can also do lockless lookups. It does two nested
    idr_for_each() calls on nsid tables (one direct call and one indirect
    call because of rtnl_net_dumpid_one() calling __peernet2id()). The
    netnsid tables are never updated. Therefore it is safe to not take the
    nsid_lock and run within an RCU-critical section instead.
    
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>

commit bd1cd32caa67e1af9acbf8889863bf0c6b1dca87
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Jul 12 13:14:40 2021 +0100

    6lowpan: iphc: Fix an off-by-one check of array index
    
    [ Upstream commit 9af417610b6142e826fd1ee8ba7ff3e9a2133a5a ]
    
    The bounds check of id is off-by-one and the comparison should
    be >= rather >. Currently the WARN_ON_ONCE check does not stop
    the out of range indexing of &ldev->ctx.table[id] so also add
    a return path if the bounds are out of range.
    
    Addresses-Coverity: ("Illegal address computation").
    Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4895cf45fd50a1e1fa4152f4cd9e584a806c667
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jun 25 18:00:09 2021 +0300

    Bluetooth: sco: prevent information leak in sco_conn_defer_accept()
    
    [ Upstream commit 59da0b38bc2ea570ede23a3332ecb3e7574ce6b2 ]
    
    Smatch complains that some of these struct members are not initialized
    leading to a stack information disclosure:
    
        net/bluetooth/sco.c:778 sco_conn_defer_accept() warn:
        check that 'cp.retrans_effort' doesn't leak information
    
    This seems like a valid warning.  I've added a default case to fix
    this issue.
    
    Fixes: 2f69a82acf6f ("Bluetooth: Use voice setting in deferred SCO connection request")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a96eb96ce4c1515c9ff9ee064c6c9e993e590858
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Mon Jul 19 16:57:08 2021 +0200

    media: coda: fix frame_mem_ctrl for YUV420 and YVU420 formats
    
    [ Upstream commit 44693d74f5653f82cd7ca0fe730eed0f6b83306a ]
    
    The frame memory control register value is currently determined
    before userspace selects the final capture format and never corrected.
    Update ctx->frame_mem_ctrl in __coda_start_decoding() to fix decoding
    into YUV420 or YVU420 capture buffers.
    
    Reported-by: Andrej Picej <andrej.picej@norik.com>
    Fixes: 497e6b8559a6 ("media: coda: add sequence initialization work")
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    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 7163014d7d294c90535b9319942de78f80adac3e
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Sun Jun 20 21:45:42 2021 +0200

    media: go7007: remove redundant initialization
    
    [ Upstream commit 6f5885a7750545973bf1a942d2f0f129aef0aa06 ]
    
    In go7007_alloc() kzalloc() is used for struct go7007
    allocation. It means that there is no need in zeroing
    any members, because kzalloc will take care of it.
    
    Removing these reduntant initialization steps increases
    execution speed a lot:
    
            Before:
                    + 86.802 us   |    go7007_alloc();
            After:
                    + 29.595 us   |    go7007_alloc();
    
    Fixes: 866b8695d67e8 ("Staging: add the go7007 video driver")
    Signed-off-by: Pavel Skripkin <paskripkin@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 810149287981ce968e59770997a80e0ba7eb9198
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Mon Jun 21 07:07:28 2021 +0200

    media: dvb-usb: Fix error handling in dvb_usb_i2c_init
    
    [ Upstream commit 131ae388b88e3daf4cb0721ed4b4cb8bfc201465 ]
    
    In dvb_usb_i2c_init, if i2c_add_adapter fails, it only prints an error
    message, and then continues to set DVB_USB_STATE_I2C. This affects the
    logic of dvb_usb_i2c_exit, which leads to that, the deletion of i2c_adap
    even if the i2c_add_adapter fails.
    
    Fix this by returning at the failure of i2c_add_adapter and then move
    dvb_usb_i2c_exit out of the error handling code of dvb_usb_i2c_init.
    
    Fixes: 13a79f14ab28 ("media: dvb-usb: Fix memory leak at error in dvb_usb_device_init()")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa8aaa769092b0836e579fa4a7ce90f315f317a0
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Fri Jun 25 07:59:04 2021 +0200

    media: dvb-usb: fix uninit-value in vp702x_read_mac_addr
    
    [ Upstream commit 797c061ad715a9a1480eb73f44b6939fbe3209ed ]
    
    If vp702x_usb_in_op fails, the mac address is not initialized.
    And vp702x_read_mac_addr does not handle this failure, which leads to
    the uninit-value in dvb_usb_adapter_dvb_init.
    
    Fix this by handling the failure of vp702x_usb_in_op.
    
    Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88933f9c93a00c940f97bdbc9ad7bb425b8c69c8
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Fri Jun 25 07:33:27 2021 +0200

    media: dvb-usb: fix uninit-value in dvb_usb_adapter_dvb_init
    
    [ Upstream commit c5453769f77ce19a5b03f1f49946fd3f8a374009 ]
    
    If dibusb_read_eeprom_byte fails, the mac address is not initialized.
    And nova_t_read_mac_address does not handle this failure, which leads to
    the uninit-value in dvb_usb_adapter_dvb_init.
    
    Fix this by handling the failure of dibusb_read_eeprom_byte.
    
    Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com
    Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f81c89614ee890cbf30ccf67169ae60a6d3b923d
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Fri Jul 2 17:54:15 2021 -0700

    soc: qcom: rpmhpd: Use corner in power_off
    
    [ Upstream commit d43b3a989bc8c06fd4bbb69a7500d180db2d68e8 ]
    
    rpmhpd_aggregate_corner() takes a corner as parameter, but in
    rpmhpd_power_off() the code requests the level of the first corner
    instead.
    
    In all (known) current cases the first corner has level 0, so this
    change should be a nop, but in case that there's a power domain with a
    non-zero lowest level this makes sure that rpmhpd_power_off() actually
    requests the lowest level - which is the closest to "power off" we can
    get.
    
    While touching the code, also skip the unnecessary zero-initialization
    of "ret".
    
    Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver")
    Reviewed-by: Rajendra Nayak <rnayak@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
    Tested-by: Sibi Sankar <sibis@codeaurora.org>
    Link: https://lore.kernel.org/r/20210703005416.2668319-2-bjorn.andersson@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b3987f583254a55c6242558df1629c9280188c5
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu Jul 1 12:15:50 2021 +0200

    arm64: dts: renesas: r8a77995: draak: Remove bogus adv7511w properties
    
    [ Upstream commit 4ec82a7bb3db8c6005e715c63224c32d458917a2 ]
    
    The "max-clock" and "min-vrefresh" properties fail to validate with
    commit cfe34bb7a770c5d8 ("dt-bindings: drm: bridge: adi,adv7511.txt:
    convert to yaml").  Drop them, as they are parts of an out-of-tree
    workaround that is not needed upstream.
    
    Fixes: bcf3003438ea4645 ("arm64: dts: renesas: r8a77995: draak: Enable HDMI display output")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
    Link: https://lore.kernel.org/r/975b6686bc423421b147d367fe7fb9a0db99c5af.1625134398.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c106c73208a9ac6a4e4e8a63f21c5447f13e817
Author: Dylan Hung <dylan_hung@aspeedtech.com>
Date:   Thu Oct 29 14:27:23 2020 +0800

    ARM: dts: aspeed-g6: Fix HVI3C function-group in pinctrl dtsi
    
    [ Upstream commit 8c295b7f3d01359ff4336fcb6e406e6ed37957d6 ]
    
    The HVI3C shall be a group of I3C function, not an independent function.
    Correct the function name from "HVI3C" to "I3C".
    
    Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com>
    Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
    Fixes: f510f04c8c83 ("ARM: dts: aspeed: Add AST2600 pinmux nodes")
    Link: https://lore.kernel.org/r/20201029062723.20798-1-dylan_hung@aspeedtech.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 004778bf390a20e9483bf3c170434deddc6a20bf
Author: He Fengqing <hefengqing@huawei.com>
Date:   Wed Jul 14 10:18:15 2021 +0000

    bpf: Fix potential memleak and UAF in the verifier.
    
    [ Upstream commit 75f0fc7b48ad45a2e5736bcf8de26c8872fe8695 ]
    
    In bpf_patch_insn_data(), we first use the bpf_patch_insn_single() to
    insert new instructions, then use adjust_insn_aux_data() to adjust
    insn_aux_data. If the old env->prog have no enough room for new inserted
    instructions, we use bpf_prog_realloc to construct new_prog and free the
    old env->prog.
    
    There have two errors here. First, if adjust_insn_aux_data() return
    ENOMEM, we should free the new_prog. Second, if adjust_insn_aux_data()
    return ENOMEM, bpf_patch_insn_data() will return NULL, and env->prog has
    been freed in bpf_prog_realloc, but we will use it in bpf_check().
    
    So in this patch, we make the adjust_insn_aux_data() never fails. In
    bpf_patch_insn_data(), we first pre-malloc memory for the new
    insn_aux_data, then call bpf_patch_insn_single() to insert new
    instructions, at last call adjust_insn_aux_data() to adjust
    insn_aux_data.
    
    Fixes: 8041902dae52 ("bpf: adjust insn_aux_data when patching insns")
    Signed-off-by: He Fengqing <hefengqing@huawei.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20210714101815.164322-1-hefengqing@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa4802c54e69430304e61ddb13d69ebd4724f8c5
Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Date:   Wed Jul 14 21:43:17 2021 +0900

    bpf: Fix a typo of reuseport map in bpf.h.
    
    [ Upstream commit f170acda7ffaf0473d06e1e17c12cd9fd63904f5 ]
    
    Fix s/BPF_MAP_TYPE_REUSEPORT_ARRAY/BPF_MAP_TYPE_REUSEPORT_SOCKARRAY/ typo
    in bpf.h.
    
    Fixes: 2dbb9b9e6df6 ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20210714124317.67526-1-kuniyu@amazon.co.jp
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a193caf9d7977bbf58441da4e4a2af73f2e97a5
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Jun 10 21:54:31 2021 +0200

    media: cxd2880-spi: Fix an error handling path
    
    [ Upstream commit dcb0145821017e929a733e2271c85c6f82b9c9f8 ]
    
    If an error occurs after a successful 'regulator_enable()' call,
    'regulator_disable()' must be called.
    
    Fix the error handling path of the probe accordingly.
    
    Fixes: cb496cd472af ("media: cxd2880-spi: Add optional vcc regulator")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34106f5260158dea7c6044fdcdf1b64973d7a3f5
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Feb 8 15:38:55 2021 +0100

    soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally
    
    [ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ]
    
    Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
    To fix this, restrict the automatic enabling of ROCKCHIP_GRF to
    ARCH_ROCKCHIP, and ask the user in case of compile-testing.
    
    Fixes: 4c58063d4258f6be ("soc: rockchip: add driver handling grf setup")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20210208143855.418374-1-geert+renesas@glider.be
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b928930530032a1a4acb9cf197d43b8468767983
Author: Krzysztof Hałasa <khalasa@piap.pl>
Date:   Wed Jun 16 07:13:55 2021 +0200

    media: TDA1997x: enable EDID support
    
    [ Upstream commit ea3e1c36e38810427485f06c2becc1f29e54521d ]
    
    Without this patch, the TDA19971 chip's EDID is inactive.
    EDID never worked with this driver, it was all tested with HDMI signal
    sources which don't need EDID support.
    
    Signed-off-by: Krzysztof Halasa <khalasa@piap.pl>
    Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver")
    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 43282ca83ace5fb4a62b5a41cc147b8e2541b2b2
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Tue Jun 8 14:38:56 2021 +0000

    drm/panfrost: Fix missing clk_disable_unprepare() on error in panfrost_clk_init()
    
    [ Upstream commit f42498705965bd4b026953c1892c686d8b1138e4 ]
    
    Fix the missing clk_disable_unprepare() before return
    from panfrost_clk_init() in the error handling case.
    
    Fixes: b681af0bc1cc ("drm: panfrost: add optional bus_clock")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Signed-off-by: Steven Price <steven.price@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210608143856.4154766-1-weiyongjun1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc9cf222908746dc969fdccfa5a5af44e1a69ad9
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date:   Wed Aug 18 10:57:00 2021 -0700

    EDAC/i10nm: Fix NVDIMM detection
    
    [ Upstream commit 2294a7299f5e51667b841f63c6d69474491753fb ]
    
    MCDDRCFG is a per-channel register and uses bit{0,1} to indicate
    the NVDIMM presence on DIMM slot{0,1}. Current i10nm_edac driver
    wrongly uses MCDDRCFG as per-DIMM register and fails to detect
    the NVDIMM.
    
    Fix it by reading MCDDRCFG as per-channel register and using its
    bit{0,1} to check whether the NVDIMM is populated on DIMM slot{0,1}.
    
    Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors")
    Reported-by: Fan Du <fan.du@intel.com>
    Tested-by: Wen Jin <wen.jin@intel.com>
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20210818175701.1611513-2-tony.luck@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32d8a3684bbade1b3a4bc04533e6f3d6cbc4e6eb
Author: Quanyang Wang <quanyang.wang@windriver.com>
Date:   Thu Aug 26 08:59:30 2021 +0800

    spi: spi-zynq-qspi: use wait_for_completion_timeout to make zynq_qspi_exec_mem_op not interruptible
    
    [ Upstream commit 26cfc0dbe43aae60dc03af27077775244f26c167 ]
    
    The function wait_for_completion_interruptible_timeout will return
    -ERESTARTSYS immediately when receiving SIGKILL signal which is sent
    by "jffs2_gcd_mtd" during umounting jffs2. This will break the SPI memory
    operation because the data transmitting may begin before the command or
    address transmitting completes. Use wait_for_completion_timeout to prevent
    the process from being interruptible.
    
    Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
    Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
    Link: https://lore.kernel.org/r/20210826005930.20572-1-quanyang.wang@windriver.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4206dbc9857bebd1b9beaa5b42ef2df2810ca883
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Thu Aug 26 17:15:46 2021 +0800

    spi: sprd: Fix the wrong WDG_LOAD_VAL
    
    [ Upstream commit 245ca2cc212bb2a078332ec99afbfbb202f44c2d ]
    
    Use 50ms as default timeout value and the time clock is 32768HZ.
    The original value of WDG_LOAD_VAL is not correct, so this patch
    fixes it.
    
    Fixes: ac1775012058 ("spi: sprd: Add the support of restarting the system")
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Link: https://lore.kernel.org/r/20210826091549.2138125-2-zhang.lyra@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f70517eac57fbc0b4cedab0b7aab8f653d733c7
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Aug 25 11:37:04 2021 +0800

    regulator: vctrl: Avoid lockdep warning in enable/disable ops
    
    [ Upstream commit 21e39809fd7c4b8ff3662f23e0168e87594c8ca8 ]
    
    vctrl_enable() and vctrl_disable() call regulator_enable() and
    regulator_disable(), respectively. However, vctrl_* are regulator ops
    and should not be calling the locked regulator APIs. Doing so results in
    a lockdep warning.
    
    Instead of exporting more internal regulator ops, model the ctrl supply
    as an actual supply to vctrl-regulator. At probe time this driver still
    needs to use the consumer API to fetch its constraints, but otherwise
    lets the regulator core handle the upstream supply for it.
    
    The enable/disable/is_enabled ops are not removed, but now only track
    state internally. This preserves the original behavior with the ops
    being available, but one could argue that the original behavior was
    already incorrect: the internal state would not match the upstream
    supply if that supply had another consumer that enabled the supply,
    while vctrl-regulator was not enabled.
    
    The lockdep warning is as follows:
    
            WARNING: possible circular locking dependency detected
            5.14.0-rc6 #2 Not tainted
            ------------------------------------------------------
            swapper/0/1 is trying to acquire lock:
            ffffffc011306d00 (regulator_list_mutex){+.+.}-{3:3}, at:
                    regulator_lock_dependent (arch/arm64/include/asm/current.h:19
                                              include/linux/ww_mutex.h:111
                                              drivers/regulator/core.c:329)
    
            but task is already holding lock:
            ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
                    regulator_lock_recursive (drivers/regulator/core.c:156
                                              drivers/regulator/core.c:263)
    
            which lock already depends on the new lock.
    
            the existing dependency chain (in reverse order) is:
    
            -> #2 (regulator_ww_class_mutex){+.+.}-{3:3}:
            __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
                                 include/asm-generic/atomic-long.h:29
                                 kernel/locking/mutex.c:103
                                 kernel/locking/mutex.c:144
                                 kernel/locking/mutex.c:963)
            ww_mutex_lock (kernel/locking/mutex.c:1199)
            regulator_lock_recursive (drivers/regulator/core.c:156
                                      drivers/regulator/core.c:263)
            regulator_lock_dependent (drivers/regulator/core.c:343)
            regulator_enable (drivers/regulator/core.c:2808)
            set_machine_constraints (drivers/regulator/core.c:1536)
            regulator_register (drivers/regulator/core.c:5486)
            devm_regulator_register (drivers/regulator/devres.c:196)
            reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
            platform_probe (drivers/base/platform.c:1427)
            [...]
    
            -> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
            regulator_lock_dependent (include/linux/ww_mutex.h:129
                                      drivers/regulator/core.c:329)
            regulator_enable (drivers/regulator/core.c:2808)
            set_machine_constraints (drivers/regulator/core.c:1536)
            regulator_register (drivers/regulator/core.c:5486)
            devm_regulator_register (drivers/regulator/devres.c:196)
            reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
            [...]
    
            -> #0 (regulator_list_mutex){+.+.}-{3:3}:
            __lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
                            kernel/locking/lockdep.c:3174 (discriminator 4)
                            kernel/locking/lockdep.c:3789 (discriminator 4)
                            kernel/locking/lockdep.c:5015 (discriminator 4))
            lock_acquire (arch/arm64/include/asm/percpu.h:39
                          kernel/locking/lockdep.c:438
                          kernel/locking/lockdep.c:5627)
            __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
                                 include/asm-generic/atomic-long.h:29
                                 kernel/locking/mutex.c:103
                                 kernel/locking/mutex.c:144
                                 kernel/locking/mutex.c:963)
            mutex_lock_nested (kernel/locking/mutex.c:1125)
            regulator_lock_dependent (arch/arm64/include/asm/current.h:19
                                      include/linux/ww_mutex.h:111
                                      drivers/regulator/core.c:329)
            regulator_enable (drivers/regulator/core.c:2808)
            vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
            _regulator_do_enable (drivers/regulator/core.c:2617)
            _regulator_enable (drivers/regulator/core.c:2764)
            regulator_enable (drivers/regulator/core.c:308
                              drivers/regulator/core.c:2809)
            _set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
            dev_pm_opp_set_rate (drivers/opp/core.c:1164)
            set_target (drivers/cpufreq/cpufreq-dt.c:62)
            __cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
                                     drivers/cpufreq/cpufreq.c:2271)
            cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
            cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
            subsys_interface_register (drivers/base/bus.c:?)
            cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
            dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
            [...]
    
            other info that might help us debug this:
    
            Chain exists of:
              regulator_list_mutex --> regulator_ww_class_acquire --> regulator_ww_class_mutex
    
             Possible unsafe locking scenario:
    
                   CPU0                    CPU1
                   ----                    ----
              lock(regulator_ww_class_mutex);
                                           lock(regulator_ww_class_acquire);
                                           lock(regulator_ww_class_mutex);
              lock(regulator_list_mutex);
    
             *** DEADLOCK ***
    
            6 locks held by swapper/0/1:
            #0: ffffff8002d32188 (&dev->mutex){....}-{3:3}, at:
                    __device_driver_lock (drivers/base/dd.c:1030)
            #1: ffffffc0111a0520 (cpu_hotplug_lock){++++}-{0:0}, at:
                    cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2792 (discriminator 2))
            #2: ffffff8002a8d918 (subsys mutex#9){+.+.}-{3:3}, at:
                    subsys_interface_register (drivers/base/bus.c:1033)
            #3: ffffff800341bb90 (&policy->rwsem){+.+.}-{3:3}, at:
                    cpufreq_online (include/linux/bitmap.h:285
                                    include/linux/cpumask.h:405
                                    drivers/cpufreq/cpufreq.c:1399)
            #4: ffffffc011f0b7b8 (regulator_ww_class_acquire){+.+.}-{0:0}, at:
                    regulator_enable (drivers/regulator/core.c:2808)
            #5: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
                    regulator_lock_recursive (drivers/regulator/core.c:156
                    drivers/regulator/core.c:263)
    
            stack backtrace:
            CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc6 #2 7c8f8996d021ed0f65271e6aeebf7999de74a9fa
            Hardware name: Google Scarlet (DT)
            Call trace:
            dump_backtrace (arch/arm64/kernel/stacktrace.c:161)
            show_stack (arch/arm64/kernel/stacktrace.c:218)
            dump_stack_lvl (lib/dump_stack.c:106 (discriminator 2))
            dump_stack (lib/dump_stack.c:113)
            print_circular_bug (kernel/locking/lockdep.c:?)
            check_noncircular (kernel/locking/lockdep.c:?)
            __lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
                            kernel/locking/lockdep.c:3174 (discriminator 4)
                            kernel/locking/lockdep.c:3789 (discriminator 4)
                            kernel/locking/lockdep.c:5015 (discriminator 4))
            lock_acquire (arch/arm64/include/asm/percpu.h:39
                          kernel/locking/lockdep.c:438
                          kernel/locking/lockdep.c:5627)
            __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
                                 include/asm-generic/atomic-long.h:29
                                 kernel/locking/mutex.c:103
                                 kernel/locking/mutex.c:144
                                 kernel/locking/mutex.c:963)
            mutex_lock_nested (kernel/locking/mutex.c:1125)
            regulator_lock_dependent (arch/arm64/include/asm/current.h:19
                                      include/linux/ww_mutex.h:111
                                      drivers/regulator/core.c:329)
            regulator_enable (drivers/regulator/core.c:2808)
            vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
            _regulator_do_enable (drivers/regulator/core.c:2617)
            _regulator_enable (drivers/regulator/core.c:2764)
            regulator_enable (drivers/regulator/core.c:308
                              drivers/regulator/core.c:2809)
            _set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
            dev_pm_opp_set_rate (drivers/opp/core.c:1164)
            set_target (drivers/cpufreq/cpufreq-dt.c:62)
            __cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
                                     drivers/cpufreq/cpufreq.c:2271)
            cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
            cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
            subsys_interface_register (drivers/base/bus.c:?)
            cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
            dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
            [...]
    
    Reported-by: Brian Norris <briannorris@chromium.org>
    Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
    Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d255d6a6457f4f801db4202862ca23a6af7e3dfe
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Aug 25 11:37:03 2021 +0800

    regulator: vctrl: Use locked regulator_get_voltage in probe path
    
    [ Upstream commit 98e47570ba985f2310586c80409238200fa3170f ]
    
    In commit e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting
    and setting the voltage"), all calls to get/set the voltage of the
    control regulator were switched to unlocked versions to avoid deadlocks.
    However, the call in the probe path is done without regulator locks
    held. In this case the locked version should be used.
    
    Switch back to the locked regulator_get_voltage() in the probe path to
    avoid any mishaps.
    
    Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20210825033704.3307263-2-wenst@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 013177ccc4c5d1a2437545655d912d2844bd64db
Author: Stefan Berger <stefanb@linux.ibm.com>
Date:   Tue Jun 29 17:34:20 2021 -0400

    certs: Trigger creation of RSA module signing key if it's not an RSA key
    
    [ Upstream commit ea35e0d5df6c92fa2e124bb1b91d09b2240715ba ]
    
    Address a kbuild issue where a developer created an ECDSA key for signing
    kernel modules and then builds an older version of the kernel, when bi-
    secting the kernel for example, that does not support ECDSA keys.
    
    If openssl is installed, trigger the creation of an RSA module signing
    key if it is not an RSA key.
    
    Fixes: cfc411e7fff3 ("Move certificate handling to its own directory")
    Cc: David Howells <dhowells@redhat.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Tested-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc74533a47c9dd03ec38cddcad5361fce63987d6
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Aug 12 21:21:10 2021 +0100

    crypto: qat - use proper type for vf_mask
    
    [ Upstream commit 462354d986b6a89c6449b85f17aaacf44e455216 ]
    
    Replace vf_mask type with unsigned long to avoid a stack-out-of-bound.
    
    This is to fix the following warning reported by KASAN the first time
    adf_msix_isr_ae() gets called.
    
        [  692.091987] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x28/0x50
        [  692.092017] Read of size 8 at addr ffff88afdf789e60 by task swapper/32/0
        [  692.092076] Call Trace:
        [  692.092089]  <IRQ>
        [  692.092101]  dump_stack+0x9c/0xcf
        [  692.092132]  print_address_description.constprop.0+0x18/0x130
        [  692.092164]  ? find_first_bit+0x28/0x50
        [  692.092185]  kasan_report.cold+0x7f/0x111
        [  692.092213]  ? static_obj+0x10/0x80
        [  692.092234]  ? find_first_bit+0x28/0x50
        [  692.092262]  find_first_bit+0x28/0x50
        [  692.092288]  adf_msix_isr_ae+0x16e/0x230 [intel_qat]
    
    Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3fa499d72a0db612f12645265a36751955c0037
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Aug 12 12:15:01 2021 +0300

    block: nbd: add sanity check for first_minor
    
    [ Upstream commit b1a811633f7321cf1ae2bb76a66805b7720e44c9 ]
    
    Syzbot hit WARNING in internal_create_group(). The problem was in
    too big disk->first_minor.
    
    disk->first_minor is initialized by value, which comes from userspace
    and there wasn't any sanity checks about value correctness. It can cause
    duplicate creation of sysfs files/links, because disk->first_minor will
    be passed to MKDEV() which causes truncation to byte. Since maximum
    minor value is 0xff, let's check if first_minor is correct minor number.
    
    NOTE: the root case of the reported warning was in wrong error handling
    in register_disk(), but we can avoid passing knowingly wrong values to
    sysfs API, because sysfs error messages can confuse users. For example:
    user passed 1048576 as index, but sysfs complains about duplicate
    creation of /dev/block/43:0. It's not obvious how 1048576 becomes 0.
    Log and reproducer for above example can be found on syzkaller bug
    report page.
    
    Link: https://syzkaller.appspot.com/bug?id=03c2ae9146416edf811958d5fd7acfab75b143d1
    Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices")
    Reported-by: syzbot+9937dc42271cd87d4b98@syzkaller.appspotmail.com
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c60a31db3990a144adc95df1feed9f7ebba6cd27
Author: Phong Hoang <phong.hoang.wz@renesas.com>
Date:   Thu Apr 22 14:34:43 2021 +0200

    clocksource/drivers/sh_cmt: Fix wrong setting if don't request IRQ for clock source channel
    
    [ Upstream commit be83c3b6e7b8ff22f72827a613bf6f3aa5afadbb ]
    
    If CMT instance has at least two channels, one channel will be used
    as a clock source and another one used as a clock event device.
    In that case, IRQ is not requested for clock source channel so
    sh_cmt_clock_event_program_verify() might work incorrectly.
    Besides, when a channel is only used for clock source, don't need to
    re-set the next match_value since it should be maximum timeout as
    it still is.
    
    On the other hand, due to no IRQ, total_cycles is not counted up
    when reaches compare match time (timer counter resets to zero),
    so sh_cmt_clocksource_read() returns unexpected value.
    Therefore, use 64-bit clocksoure's mask for 32-bit or 16-bit variants
    will also lead to wrong delta calculation. Hence, this mask should
    correspond to timer counter width, and above function just returns
    the raw value of timer counter register.
    
    Fixes: bfa76bb12f23 ("clocksource: sh_cmt: Request IRQ for clock event device only")
    Fixes: 37e7742c55ba ("clocksource/drivers/sh_cmt: Fix clocksource width for 32-bit machines")
    Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
    Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20210422123443.73334-1-niklas.soderlund+renesas@ragnatech.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b10d3d3a9ff260d734e0072a3b3792e4f1bbea5
Author: Hongbo Li <herberthbli@tencent.com>
Date:   Thu Aug 5 16:53:32 2021 +0800

    lib/mpi: use kcalloc in mpi_resize
    
    [ Upstream commit b6f756726e4dfe75be1883f6a0202dcecdc801ab ]
    
    We should set the additional space to 0 in mpi_resize().
    So use kcalloc() instead of kmalloc_array().
    
    In lib/mpi/ec.c:
    /****************
     * Resize the array of A to NLIMBS. the additional space is cleared
     * (set to 0) [done by m_realloc()]
     */
    int mpi_resize(MPI a, unsigned nlimbs)
    
    Like the comment of kernel's mpi_resize() said, the additional space
    need to be set to 0, but when a->d is not NULL, it does not set.
    
    The kernel's mpi lib is from libgcrypt, the mpi resize in libgcrypt
    is _gcry_mpi_resize() which set the additional space to 0.
    
    This bug may cause mpi api which use mpi_resize() get wrong result
    under the condition of using the additional space without initiation.
    If this condition is not met, the bug would not be triggered.
    Currently in kernel, rsa, sm2 and dh use mpi lib, and they works well,
    so the bug is not triggered in these cases.
    
    add_points_edwards() use the additional space directly, so it will
    get a wrong result.
    
    Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)")
    Signed-off-by: Hongbo Li <herberthbli@tencent.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57c8e2ea47bcca90bda5c8b3da8182a25da985e3
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Wed Aug 11 17:33:32 2021 +0800

    genirq/timings: Fix error return code in irq_timings_test_irqs()
    
    [ Upstream commit 290fdc4b7ef14e33d0e30058042b0e9bfd02b89b ]
    
    Return a negative error code from the error handling case instead of 0, as
    done elsewhere in this function.
    
    Fixes: f52da98d900e ("genirq/timings: Add selftest for irqs circular buffer")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20210811093333.2376-1-thunder.leizhen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d00b22c8b8136f5b86af6772be6d556fe227962
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Aug 10 11:17:27 2021 +0300

    spi: spi-pic32: Fix issue with uninitialized dma_slave_config
    
    [ Upstream commit 976c1de1de147bb7f4e0d87482f375221c05aeaf ]
    
    Depending on the DMA driver being used, the struct dma_slave_config may
    need to be initialized to zero for the unused data.
    
    For example, we have three DMA drivers using src_port_window_size and
    dst_port_window_size. If these are left uninitialized, it can cause DMA
    failures.
    
    For spi-pic32, this is probably not currently an issue but is still good to
    fix though.
    
    Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver")
    Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
    Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210810081727.19491-2-tony@atomide.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b29593d0696d81fc6bbfd510f74391cb2cc6b8d5
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Aug 10 11:17:26 2021 +0300

    spi: spi-fsl-dspi: Fix issue with uninitialized dma_slave_config
    
    [ Upstream commit 209ab223ad5b18e437289235e3bde12593b94ac4 ]
    
    Depending on the DMA driver being used, the struct dma_slave_config may
    need to be initialized to zero for the unused data.
    
    For example, we have three DMA drivers using src_port_window_size and
    dst_port_window_size. If these are left uninitialized, it can cause DMA
    failures.
    
    For spi-fsl-dspi, this is probably not currently an issue but is still
    good to fix though.
    
    Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid")
    Cc: Sanchayan Maity <maitysanchayan@gmail.com>
    Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
    Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Acked-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Link: https://lore.kernel.org/r/20210810081727.19491-1-tony@atomide.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 449884aeb3587ac38fd142a5448f178de37e5421
Author: Quentin Perret <qperret@google.com>
Date:   Thu Aug 5 11:21:53 2021 +0100

    sched: Fix UCLAMP_FLAG_IDLE setting
    
    [ Upstream commit ca4984a7dd863f3e1c0df775ae3e744bff24c303 ]
    
    The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last
    uclamp active task (that is, when buckets.tasks reaches 0 for all
    buckets) to maintain the last uclamp.max and prevent blocked util from
    suddenly becoming visible.
    
    However, there is an asymmetry in how the flag is set and cleared which
    can lead to having the flag set whilst there are active tasks on the rq.
    Specifically, the flag is cleared in the uclamp_rq_inc() path, which is
    called at enqueue time, but set in uclamp_rq_dec_id() which is called
    both when dequeueing a task _and_ in the update_uclamp_active() path. As
    a result, when both uclamp_rq_{dec,ind}_id() are called from
    update_uclamp_active(), the flag ends up being set but not cleared,
    hence leaving the runqueue in a broken state.
    
    Fix this by clearing the flag in update_uclamp_active() as well.
    
    Fixes: e496187da710 ("sched/uclamp: Enforce last task's UCLAMP_MAX")
    Reported-by: Rick Yiu <rickyiu@google.com>
    Signed-off-by: Quentin Perret <qperret@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Qais Yousef <qais.yousef@arm.com>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Link: https://lore.kernel.org/r/20210805102154.590709-2-qperret@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67da2d9c9e9943be4258ee94906cf3be367df152
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Mon Jul 5 23:47:27 2021 +0300

    m68k: emu: Fix invalid free in nfeth_cleanup()
    
    [ Upstream commit 761608f5cf70e8876c2f0e39ca54b516bdcb7c12 ]
    
    In the for loop all nfeth_dev array members should be freed, not only
    the first one.  Freeing only the first array member can cause
    double-free bugs and memory leaks.
    
    Fixes: 9cd7b148312f ("m68k/atari: ARAnyM - Add support for network access")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/20210705204727.10743-1-paskripkin@gmail.com
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c68ba4a708fbd0efdc384cd29250bb292a45e559
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Fri Aug 13 15:05:03 2021 +0200

    s390/debug: fix debug area life cycle
    
    [ Upstream commit 9372a82892c2caa6bccab9a4081166fa769699f8 ]
    
    Currently allocation and registration of s390dbf debug areas are tied
    together. As a result, a debug area cannot be unregistered and
    re-registered while any process has an associated debugfs file open.
    
    Fix this by splitting alloc/release from register/unregister.
    
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a67a00ea8a7d4a9df6fa5585d90f5cc7877733e
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Fri Aug 6 12:55:08 2021 +0200

    s390/kasan: fix large PMD pages address alignment check
    
    [ Upstream commit ddd63c85ef67ea9ea7282ad35eafb6568047126e ]
    
    It is currently possible to initialize a large PMD page when
    the address is not aligned on page boundary.
    
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98296eb3deca34760f6c98478d7d2454b4005ff1
Author: Stian Skjelstad <stian.skjelstad@gmail.com>
Date:   Sun Aug 22 11:33:32 2021 +0200

    udf_get_extendedattr() had no boundary checks.
    
    [ Upstream commit 58bc6d1be2f3b0ceecb6027dfa17513ec6aa2abb ]
    
    When parsing the ExtendedAttr data, malicous or corrupt attribute length
    could cause kernel hangs and buffer overruns in some special cases.
    
    Link: https://lore.kernel.org/r/20210822093332.25234-1-stian.skjelstad@gmail.com
    Signed-off-by: Stian Skjelstad <stian.skjelstad@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae4240d1f4bf3e253bd3c429d54de9975595f7da
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date:   Fri Jul 2 17:18:31 2021 +0800

    fcntl: fix potential deadlock for &fasync_struct.fa_lock
    
    [ Upstream commit 2f488f698fda820f8e6fa0407630154eceb145d6 ]
    
    There is an existing lock hierarchy of
    &dev->event_lock --> &fasync_struct.fa_lock --> &f->f_owner.lock
    from the following call chain:
    
      input_inject_event():
        spin_lock_irqsave(&dev->event_lock,...);
        input_handle_event():
          input_pass_values():
            input_to_handler():
              evdev_events():
                evdev_pass_values():
                  spin_lock(&client->buffer_lock);
                  __pass_event():
                    kill_fasync():
                      kill_fasync_rcu():
                        read_lock(&fa->fa_lock);
                        send_sigio():
                          read_lock_irqsave(&fown->lock,...);
    
    &dev->event_lock is HARDIRQ-safe, so interrupts have to be disabled
    while grabbing &fasync_struct.fa_lock, otherwise we invert the lock
    hierarchy. However, since kill_fasync which calls kill_fasync_rcu is
    an exported symbol, it may not necessarily be called with interrupts
    disabled.
    
    As kill_fasync_rcu may be called with interrupts disabled (for
    example, in the call chain above), we replace calls to
    read_lock/read_unlock on &fasync_struct.fa_lock in kill_fasync_rcu
    with read_lock_irqsave/read_unlock_irqrestore.
    
    Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6273c8c2aca93782746af84f97fae20d481c3e6
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Aug 12 21:21:28 2021 +0100

    crypto: qat - do not export adf_iov_putmsg()
    
    [ Upstream commit 645ae0af1840199086c33e4f841892ebee73f615 ]
    
    The function adf_iov_putmsg() is only used inside the intel_qat module
    therefore should not be exported.
    Remove EXPORT_SYMBOL for the function adf_iov_putmsg().
    
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7dfa7bb69e1322c81b52b8a4d405791a47f8ff38
Author: Marco Chiappero <marco.chiappero@intel.com>
Date:   Thu Aug 12 21:21:22 2021 +0100

    crypto: qat - fix naming for init/shutdown VF to PF notifications
    
    [ Upstream commit b90c1c4d3fa8cd90f4e8245b13564380fd0bfad1 ]
    
    At start and shutdown, VFs notify the PF about their state. These
    notifications are carried out through a message exchange using the PFVF
    protocol.
    
    Function names lead to believe they do perform init or shutdown logic.
    This is to fix the naming to better reflect their purpose.
    
    Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
    Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 843b4e713a80b7cfdceb79833fdcfeaf66870859
Author: Marco Chiappero <marco.chiappero@intel.com>
Date:   Thu Aug 12 21:21:19 2021 +0100

    crypto: qat - fix reuse of completion variable
    
    [ Upstream commit 3d655732b0199562267a05c7ff69ecdd11632939 ]
    
    Use reinit_completion() to set to a clean state a completion variable,
    used to coordinate the VF to PF request-response flow, before every
    new VF request.
    
    Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
    Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a988264556c809444e62a46d72c76aaffdb067e
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Aug 12 21:21:14 2021 +0100

    crypto: qat - handle both source of interrupt in VF ISR
    
    [ Upstream commit 0a73c762e1eee33a5e5dc0e3488f1b7cd17249b3 ]
    
    The top half of the VF drivers handled only a source at the time.
    If an interrupt for PF2VF and bundle occurred at the same time, the ISR
    scheduled only the bottom half for PF2VF.
    This patch fixes the VF top half so that if both sources of interrupt
    trigger at the same time, both bottom halves are scheduled.
    
    This patch is based on earlier work done by Conor McLoughlin.
    
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2b3f81125a6b197796c78927ccfd8de757c49da
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Aug 12 21:21:13 2021 +0100

    crypto: qat - do not ignore errors from enable_vf2pf_comms()
    
    [ Upstream commit 5147f0906d50a9d26f2b8698cd06b5680e9867ff ]
    
    The function adf_dev_init() ignores the error code reported by
    enable_vf2pf_comms(). If the latter fails, e.g. the VF is not compatible
    with the pf, then the load of the VF driver progresses.
    This patch changes adf_dev_init() so that the error code from
    enable_vf2pf_comms() is returned to the caller.
    
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c189ccef0cfaf292a816f9abcc7a1b11fe094c6
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Mon Aug 16 10:44:47 2021 +0900

    libata: fix ata_host_start()
    
    [ Upstream commit 355a8031dc174450ccad2a61c513ad7222d87a97 ]
    
    The loop on entry of ata_host_start() may not initialize host->ops to a
    non NULL value. The test on the host_stop field of host->ops must then
    be preceded by a check that host->ops is not NULL.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20210816014456.2191776-3-damien.lemoal@wdc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e55b627d6e1f13ee73ec3525f1e4ff0b48a85453
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Sun Apr 25 10:52:38 2021 +0200

    s390/cio: add dev_busid sysfs entry for each subchannel
    
    [ Upstream commit d3683c055212bf910d4e318f7944910ce10dbee6 ]
    
    Introduce dev_busid, which exports the device-id associated with the
    io-subchannel (and message-subchannel). The dev_busid indicates that of
    the device which may be physically installed on the corrosponding
    subchannel. The dev_busid value "none" indicates that the subchannel
    is not valid, there is no I/O device currently associated with the
    subchannel.
    
    The dev_busid information would be helpful to write device-specific
    udev-rules associated with the subchannel. The dev_busid interface would
    be available even when the sch is not bound to any driver or if there is
    no operational device connected on it. Hence this attribute can be used to
    write udev-rules which are specific to the device associated with the
    subchannel.
    
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0423517520d306464688aca8fa445db29a0d5673
Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Date:   Mon Aug 16 18:50:14 2021 +0200

    power: supply: max17042_battery: fix typo in MAx17042_TOFF
    
    [ Upstream commit ed0d0a0506025f06061325cedae1bbebd081620a ]
    
    Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb45ae88bf106108b5991a4b25b741e69187978e
Author: Amit Engel <amit.engel@dell.com>
Date:   Sun Aug 8 09:20:14 2021 +0300

    nvmet: pass back cntlid on successful completion
    
    [ Upstream commit e804d5abe2d74cfe23f5f83be580d1cdc9307111 ]
    
    According to the NVMe specification, the response dword 0 value of the
    Connect command is based on status code: return cntlid for successful
    compeltion return IPO and IATTR for connect invalid parameters.  Fix
    a missing error information for a zero sized queue, and return the
    cntlid also for I/O queue Connect commands.
    
    Signed-off-by: Amit Engel <amit.engel@dell.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cb5d6ae687df7690694ba3783915f89a6547de4
Author: Ruozhu Li <liruozhu@huawei.com>
Date:   Wed Jul 28 17:41:20 2021 +0800

    nvme-rdma: don't update queue count when failing to set io queues
    
    [ Upstream commit 85032874f80ba17bf187de1d14d9603bf3f582b8 ]
    
    We update ctrl->queue_count and schedule another reconnect when io queue
    count is zero.But we will never try to create any io queue in next reco-
    nnection, because ctrl->queue_count already set to zero.We will end up
    having an admin-only session in Live state, which is exactly what we try
    to avoid in the original patch.
    Update ctrl->queue_count after queue_count zero checking to fix it.
    
    Signed-off-by: Ruozhu Li <liruozhu@huawei.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3073ec7f064245437b0c780ca20c8fe9491e6f07
Author: Ruozhu Li <liruozhu@huawei.com>
Date:   Sat Aug 7 11:50:23 2021 +0800

    nvme-tcp: don't update queue count when failing to set io queues
    
    [ Upstream commit 664227fde63844d69e9ec9e90a8a7801e6ff072d ]
    
    We update ctrl->queue_count and schedule another reconnect when io queue
    count is zero.But we will never try to create any io queue in next reco-
    nnection, because ctrl->queue_count already set to zero.We will end up
    having an admin-only session in Live state, which is exactly what we try
    to avoid in the original patch.
    Update ctrl->queue_count after queue_count zero checking to fix it.
    
    Signed-off-by: Ruozhu Li <liruozhu@huawei.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93cf19b4d9b33786e584aae57ab908b04fed29dc
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Aug 9 08:40:26 2021 +0200

    bcache: add proper error unwinding in bcache_device_init
    
    [ Upstream commit 224b0683228c5f332f9cee615d85e75e9a347170 ]
    
    Except for the IDA none of the allocations in bcache_device_init is
    unwound on error, fix that.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20210809064028.1198327-7-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e55f20798f5305f32236431a53e23ab04efa6aa3
Author: Pali Rohár <pali@kernel.org>
Date:   Sun Aug 8 18:24:37 2021 +0200

    isofs: joliet: Fix iocharset=utf8 mount option
    
    [ Upstream commit 28ce50f8d96ec9035f60c9348294ea26b94db944 ]
    
    Currently iocharset=utf8 mount option is broken. To use UTF-8 as iocharset,
    it is required to use utf8 mount option.
    
    Fix iocharset=utf8 mount option to use be equivalent to the utf8 mount
    option.
    
    If UTF-8 as iocharset is used then s_nls_iocharset is set to NULL. So
    simplify code around, remove s_utf8 field as to distinguish between UTF-8
    and non-UTF-8 it is needed just to check if s_nls_iocharset is set to NULL
    or not.
    
    Link: https://lore.kernel.org/r/20210808162453.1653-5-pali@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f5cd92e5eb53c08309285b9d923fa7602bc613d
Author: Pali Rohár <pali@kernel.org>
Date:   Sun Aug 8 18:24:36 2021 +0200

    udf: Fix iocharset=utf8 mount option
    
    [ Upstream commit b645333443712d2613e4e863f81090d5dc509657 ]
    
    Currently iocharset=utf8 mount option is broken. To use UTF-8 as iocharset,
    it is required to use utf8 mount option.
    
    Fix iocharset=utf8 mount option to use be equivalent to the utf8 mount
    option.
    
    If UTF-8 as iocharset is used then s_nls_map is set to NULL. So simplify
    code around, remove UDF_FLAG_NLS_MAP and UDF_FLAG_UTF8 flags as to
    distinguish between UTF-8 and non-UTF-8 it is needed just to check if
    s_nls_map set to NULL or not.
    
    Link: https://lore.kernel.org/r/20210808162453.1653-4-pali@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86987cf0fbd279c7917e7c60af6d2ce2760d341c
Author: Jan Kara <jack@suse.cz>
Date:   Mon May 3 11:39:03 2021 +0200

    udf: Check LVID earlier
    
    [ Upstream commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d ]
    
    We were checking validity of LVID entries only when getting
    implementation use information from LVID in udf_sb_lvidiu(). However if
    the LVID is suitably corrupted, it can cause problems also to code such
    as udf_count_free() which doesn't use udf_sb_lvidiu(). So check validity
    of LVID already when loading it from the disk and just disable LVID
    altogether when it is not valid.
    
    Reported-by: syzbot+7fbfe5fed73ebb675748@syzkaller.appspotmail.com
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc608af36e0007402ac326c84db8826fc9ebd08e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jul 13 15:39:48 2021 +0200

    hrtimer: Ensure timerfd notification for HIGHRES=n
    
    [ Upstream commit 8c3b5e6ec0fee18bc2ce38d1dfe913413205f908 ]
    
    If high resolution timers are disabled the timerfd notification about a
    clock was set event is not happening for all cases which use
    clock_was_set_delayed() because that's a NOP for HIGHRES=n, which is wrong.
    
    Make clock_was_set_delayed() unconditially available to fix that.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20210713135158.196661266@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8457878307fa3683bd836cf3249de41efc3fabf
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jul 13 15:39:46 2021 +0200

    hrtimer: Avoid double reprogramming in __hrtimer_start_range_ns()
    
    [ Upstream commit 627ef5ae2df8eeccb20d5af0e4cfa4df9e61ed28 ]
    
    If __hrtimer_start_range_ns() is invoked with an already armed hrtimer then
    the timer has to be canceled first and then added back. If the timer is the
    first expiring timer then on removal the clockevent device is reprogrammed
    to the next expiring timer to avoid that the pending expiry fires needlessly.
    
    If the new expiry time ends up to be the first expiry again then the clock
    event device has to reprogrammed again.
    
    Avoid this by checking whether the timer is the first to expire and in that
    case, keep the timer on the current CPU and delay the reprogramming up to
    the point where the timer has been enqueued again.
    
    Reported-by: Lorenzo Colitti <lorenzo@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20210713135157.873137732@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c322a963d522e9a4273e18c9d7bd6fd40a25160f
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Mon Jul 26 14:55:10 2021 +0200

    posix-cpu-timers: Force next expiration recalc after itimer reset
    
    [ Upstream commit 406dd42bd1ba0c01babf9cde169bb319e52f6147 ]
    
    When an itimer deactivates a previously armed expiration, it simply doesn't
    do anything. As a result the process wide cputime counter keeps running and
    the tick dependency stays set until it reaches the old ghost expiration
    value.
    
    This can be reproduced with the following snippet:
    
            void trigger_process_counter(void)
            {
                    struct itimerval n = {};
    
                    n.it_value.tv_sec = 100;
                    setitimer(ITIMER_VIRTUAL, &n, NULL);
                    n.it_value.tv_sec = 0;
                    setitimer(ITIMER_VIRTUAL, &n, NULL);
            }
    
    Fix this with resetting the relevant base expiration. This is similar to
    disarming a timer.
    
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20210726125513.271824-4-frederic@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28996dbb8a74e0ffc8715f3fd463efafa0947db1
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date:   Sat May 22 00:56:23 2021 +0900

    rcu/tree: Handle VM stoppage in stall detection
    
    [ Upstream commit ccfc9dd6914feaa9a81f10f9cce56eb0f7712264 ]
    
    The soft watchdog timer function checks if a virtual machine
    was suspended and hence what looks like a lockup in fact
    is a false positive.
    
    This is what kvm_check_and_clear_guest_paused() does: it
    tests guest PVCLOCK_GUEST_STOPPED (which is set by the host)
    and if it's set then we need to touch all watchdogs and bail
    out.
    
    Watchdog timer function runs from IRQ, so PVCLOCK_GUEST_STOPPED
    check works fine.
    
    There is, however, one more watchdog that runs from IRQ, so
    watchdog timer fn races with it, and that watchdog is not aware
    of PVCLOCK_GUEST_STOPPED - RCU stall detector.
    
    apic_timer_interrupt()
     smp_apic_timer_interrupt()
      hrtimer_interrupt()
       __hrtimer_run_queues()
        tick_sched_timer()
         tick_sched_handle()
          update_process_times()
           rcu_sched_clock_irq()
    
    This triggers RCU stalls on our devices during VM resume.
    
    If tick_sched_handle()->rcu_sched_clock_irq() runs on a VCPU
    before watchdog_timer_fn()->kvm_check_and_clear_guest_paused()
    then there is nothing on this VCPU that touches watchdogs and
    RCU reads stale gp stall timestamp and new jiffies value, which
    makes it think that RCU has stalled.
    
    Make RCU stall watchdog aware of PVCLOCK_GUEST_STOPPED and
    don't report RCU stalls when we resume the VM.
    
    Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7c560ae51c606d9ed7c9753f11719ff71b652f4
Author: Dietmar Eggemann <dietmar.eggemann@arm.com>
Date:   Wed Aug 4 15:59:25 2021 +0200

    sched/deadline: Fix missing clock update in migrate_task_rq_dl()
    
    [ Upstream commit b4da13aa28d4fd0071247b7b41c579ee8a86c81a ]
    
    A missing clock update is causing the following warning:
    
    rq->clock_update_flags < RQCF_ACT_SKIP
    WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453
    sub_running_bw.isra.0+0x190/0x1a0
    ...
    CPU: 112 PID: 2041 Comm: sugov:112 Tainted: G W 5.14.0-rc1 #1
    Hardware name: WIWYNN Mt.Jade Server System
    B81.030Z1.0007/Mt.Jade Motherboard, BIOS 1.6.20210526 (SCP:
    1.06.20210526) 2021/05/26
    ...
    Call trace:
      sub_running_bw.isra.0+0x190/0x1a0
      migrate_task_rq_dl+0xf8/0x1e0
      set_task_cpu+0xa8/0x1f0
      try_to_wake_up+0x150/0x3d4
      wake_up_q+0x64/0xc0
      __up_write+0xd0/0x1c0
      up_write+0x4c/0x2b0
      cppc_set_perf+0x120/0x2d0
      cppc_cpufreq_set_target+0xe0/0x1a4 [cppc_cpufreq]
      __cpufreq_driver_target+0x74/0x140
      sugov_work+0x64/0x80
      kthread_worker_fn+0xe0/0x230
      kthread+0x138/0x140
      ret_from_fork+0x10/0x18
    
    The task causing this is the `cppc_fie` DL task introduced by
    commit 1eb5dde674f5 ("cpufreq: CPPC: Add support for frequency
    invariance").
    
    With CONFIG_ACPI_CPPC_CPUFREQ_FIE=y and schedutil cpufreq governor on
    slow-switching system (like on this Ampere Altra WIWYNN Mt. Jade Arm
    Server):
    
    DL task `curr=sugov:112` lets `p=cppc_fie` migrate and since the latter
    is in `non_contending` state, migrate_task_rq_dl() calls
    
      sub_running_bw()->__sub_running_bw()->cpufreq_update_util()->
      rq_clock()->assert_clock_updated()
    
    on p.
    
    Fix this by updating the clock for a non_contending task in
    migrate_task_rq_dl() before calling sub_running_bw().
    
    Reported-by: Bruno Goncalves <bgoncalv@redhat.com>
    Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://lore.kernel.org/r/20210804135925.3734605-1-dietmar.eggemann@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40db13e3efcec79553e36cfa97a9cc7adf04c6b6
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Jul 27 13:23:34 2021 +0300

    crypto: omap-sham - clear dma flags only after omap_sham_update_dma_stop()
    
    [ Upstream commit fe28140b3393b0ba1eb95cc109f974a7e58b26fd ]
    
    We should not clear FLAGS_DMA_ACTIVE before omap_sham_update_dma_stop() is
    done calling dma_unmap_sg(). We already clear FLAGS_DMA_ACTIVE at the
    end of omap_sham_update_dma_stop().
    
    The early clearing of FLAGS_DMA_ACTIVE is not causing issues as we do not
    need to defer anything based on FLAGS_DMA_ACTIVE currently. So this can be
    applied as clean-up.
    
    Cc: Lokesh Vutla <lokeshvutla@ti.com>
    Cc: Tero Kristo <kristo@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebf0f71ae3bdadcd1186167b236681822579e0d2
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Aug 1 15:30:59 2021 +0200

    power: supply: axp288_fuel_gauge: Report register-address on readb / writeb errors
    
    [ Upstream commit caa534c3ba40c6e8352b42cbbbca9ba481814ac8 ]
    
    When fuel_gauge_reg_readb()/_writeb() fails, report which register we
    were trying to read / write when the error happened.
    
    Also reword the message a bit:
    - Drop the axp288 prefix, dev_err() already prints this
    - Switch from telegram / abbreviated style to a normal sentence, aligning
      the message with those from fuel_gauge_read_*bit_word()
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bba2b82d1b4815687d7e86b80e77dd235cdf3f9a
Author: Quentin Perret <qperret@google.com>
Date:   Tue Jul 27 11:11:01 2021 +0100

    sched/deadline: Fix reset_on_fork reporting of DL tasks
    
    [ Upstream commit f95091536f78971b269ec321b057b8d630b0ad8a ]
    
    It is possible for sched_getattr() to incorrectly report the state of
    the reset_on_fork flag when called on a deadline task.
    
    Indeed, if the flag was set on a deadline task using sched_setattr()
    with flags (SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_KEEP_PARAMS), then
    p->sched_reset_on_fork will be set, but __setscheduler() will bail out
    early, which means that the dl_se->flags will not get updated by
    __setscheduler_params()->__setparam_dl(). Consequently, if
    sched_getattr() is then called on the task, __getparam_dl() will
    override kattr.sched_flags with the now out-of-date copy in dl_se->flags
    and report the stale value to userspace.
    
    To fix this, make sure to only copy the flags that are relevant to
    sched_deadline to and from the dl_se->flags field.
    
    Signed-off-by: Quentin Perret <qperret@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20210727101103.2729607-2-qperret@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53a6ef40c6bcf13971e48fc6a340d26b971b96d8
Author: Sean Anderson <sean.anderson@seco.com>
Date:   Thu Jul 1 14:56:37 2021 -0400

    crypto: mxs-dcp - Check for DMA mapping errors
    
    [ Upstream commit df6313d707e575a679ada3313358289af24454c0 ]
    
    After calling dma_map_single(), we must also call dma_mapping_error().
    This fixes the following warning when compiling with CONFIG_DMA_API_DEBUG:
    
    [  311.241478] WARNING: CPU: 0 PID: 428 at kernel/dma/debug.c:1027 check_unmap+0x79c/0x96c
    [  311.249547] DMA-API: mxs-dcp 2280000.crypto: device driver failed to check map error[device address=0x00000000860cb080] [size=32 bytes] [mapped as single]
    
    Signed-off-by: Sean Anderson <sean.anderson@seco.com>
    Reviewed-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 344a38789ab26f795a1de23593b22548df56e87e
Author: Jeongtae Park <jeongtae.park@gmail.com>
Date:   Thu Jul 1 23:26:30 2021 +0900

    regmap: fix the offset of register error log
    
    [ Upstream commit 1852f5ed358147095297a09cc3c6f160208a676d ]
    
    This patch fixes the offset of register error log
    by using regmap_get_offset().
    
    Signed-off-by: Jeongtae Park <jeongtae.park@gmail.com>
    Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5e42516a61ead33e5b98c6508547e1cbef0f8ac
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Jun 30 17:35:18 2021 +0200

    locking/mutex: Fix HANDOFF condition
    
    [ Upstream commit 048661a1f963e9517630f080687d48af79ed784c ]
    
    Yanfei reported that setting HANDOFF should not depend on recomputing
    @first, only on @first state. Which would then give:
    
      if (ww_ctx || !first)
        first = __mutex_waiter_is_first(lock, &waiter);
      if (first)
        __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
    
    But because 'ww_ctx || !first' is basically 'always' and the test for
    first is relatively cheap, omit that first branch entirely.
    
    Reported-by: Yanfei Xu <yanfei.xu@windriver.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Yanfei Xu <yanfei.xu@windriver.com>
    Link: https://lore.kernel.org/r/20210630154114.896786297@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>