commit 4d8524048a35c03ff04c25ca1bcdf569f9aeb14a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 22 12:28:07 2021 +0200

    Linux 5.10.68
    
    Link: https://lore.kernel.org/r/20210920163915.757887582@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a23d3576215f7447c547976817b33cb975ecec84
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Sep 16 14:33:35 2021 -0700

    net: dsa: bcm_sf2: Fix array overrun in bcm_sf2_num_active_ports()
    
    commit 02319bf15acf54004216e40ac9c171437f24be24 upstream.
    
    After d12e1c464988 ("net: dsa: b53: Set correct number of ports in the
    DSA struct") we stopped setting dsa_switch::num_ports to DSA_MAX_PORTS,
    which created an off by one error between the statically allocated
    bcm_sf2_priv::port_sts array (of size DSA_MAX_PORTS). When
    dsa_is_cpu_port() is used, we end-up accessing an out of bounds member
    and causing a NPD.
    
    Fix this by iterating with the appropriate port count using
    ds->num_ports.
    
    Fixes: d12e1c464988 ("net: dsa: b53: Set correct number of ports in the DSA struct")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f2972e151dd16d3286c1407bec4e66395f30135
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Sep 12 12:34:47 2021 -0400

    bnxt_en: Fix error recovery regression
    
    commit eca4cf12acda306f851f6d2a05b1c9ef62cf0e81 upstream.
    
    The recent patch has introduced a regression by not reading the reset
    count in the ERROR_RECOVERY async event handler.  We may have just
    gone through a reset and the reset count has just incremented.  If
    we don't update the reset count in the ERROR_RECOVERY event handler,
    the health check timer will see that the reset count has changed and
    will initiate an unintended reset.
    
    Restore the unconditional update of the reset count in
    bnxt_async_event_process() if error recovery watchdog is enabled.
    Also, update the reset count at the end of the reset sequence to
    make it even more robust.
    
    Fixes: 1b2b91831983 ("bnxt_en: Fix possible unintended driver initiated error recovery")
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 619d747c1850bab61625ca9d8b4730f470a5947b
Author: Tony Luck <tony.luck@intel.com>
Date:   Mon Sep 13 14:52:39 2021 -0700

    x86/mce: Avoid infinite loop for copy from user recovery
    
    commit 81065b35e2486c024c7aa86caed452e1f01a59d4 upstream.
    
    There are two cases for machine check recovery:
    
    1) The machine check was triggered by ring3 (application) code.
       This is the simpler case. The machine check handler simply queues
       work to be executed on return to user. That code unmaps the page
       from all users and arranges to send a SIGBUS to the task that
       triggered the poison.
    
    2) The machine check was triggered in kernel code that is covered by
       an exception table entry. In this case the machine check handler
       still queues a work entry to unmap the page, etc. but this will
       not be called right away because the #MC handler returns to the
       fix up code address in the exception table entry.
    
    Problems occur if the kernel triggers another machine check before the
    return to user processes the first queued work item.
    
    Specifically, the work is queued using the ->mce_kill_me callback
    structure in the task struct for the current thread. Attempting to queue
    a second work item using this same callback results in a loop in the
    linked list of work functions to call. So when the kernel does return to
    user, it enters an infinite loop processing the same entry for ever.
    
    There are some legitimate scenarios where the kernel may take a second
    machine check before returning to the user.
    
    1) Some code (e.g. futex) first tries a get_user() with page faults
       disabled. If this fails, the code retries with page faults enabled
       expecting that this will resolve the page fault.
    
    2) Copy from user code retries a copy in byte-at-time mode to check
       whether any additional bytes can be copied.
    
    On the other side of the fence are some bad drivers that do not check
    the return value from individual get_user() calls and may access
    multiple user addresses without noticing that some/all calls have
    failed.
    
    Fix by adding a counter (current->mce_count) to keep track of repeated
    machine checks before task_work() is called. First machine check saves
    the address information and calls task_work_add(). Subsequent machine
    checks before that task_work call back is executed check that the address
    is in the same page as the first machine check (since the callback will
    offline exactly one page).
    
    Expected worst case is four machine checks before moving on (e.g. one
    user access with page faults disabled, then a repeat to the same address
    with page faults enabled ... repeat in copy tail bytes). Just in case
    there is some code that loops forever enforce a limit of 10.
    
     [ bp: Massage commit message, drop noinstr, fix typo, extend panic
       messages. ]
    
    Fixes: 5567d11c21a1 ("x86/mce: Send #MC singal from task work")
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/YT/IJ9ziLqmtqEPu@agluck-desk2.amr.corp.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47bc9c3929eb0bafe805bf87474615c8596d16bc
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Sep 7 20:29:40 2021 +0900

    net: renesas: sh_eth: Fix freeing wrong tx descriptor
    
    [ Upstream commit 0341d5e3d1ee2a36dd5a49b5bef2ce4ad1cfa6b4 ]
    
    The cur_tx counter must be incremented after TACT bit of
    txdesc->status was set. However, a CPU is possible to reorder
    instructions and/or memory accesses between cur_tx and
    txdesc->status. And then, if TX interrupt happened at such a
    timing, the sh_eth_tx_free() may free the descriptor wrongly.
    So, add wmb() before cur_tx++.
    Otherwise NETDEV WATCHDOG timeout is possible to happen.
    
    Fixes: 86a74ff21a7a ("net: sh_eth: add support for Renesas SuperH Ethernet")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2f9b7455baf8ba12113520cdf0398b6141ae42f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Sep 6 17:19:49 2021 -0700

    mfd: lpc_sch: Rename GPIOBASE to prevent build error
    
    [ Upstream commit cdff1eda69326fb46de10c5454212b3efcf4bb41 ]
    
    One MIPS platform (mach-rc32434) defines GPIOBASE. This macro
    conflicts with one of the same name in lpc_sch.c. Rename the latter one
    to prevent the build error.
    
    ../drivers/mfd/lpc_sch.c:25: error: "GPIOBASE" redefined [-Werror]
       25 | #define GPIOBASE        0x44
    ../arch/mips/include/asm/mach-rc32434/rb.h:32: note: this is the location of the previous definition
       32 | #define GPIOBASE        0x050000
    
    Cc: Denis Turischev <denis@compulab.co.il>
    Fixes: e82c60ae7d3a ("mfd: Introduce lpc_sch for Intel SCH LPC bridge")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 027c44b8c8e4140d8dc1633fb32586ab07f1ed3a
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Mar 3 18:49:44 2021 +0200

    mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000"
    
    [ Upstream commit 922e8ce883e59b52786b2c11656d84dc58ef084a ]
    
    The IRQ support for SCH GPIO is not specific to the Intel Quark SoC.
    Moreover the IRQ routing is quite interesting there, so while it's
    needs a special support, the driver haven't it anyway yet.
    
    Due to above remove basically redundant code of IRQ support.
    
    This reverts commit ec689a8a8155ce8b966bd5d7737a3916f5e48be3.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52a7e6667133553a51f93076f96c9294314ae44f
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Sep 5 14:10:59 2021 -0400

    bnxt_en: Fix possible unintended driver initiated error recovery
    
    [ Upstream commit 1b2b91831983aeac3adcbb469aa8b0dc71453f89 ]
    
    If error recovery is already enabled, bnxt_timer() will periodically
    check the heartbeat register and the reset counter.  If we get an
    error recovery async. notification from the firmware (e.g. change in
    primary/secondary role), we will immediately read and update the
    heartbeat register and the reset counter.  If the timer for the next
    health check expires soon after this, we may read the heartbeat register
    again in quick succession and find that it hasn't changed.  This will
    trigger error recovery unintentionally.
    
    The likelihood is small because we also reset fw_health->tmr_counter
    which will reset the interval for the next health check.  But the
    update is not protected and bnxt_timer() can miss the update and
    perform the health check without waiting for the full interval.
    
    Fix it by only reading the heartbeat register and reset counter in
    bnxt_async_event_process() if error recovery is trasitioning to the
    enabled state.  Also add proper memory barriers so that when enabling
    for the first time, bnxt_timer() will see the tmr_counter interval and
    perform the health check after the full interval has elapsed.
    
    Fixes: 7e914027f757 ("bnxt_en: Enable health monitoring.")
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a3f52f73c04dd8dddf9209fbf555f530b315ec3
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Feb 14 18:05:01 2021 -0500

    bnxt_en: Improve logging of error recovery settings information.
    
    [ Upstream commit f4d95c3c194de04ae7b44f850131321c7ceb9312 ]
    
    We currently only log the error recovery settings if it is enabled.
    In some cases, firmware disables error recovery after it was
    initially enabled.  Without logging anything, the user will not be
    aware of this change in setting.
    
    Log it when error recovery is disabled.  Also, change the reset count
    value from hexadecimal to decimal.
    
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 639a2eddb7310bf6e76377a2e5610184712204a3
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Tue Jan 26 01:20:24 2021 -0500

    bnxt_en: Convert to use netif_level() helpers.
    
    [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]
    
    Use the various netif_level() helpers to simplify the C code.  This was
    suggested by Joe Perches.
    
    Cc: Joe Perches <joe@perches.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/1611642024-3166-1-git-send-email-michael.chan@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01cad477a96834c16f76019698aac57c779893b4
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Mon Jan 25 02:08:20 2021 -0500

    bnxt_en: Consolidate firmware reset event logging.
    
    [ Upstream commit 5863b10aa86a5f5f69a25b55a5c15806c834471a ]
    
    Combine the three netdev_warn() calls into a single call, printed at
    the NETIF_MSG_HW log level.
    
    Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fad75e046363ebf37c42c04dc8e3f68e0ed4c130
Author: Edwin Peer <edwin.peer@broadcom.com>
Date:   Mon Jan 25 02:08:13 2021 -0500

    bnxt_en: log firmware debug notifications
    
    [ Upstream commit a44daa8fcbcf572545c4c1a7908b3fbb38388048 ]
    
    Firmware is capable of generating asynchronous debug notifications.
    The event data is opaque to the driver and is simply logged. Debug
    notifications can be enabled by turning on hardware status messages
    using the ethtool msglvl interface.
    
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f90a34fabaa5f6c62fb0dcf4990c10ad84678eff
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Sep 5 14:10:57 2021 -0400

    bnxt_en: Fix asic.rev in devlink dev info command
    
    [ Upstream commit 6fdab8a3ade2adc123bbf5c4fdec3394560b1fb1 ]
    
    The current asic.rev is incomplete and does not include the metal
    revision.  Add the metal revision and decode the complete asic
    revision into the more common and readable form (A0, B0, etc).
    
    Fixes: 7154917a12b2 ("bnxt_en: Refactor bnxt_dl_info_get().")
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72450231845518503833b8cc1892f44e59dd10e3
Author: Edwin Peer <edwin.peer@broadcom.com>
Date:   Sun Sep 5 14:10:55 2021 -0400

    bnxt_en: fix stored FW_PSID version masks
    
    [ Upstream commit 1656db67233e4259281d2ac35b25f712edbbc20b ]
    
    The FW_PSID version components are 8 bits wide, not 4.
    
    Fixes: db28b6c77f40 ("bnxt_en: Fix devlink info's stored fw.psid version format.")
    Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb635e008cb1d9845e19ac5910c82ff77e660306
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Sep 5 19:23:28 2021 +0200

    net: dsa: b53: Fix IMP port setup on BCM5301x
    
    [ Upstream commit 63f8428b4077de3664eb0b252393c839b0b293ec ]
    
    Broadcom's b53 switches have one IMP (Inband Management Port) that needs
    to be programmed using its own designed register. IMP port may be
    different than CPU port - especially on devices with multiple CPU ports.
    
    For that reason it's required to explicitly note IMP port index and
    check for it when choosing a register to use.
    
    This commit fixes BCM5301x support. Those switches use CPU port 5 while
    their IMP port is 8. Before this patch b53 was trying to program port 5
    with B53_PORT_OVERRIDE_CTRL instead of B53_GMII_PORT_OVERRIDE_CTRL(5).
    
    It may be possible to also replace "cpu_port" usages with
    dsa_is_cpu_port() but that is out of the scope of thix BCM5301x fix.
    
    Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87b34cd6485192777f632f92d592f2a71d8801a6
Author: Willem de Bruijn <willemb@google.com>
Date:   Sun Sep 5 11:21:09 2021 -0400

    ip_gre: validate csum_start only on pull
    
    [ Upstream commit 8a0ed250f911da31a2aef52101bc707846a800ff ]
    
    The GRE tunnel device can pull existing outer headers in ipge_xmit.
    This is a rare path, apparently unique to this device. The below
    commit ensured that pulling does not move skb->data beyond csum_start.
    
    But it has a false positive if ip_summed is not CHECKSUM_PARTIAL and
    thus csum_start is irrelevant.
    
    Refine to exclude this. At the same time simplify and strengthen the
    test.
    
    Simplify, by moving the check next to the offending pull, making it
    more self documenting and removing an unnecessary branch from other
    code paths.
    
    Strengthen, by also ensuring that the transport header is correct and
    therefore the inner headers will be after skb_reset_inner_headers.
    The transport header is set to csum_start in skb_partial_csum_set.
    
    Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/
    Fixes: 1d011c4803c7 ("ip_gre: add validation for csum_start")
    Reported-by: Ido Schimmel <idosch@idosch.org>
    Suggested-by: Alexander Duyck <alexander.duyck@gmail.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c98d2bd143420a26d3ba1b096326f28247a058d
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Fri Sep 3 15:35:43 2021 +0800

    qlcnic: Remove redundant unlock in qlcnic_pinit_from_rom
    
    [ Upstream commit 9ddbc2a00d7f63fa9748f4278643193dac985f2d ]
    
    Previous commit 68233c583ab4 removes the qlcnic_rom_lock()
    in qlcnic_pinit_from_rom(), but remains its corresponding
    unlock function, which is odd. I'm not very sure whether the
    lock is missing, or the unlock is redundant. This bug is
    suggested by a static analysis tool, please advise.
    
    Fixes: 68233c583ab4 ("qlcnic: updated reset sequence")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c01c620ae61142760d8924ee96a3ff8eec00aa6
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 3 15:03:43 2021 -0700

    fq_codel: reject silly quantum parameters
    
    [ Upstream commit c7c5e6ff533fe1f9afef7d2fa46678987a1335a7 ]
    
    syzbot found that forcing a big quantum attribute would crash hosts fast,
    essentially using this:
    
    tc qd replace dev eth0 root fq_codel quantum 4294967295
    
    This is because fq_codel_dequeue() would have to loop
    ~2^31 times in :
    
            if (flow->deficit <= 0) {
                    flow->deficit += q->quantum;
                    list_move_tail(&flow->flowchain, &q->old_flows);
                    goto begin;
            }
    
    SFQ max quantum is 2^19 (half a megabyte)
    Lets adopt a max quantum of one megabyte for FQ_CODEL.
    
    Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e2d36f2b1d19bee1096a53e6cbc9e0c0f0b05b4
Author: Benjamin Hesmans <benjamin.hesmans@tessares.net>
Date:   Fri Sep 3 15:23:35 2021 +0200

    netfilter: socket: icmp6: fix use-after-scope
    
    [ Upstream commit 730affed24bffcd1eebd5903171960f5ff9f1f22 ]
    
    Bug reported by KASAN:
    
    BUG: KASAN: use-after-scope in inet6_ehashfn (net/ipv6/inet6_hashtables.c:40)
    Call Trace:
    (...)
    inet6_ehashfn (net/ipv6/inet6_hashtables.c:40)
    (...)
    nf_sk_lookup_slow_v6 (net/ipv6/netfilter/nf_socket_ipv6.c:91
    net/ipv6/netfilter/nf_socket_ipv6.c:146)
    
    It seems that this bug has already been fixed by Eric Dumazet in the
    past in:
    commit 78296c97ca1f ("netfilter: xt_socket: fix a stack corruption bug")
    
    But a variant of the same issue has been introduced in
    commit d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match")
    
    `daddr` and `saddr` potentially hold a reference to ipv6_var that is no
    longer in scope when the call to `nf_socket_get_sock_v6` is made.
    
    Fixes: d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match")
    Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Benjamin Hesmans <benjamin.hesmans@tessares.net>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c361c955609a48d993f07caa93fdcc516de20849
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Sep 2 10:30:51 2021 +0200

    net: dsa: b53: Set correct number of ports in the DSA struct
    
    [ Upstream commit d12e1c4649883e8ca5e8ff341e1948b3b6313259 ]
    
    Setting DSA_MAX_PORTS caused DSA to call b53 callbacks (e.g.
    b53_disable_port() during dsa_register_switch()) for invalid
    (non-existent) ports. That made b53 modify unrelated registers and is
    one of reasons for a broken BCM5301x support.
    
    This problem exists for years but DSA_MAX_PORTS usage has changed few
    times. It seems the most accurate to reference commit dropping
    dsa_switch_alloc() in the Fixes tag.
    
    Fixes: 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0db7e0d9f67da8789d2aea12e0464e40359f9bd4
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Sep 2 10:30:50 2021 +0200

    net: dsa: b53: Fix calculating number of switch ports
    
    [ Upstream commit cdb067d31c0fe4cce98b9d15f1f2ef525acaa094 ]
    
    It isn't true that CPU port is always the last one. Switches BCM5301x
    have 9 ports (port 6 being inactive) and they use port 5 as CPU by
    default (depending on design some other may be CPU ports too).
    
    A more reliable way of determining number of ports is to check for the
    last set bit in the "enabled_ports" bitfield.
    
    This fixes b53 internal state, it will allow providing accurate info to
    the DSA and is required to fix BCM5301x support.
    
    Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f89b0d032f86df6174f4c542ccb0bcdc2630718d
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Thu Sep 2 16:36:09 2021 +0800

    net: hso: add failure handler for add_net_device
    
    [ Upstream commit ecdc28defc46af476566fffd9e5cb4495a2f176e ]
    
    If the network devices connected to the system beyond
    HSO_MAX_NET_DEVICES. add_net_device() in hso_create_net_device()
    will be failed for the network_table is full. It will lead to
    business failure which rely on network_table, for example,
    hso_suspend() and hso_resume(). It will also lead to memory leak
    because resource release process can not search the hso_device
    object from network_table in hso_free_interface().
    
    Add failure handler for add_net_device() in hso_create_net_device()
    to solve the above problems.
    
    Fixes: 72dc1c096c70 ("HSO: add option hso driver")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f450958f7ff8e99a3e511ae4732dbe67f54c5223
Author: Matthieu Baerts <matthieu.baerts@tessares.net>
Date:   Wed Sep 1 10:15:37 2021 -0700

    selftests: mptcp: clean tmp files in simult_flows
    
    [ Upstream commit bfd862a7e9318dd906844807a713d27cdd1a72b1 ]
    
    '$cin' and '$sin' variables are local to a function: they are then not
    available from the cleanup trap.
    
    Instead, we need to use '$large' and '$small' that are not local and
    defined just before setting the trap.
    
    Without this patch, running this script in a loop might cause a:
    
      write: No space left on device
    
    issue.
    
    Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests")
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5711ced58eb4ad37b3b71409294505abe572e26b
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Aug 31 20:50:50 2021 +0200

    net: dsa: tag_rtl4_a: Fix egress tags
    
    [ Upstream commit 0e90dfa7a8d817db755c7b5d89d77b9c485e4180 ]
    
    I noticed that only port 0 worked on the RTL8366RB since we
    started to use custom tags.
    
    It turns out that the format of egress custom tags is actually
    different from ingress custom tags. While the lower bits just
    contain the port number in ingress tags, egress tags need to
    indicate destination port by setting the bit for the
    corresponding port.
    
    It was working on port 0 because port 0 added 0x00 as port
    number in the lower bits, and if you do this the packet appears
    at all ports, including the intended port. Ooops.
    
    Fix this and all ports work again. Use the define for shifting
    the "type A" into place while we're at it.
    
    Tested on the D-Link DIR-685 by sending traffic to each of
    the ports in turn. It works.
    
    Fixes: 86dd9868b878 ("net: dsa: tag_rtl4_a: Support also egress tags")
    Cc: DENG Qingfang <dqfext@gmail.com>
    Cc: Mauri Sandberg <sandberg@mailfence.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b167a0cec18772a52c04445b1c46f62f737d10e3
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Aug 20 17:38:13 2021 +0200

    gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid a leak
    
    [ Upstream commit 889a1b3f35db6ba5ba6a0c23a3a55594570b6a17 ]
    
    If an error occurs after a 'gpiochip_add_data()' call it must be undone by
    a corresponding 'gpiochip_remove()' as already done in the remove function.
    
    To simplify the code a fix a leak in the error handling path of the probe,
    use the managed version instead (i.e. 'devm_gpiochip_add_data()')
    
    Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f86956143da9a32f5f7c5cef248563c65dbee47c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Aug 20 17:37:55 2021 +0200

    gpio: mpc8xxx: Fix a resources leak in the error handling path of 'mpc8xxx_probe()'
    
    [ Upstream commit 555bda42b0c1a5ffb72d3227c043e8afde778f1f ]
    
    Commit 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal")
    has introduced a new 'goto err;' at the very end of the function, but has
    not updated the error handling path accordingly.
    
    Add the now missing 'irq_domain_remove()' call which balances a previous
    'irq_domain_create_linear() call.
    
    Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2b52963fd0c2ceda4c75df66ff4a3129f148436
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Wed Aug 25 11:50:37 2021 -0300

    perf bench inject-buildid: Handle writen() errors
    
    [ Upstream commit edf7b4a2d85e37a1ee77156bddaed4aa6af9c5e1 ]
    
    The build on fedora:35 and fedora:rawhide with clang is failing with:
    
      49    41.00 fedora:35                     : FAIL clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35)
        bench/inject-buildid.c:351:6: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable]
                u64 len = 0;
                    ^
        1 error generated.
        make[3]: *** [/git/perf-5.14.0-rc7/tools/build/Makefile.build:139: bench] Error 2
      50    41.11 fedora:rawhide                : FAIL clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35)
        bench/inject-buildid.c:351:6: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable]
                u64 len = 0;
                    ^
        1 error generated.
        make[3]: *** [/git/perf-5.14.0-rc7/tools/build/Makefile.build:139: bench] Error 2
    
    That 'len' variable is not used at all, so just make sure all the
    synthesize_RECORD() routines return ssize_t to propagate the writen()
    return, as it may fail, ditch the 'ret' var and bail out if those
    routines fail.
    
    Fixes: 0bf02a0d80427f26 ("perf bench: Add build-id injection benchmark")
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/CAM9d7cgEZNSor+B+7Y2C+QYGme_v5aH0Zn0RLfxoQ+Fy83EHrg@mail.gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a20adc388114bdfe5f8c1fee39703f840a1ddbb
Author: Li Huafei <lihuafei1@huawei.com>
Date:   Mon Aug 23 21:43:40 2021 +0800

    perf unwind: Do not overwrite FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64}
    
    [ Upstream commit cdf32b44678c382a31dc183d9a767306915cda7b ]
    
    When setting LIBUNWIND_DIR, we first set
    
     FEATURE_CHECK_LDFLAGS-libunwind-{aarch64,x86} = -L$(LIBUNWIND_DIR)/lib.
    
    <committer note>
    This happens a bit before, the overwritting, in:
    
      libunwind_arch_set_flags = $(eval $(libunwind_arch_set_flags_code))
      define libunwind_arch_set_flags_code
        FEATURE_CHECK_CFLAGS-libunwind-$(1)  = -I$(LIBUNWIND_DIR)/include
        FEATURE_CHECK_LDFLAGS-libunwind-$(1) = -L$(LIBUNWIND_DIR)/lib
      endef
    
      ifdef LIBUNWIND_DIR
        LIBUNWIND_CFLAGS  = -I$(LIBUNWIND_DIR)/include
        LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib
        LIBUNWIND_ARCHS = x86 x86_64 arm aarch64 debug-frame-arm debug-frame-aarch64
        $(foreach libunwind_arch,$(LIBUNWIND_ARCHS),$(call libunwind_arch_set_flags,$(libunwind_arch)))
      endif
    
    Look at that 'foreach' on all the LIBUNWIND_ARCHS.
    </>
    
    After commit 5c4d7c82c0dc ("perf unwind: Do not put libunwind-{x86,aarch64}
    in FEATURE_TESTS_BASIC"), FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} is
    overwritten. As a result, the remote libunwind libraries cannot be searched
    from $(LIBUNWIND_DIR)/lib directory during feature check tests. Fix it with
    variable appending.
    
    Before this patch:
    
      perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64
       BUILD:   Doing 'make -j16' parallel build
      <SNIP>
      ...
      ...                    libopencsd: [ OFF ]
      ...                 libunwind-x86: [ OFF ]
      ...              libunwind-x86_64: [ OFF ]
      ...                 libunwind-arm: [ OFF ]
      ...             libunwind-aarch64: [ OFF ]
      ...         libunwind-debug-frame: [ OFF ]
      ...     libunwind-debug-frame-arm: [ OFF ]
      ... libunwind-debug-frame-aarch64: [ OFF ]
      ...                           cxx: [ OFF ]
      <SNIP>
    
      perf$ cat ../build/feature/test-libunwind-aarch64.make.output
      /usr/bin/ld: cannot find -lunwind-aarch64
      /usr/bin/ld: cannot find -lunwind-aarch64
      collect2: error: ld returned 1 exit status
    
    After this patch:
    
      perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64
       BUILD:   Doing 'make -j16' parallel build
      <SNIP>
      ...                    libopencsd: [ OFF ]
      ...                 libunwind-x86: [ OFF ]
      ...              libunwind-x86_64: [ OFF ]
      ...                 libunwind-arm: [ OFF ]
      ...             libunwind-aarch64: [ on  ]
      ...         libunwind-debug-frame: [ OFF ]
      ...     libunwind-debug-frame-arm: [ OFF ]
      ... libunwind-debug-frame-aarch64: [ OFF ]
      ...                           cxx: [ OFF ]
      <SNIP>
    
      perf$ cat ../build/feature/test-libunwind-aarch64.make.output
    
      perf$ ldd ./perf
            linux-vdso.so.1 (0x00007ffdf07da000)
            libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30953dc000)
            librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f30951d4000)
            libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3094e36000)
            libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3094c32000)
            libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f3094a18000)
            libdw.so.1 => /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f30947cc000)
            libunwind-x86_64.so.8 => /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8 (0x00007f30945ad000)
            libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f3094392000)
            liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f309416c000)
            libunwind-aarch64.so.8 => not found
            libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x00007f3093c8a000)
            libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00007f309386b000)
            libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f309364e000)
            libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f3093443000)
            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3093052000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f3096097000)
            libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3092e42000)
            libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3092c3f000)
    
    Fixes: 5c4d7c82c0dceccf ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC")
    Signed-off-by: Li Huafei <lihuafei1@huawei.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: He Kuang <hekuang@huawei.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Zhang Jinhao <zhangjinhao2@huawei.com>
    Link: http://lore.kernel.org/lkml/20210823134340.60955-1-lihuafei1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5176a0798bd286a1fb2061a28f136fe1fdb0cc2
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Aug 16 14:05:33 2021 -0700

    ARC: export clear_user_page() for modules
    
    [ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
    
    0day bot reports a build error:
      ERROR: modpost: "clear_user_page" [drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
    so export it in arch/arc/ to fix the build error.
    
    In most ARCHes, clear_user_page() is a macro. OTOH, in a few
    ARCHes it is a function and needs to be exported.
    PowerPC exported it in 2004. It looks like nds32 and nios2
    still need to have it exported.
    
    Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: linux-snps-arc@lists.infradead.org
    Signed-off-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9da1fb128c5492fb7204eabf32d2f80575beed23
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 21 09:58:45 2021 +0200

    mtd: rawnand: cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'
    
    [ Upstream commit 6b430c7595e4eb95fae8fb54adc3c3ce002e75ae ]
    
    A successful 'init_rs_non_canonical()' call should be balanced by a
    corresponding 'free_rs()' call in the error handling path of the probe, as
    already done in the remove function.
    
    Update the error handling path accordingly.
    
    Fixes: 8c61b7a7f4d4 ("[MTD] [NAND] Use rslib for CAFÉ ECC")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5402b31c0c46fde28bbbc7993ce0d2823847d80c
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Aug 13 18:36:19 2021 +0300

    PCI: Sync __pci_register_driver() stub for CONFIG_PCI=n
    
    [ Upstream commit 817f9916a6e96ae43acdd4e75459ef4f92d96eb1 ]
    
    The CONFIG_PCI=y case got a new parameter long time ago.  Sync the stub as
    well.
    
    [bhelgaas: add parameter names]
    Fixes: 725522b5453d ("PCI: add the sysfs driver name to all modules")
    Link: https://lore.kernel.org/r/20210813153619.89574-1-andriy.shevchenko@linux.intel.com
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a957d82b23161f175b124ef30b005a56e84e7ef2
Author: Oliver Upton <oupton@google.com>
Date:   Wed Aug 18 20:21:31 2021 +0000

    KVM: arm64: Handle PSCI resets before userspace touches vCPU state
    
    [ Upstream commit 6826c6849b46aaa91300201213701eb861af4ba0 ]
    
    The CPU_ON PSCI call takes a payload that KVM uses to configure a
    destination vCPU to run. This payload is non-architectural state and not
    exposed through any existing UAPI. Effectively, we have a race between
    CPU_ON and userspace saving/restoring a guest: if the target vCPU isn't
    ran again before the VMM saves its state, the requested PC and context
    ID are lost. When restored, the target vCPU will be runnable and start
    executing at its old PC.
    
    We can avoid this race by making sure the reset payload is serviced
    before userspace can access a vCPU's state.
    
    Fixes: 358b28f09f0a ("arm/arm64: KVM: Allow a VCPU to fully reset itself")
    Signed-off-by: Oliver Upton <oupton@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20210818202133.1106786-3-oupton@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53921242cf995a6c9867154696ba9f07b6bd7957
Author: Oliver Upton <oupton@google.com>
Date:   Wed Aug 18 20:21:30 2021 +0000

    KVM: arm64: Fix read-side race on updates to vcpu reset state
    
    [ Upstream commit 6654f9dfcb88fea3b9affc180dc3c04333d0f306 ]
    
    KVM correctly serializes writes to a vCPU's reset state, however since
    we do not take the KVM lock on the read side it is entirely possible to
    read state from two different reset requests.
    
    Cure the race for now by taking the KVM lock when reading the
    reset_state structure.
    
    Fixes: 358b28f09f0a ("arm/arm64: KVM: Allow a VCPU to fully reset itself")
    Signed-off-by: Oliver Upton <oupton@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20210818202133.1106786-2-oupton@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9b89da56af761fbb12da26ca5eb0c068446ec16
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue Aug 17 19:48:57 2021 +0800

    mtd: mtdconcat: Check _read, _write callbacks existence before assignment
    
    [ Upstream commit a89d69a44e282be95ae76125dddc79515541efeb ]
    
    Since 2431c4f5b46c3 ("mtd: Implement mtd_{read,write}() as wrappers
    around mtd_{read,write}_oob()") don't allow _write|_read and
    _write_oob|_read_oob existing at the same time, we should check the
    existence of callbacks "_read and _write" from subdev's master device
    (We can trust master device since it has been registered) before
    assigning, otherwise following warning occurs while making
    concatenated device:
    
      WARNING: CPU: 2 PID: 6728 at drivers/mtd/mtdcore.c:595
      add_mtd_device+0x7f/0x7b0
    
    Fixes: 2431c4f5b46c3 ("mtd: Implement mtd_{read,write}() around ...")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210817114857.2784825-3-chengzhihao1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 812cbb143c12596ad2f2cc289e73a5afe462675f
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue Aug 17 19:48:56 2021 +0800

    mtd: mtdconcat: Judge callback existence based on the master
    
    [ Upstream commit f9e109a209a8e01e16f37e1252304f1eb3908be4 ]
    
    Since commit 46b5889cc2c5("mtd: implement proper partition handling")
    applied, mtd partition device won't hold some callback functions, such
    as _block_isbad, _block_markbad, etc. Besides, function mtd_block_isbad()
    will get mtd device's master mtd device, then invokes master mtd device's
    callback function. So, following process may result mtd_block_isbad()
    always return 0, even though mtd device has bad blocks:
    
    1. Split a mtd device into 3 partitions: PA, PB, PC
    [ Each mtd partition device won't has callback function _block_isbad(). ]
    2. Concatenate PA and PB as a new mtd device PN
    [ mtd_concat_create() finds out each subdev has no callback function
    _block_isbad(), so PN won't be assigned callback function
    concat_block_isbad(). ]
    Then, mtd_block_isbad() checks "!master->_block_isbad" is true, will
    always return 0.
    
    Reproducer:
    // reproduce.c
    static int __init init_diy_module(void)
    {
            struct mtd_info *mtd[2];
            struct mtd_info *mtd_combine = NULL;
    
            mtd[0] = get_mtd_device_nm("NAND simulator partition 0");
            if (!mtd[0]) {
                    pr_err("cannot find mtd1\n");
                    return -EINVAL;
            }
            mtd[1] = get_mtd_device_nm("NAND simulator partition 1");
            if (!mtd[1]) {
                    pr_err("cannot find mtd2\n");
                    return -EINVAL;
            }
    
            put_mtd_device(mtd[0]);
            put_mtd_device(mtd[1]);
    
            mtd_combine = mtd_concat_create(mtd, 2, "Combine mtd");
            if (mtd_combine == NULL) {
                    pr_err("combine failed\n");
                    return -EINVAL;
            }
    
            mtd_device_register(mtd_combine, NULL, 0);
            pr_info("Combine success\n");
    
            return 0;
    }
    
    1. ID="0x20,0xac,0x00,0x15"
    2. modprobe nandsim id_bytes=$ID parts=50,100 badblocks=100
    3. insmod reproduce.ko
    4. flash_erase /dev/mtd3 0 0
      libmtd: error!: MEMERASE64 ioctl failed for eraseblock 100 (mtd3)
      error 5 (Input/output error)
      // Should be "flash_erase: Skipping bad block at 00c80000"
    
    Fixes: 46b5889cc2c54bac ("mtd: implement proper partition handling")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210817114857.2784825-2-chengzhihao1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8dfc446a16a81b5a12c87de7367d79ba3ff8b54
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Tue Aug 10 11:07:14 2021 +0900

    tracing/boot: Fix a hist trigger dependency for boot time tracing
    
    [ Upstream commit 6fe7c745f2acb73e4cc961d7f91125eef5a8861f ]
    
    Fixes a build error when CONFIG_HIST_TRIGGERS=n with boot-time
    tracing. Since the trigger_process_regex() is defined only
    when CONFIG_HIST_TRIGGERS=y, if it is disabled, the 'actions'
    event option also must be disabled.
    
    Link: https://lkml.kernel.org/r/162856123376.203126.582144262622247352.stgit@devnote2
    
    Fixes: 81a59555ff15 ("tracing/boot: Add per-event settings")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87479b10eb72f82aa45e8dc6a3dd9bfaec38f9d7
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Fri Jul 16 12:00:48 2021 +0200

    mfd: tqmx86: Clear GPIO IRQ resource when no IRQ is set
    
    [ Upstream commit a946506c48f3bd09363c9d2b0a178e55733bcbb6 ]
    
    The driver was registering IRQ 0 when no IRQ was set. This leads to
    warnings with newer kernels.
    
    Clear the resource flags, so no resource is registered at all in this
    case.
    
    Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO")
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f10f727cf9f452909be535a4e2db51baca7dff41
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 12 10:00:04 2021 +0300

    PCI: Fix pci_dev_str_match_path() alloc while atomic bug
    
    [ Upstream commit 7eb6ea4148579b85540a41d57bcec315b8af8ff8 ]
    
    pci_dev_str_match_path() is often called with a spinlock held so the
    allocation has to be atomic.  The call tree is:
    
      pci_specified_resource_alignment() <-- takes spin_lock();
        pci_dev_str_match()
          pci_dev_str_match_path()
    
    Fixes: 45db33709ccc ("PCI: Allow specifying devices using a base bus and path of devfns")
    Link: https://lore.kernel.org/r/20210812070004.GC31863@kili
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed44be1cbe5e1b3a032c5e20e4c4e6a6378c8bcd
Author: Anshuman Khandual <anshuman.khandual@arm.com>
Date:   Wed Aug 11 16:41:15 2021 +0530

    KVM: arm64: Restrict IPA size to maximum 48 bits on 4K and 16K page size
    
    [ Upstream commit 5e5df9571c319fb107d7a523cc96fcc99961ee70 ]
    
    Even though ID_AA64MMFR0.PARANGE reports 52 bit PA size support, it cannot
    be enabled as guest IPA size on 4K or 16K page size configurations. Hence
    kvm_ipa_limit must be restricted to 48 bits. This change achieves required
    IPA capping.
    
    Before the commit c9b69a0cf0b4 ("KVM: arm64: Don't constrain maximum IPA
    size based on host configuration"), the problem here would have been just
    latent via PHYS_MASK_SHIFT (which earlier in turn capped kvm_ipa_limit),
    which remains capped at 48 bits on 4K and 16K configs.
    
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: James Morse <james.morse@arm.com>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: kvmarm@lists.cs.columbia.edu
    Cc: linux-kernel@vger.kernel.org
    Fixes: c9b69a0cf0b4 ("KVM: arm64: Don't constrain maximum IPA size based on host configuration")
    Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/1628680275-16578-1-git-send-email-anshuman.khandual@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62f813769f50bb0010ab9a63c021d2af39d156e4
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Aug 10 15:59:20 2021 +0300

    netfilter: nft_ct: protect nft_ct_pcpu_template_refcnt with mutex
    
    [ Upstream commit e3245a7b7b34bd2e97f744fd79463add6e9d41f4 ]
    
    Syzbot hit use-after-free in nf_tables_dump_sets. The problem was in
    missing lock protection for nft_ct_pcpu_template_refcnt.
    
    Before commit f102d66b335a ("netfilter: nf_tables: use dedicated
    mutex to guard transactions") all transactions were serialized by global
    mutex, but then global mutex was changed to local per netnamespace
    commit_mutex.
    
    This change causes use-after-free bug, when 2 netnamespaces concurently
    changing nft_ct_pcpu_template_refcnt without proper locking. Fix it by
    adding nft_ct_pcpu_mutex and protect all nft_ct_pcpu_template_refcnt
    changes with it.
    
    Fixes: f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions")
    Reported-and-tested-by: syzbot+649e339fa6658ee623d3@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1cf43a1e5782167cff8afcc35074994517436269
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Mar 5 02:42:09 2021 -0600

    netfilter: Fix fall-through warnings for Clang
    
    [ Upstream commit c2168e6bd7ec50cedb69b3be1ba6146e28893c69 ]
    
    In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
    warnings by explicitly adding multiple break statements instead of just
    letting the code fall through to the next case.
    
    Link: https://github.com/KSPP/linux/issues/115
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e89c22d1c949d7123a2edd8abc8e18f24895e80
Author: Rob Herring <robh@kernel.org>
Date:   Tue Aug 3 15:56:56 2021 -0600

    PCI: iproc: Fix BCMA probe resource handling
    
    [ Upstream commit aeaea8969b402e0081210cc9144404d13996efed ]
    
    In commit 7ef1c871da16 ("PCI: iproc: Use
    pci_parse_request_of_pci_ranges()"), calling
    devm_request_pci_bus_resources() was dropped from the common iProc
    probe code, but is still needed for BCMA bus probing. Without it, there
    will be lots of warnings like this:
    
    pci 0000:00:00.0: BAR 8: no space for [mem size 0x00c00000]
    pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00c00000]
    
    Add back calling devm_request_pci_bus_resources() and adding the
    resources to pci_host_bridge.windows for BCMA bus probe.
    
    Link: https://lore.kernel.org/r/20210803215656.3803204-2-robh@kernel.org
    Fixes: 7ef1c871da16 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()")
    Reported-by: Rafał Miłecki <zajec5@gmail.com>
    Tested-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: Srinath Mannam <srinath.mannam@broadcom.com>
    Cc: Roman Bacik <roman.bacik@broadcom.com>
    Cc: Bharat Gooty <bharat.gooty@broadcom.com>
    Cc: Abhishek Shah <abhishek.shah@broadcom.com>
    Cc: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
    Cc: Ray Jui <ray.jui@broadcom.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>
    Cc: Scott Branden <sbranden@broadcom.com>
    Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: "Krzysztof Wilczyński" <kw@linux.com>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1f3be0c302a75ce2c712b9b5da930888426d686
Author: Rob Herring <robh@kernel.org>
Date:   Tue Aug 3 15:56:55 2021 -0600

    PCI: of: Don't fail devm_pci_alloc_host_bridge() on missing 'ranges'
    
    [ Upstream commit d277f6e88c88729b1d57d40bbfb00d0bfc961972 ]
    
    Commit 669cbc708122 ("PCI: Move DT resource setup into
    devm_pci_alloc_host_bridge()") made devm_pci_alloc_host_bridge() fail on
    any DT resource parsing errors, but Broadcom iProc uses
    devm_pci_alloc_host_bridge() on BCMA bus devices that don't have DT
    resources. In particular, there is no 'ranges' property. Fix iProc by
    making 'ranges' optional.
    
    If 'ranges' is required by a platform, there's going to be more errors
    latter on if it is missing.
    
    Link: https://lore.kernel.org/r/20210803215656.3803204-1-robh@kernel.org
    Fixes: 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()")
    Reported-by: Rafał Miłecki <zajec5@gmail.com>
    Tested-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Srinath Mannam <srinath.mannam@broadcom.com>
    Cc: Roman Bacik <roman.bacik@broadcom.com>
    Cc: Bharat Gooty <bharat.gooty@broadcom.com>
    Cc: Abhishek Shah <abhishek.shah@broadcom.com>
    Cc: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
    Cc: Ray Jui <ray.jui@broadcom.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>
    Cc: Scott Branden <sbranden@broadcom.com>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 063c3d980d78484996cfcfe299b5111b9dd6f03d
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu Jul 15 13:36:36 2021 +0200

    backlight: ktd253: Stabilize backlight
    
    [ Upstream commit daa37361518bf2d1f591bbdaa7c68b2a43d7af48 ]
    
    Remove interrupt disablement during backlight setting. It is
    way to dangerous and makes platforms instable by having it
    miss vblank IRQs leading to the graphics derailing.
    
    The code is using ndelay() which is not available on
    platforms such as ARM and will result in 32 * udelay(1)
    which is substantial.
    
    Add some code to detect if an interrupt occurs during the
    tight loop and in that case just redo it from the top.
    
    Fixes: 5317f37e48b9 ("backlight: Add Kinetic KTD253 backlight driver")
    Cc: Stephan Gerhold <stephan@gerhold.net>
    Reported-by: newbyte@disroot.org
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00303e459251c31d1206f261d598ab94ebd8cbaa
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Jun 29 19:12:39 2021 +0200

    mfd: axp20x: Update AXP288 volatile ranges
    
    [ Upstream commit f949a9ebce7a18005266b859a17f10c891bb13d7 ]
    
    On Cherry Trail devices with an AXP288 PMIC the external SD-card slot
    used the AXP's DLDO2 as card-voltage and either DLDO3 or GPIO1LDO
    (GPIO1 pin in low noise LDO mode) as signal-voltage.
    
    These regulators are turned on/off and in case of the signal-voltage
    also have their output-voltage changed by the _PS0 and _PS3 power-
    management ACPI methods on the MMC-controllers ACPI fwnode as well as
    by the _DSM ACPI method for changing the signal voltage.
    
    The AML code implementing these methods is directly accessing the
    PMIC through ACPI I2C OpRegion accesses, instead of using the special
    PMIC OpRegion handled by drivers/acpi/pmic/intel_pmic_xpower.c .
    
    This means that the contents of the involved PMIC registers can change
    without the change being made through the regmap interface, so regmap
    should not cache the contents of these registers.
    
    Mark the regulator power on/off, the regulator voltage control and the
    GPIO1 control registers as volatile, to avoid regmap caching them.
    
    Specifically this fixes an issue on some models where the i915 driver
    toggles another LDO using the same on/off register on/off through
    MIPI sequences (through intel_soc_pmic_exec_mipi_pmic_seq_element())
    which then writes back a cached on/off register-value where the
    card-voltage is off causing the external sdcard slot to stop working
    when the screen goes blank, or comes back on again.
    
    The regulator register-range now marked volatile also includes the
    buck regulator control registers. This is done on purpose these are
    normally not touched by the AML code, but they are updated directly
    by the SoC's PUNIT which means that they may also change without going
    through regmap.
    
    Note the AXP288 PMIC is only used on Bay- and Cherry-Trail platforms,
    so even though this is an ACPI specific problem there is no need to
    make the new volatile ranges conditional since these platforms always
    use ACPI.
    
    Fixes: dc91c3b6fe66 ("mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatile")
    Fixes: cd53216625a0 ("mfd: axp20x: Fix axp288 volatile ranges")
    Reported-and-tested-by: Clamshell <clamfly@163.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab7cf225016159bc2c3590be6fa12965565d903b
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Tue Sep 7 11:58:59 2021 +0200

    s390/bpf: Fix branch shortening during codegen pass
    
    commit 1511df6f5e9ef32826f20db2ee81f8527154dc14 upstream.
    
    EMIT6_PCREL() macro assumes that the previous pass generated 6 bytes
    of code, which is not the case if branch shortening took place. Fix by
    using jit->prg, like all the other EMIT6_PCREL_*() macros.
    
    Reported-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
    Fixes: 4e9b4a6883dd ("s390/bpf: Use relative long branches")
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4320c222c2ffe778a8aff5b8bc4ac33af6d54eba
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Tue Sep 7 13:41:16 2021 +0200

    s390/bpf: Fix 64-bit subtraction of the -0x80000000 constant
    
    commit 6e61dc9da0b7a0d91d57c2e20b5ea4fd2d4e7e53 upstream.
    
    The JIT uses agfi for subtracting constants, but -(-0x80000000) cannot
    be represented as a 32-bit signed binary integer. Fix by using algfi in
    this particular case.
    
    Reported-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
    Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d92d3a9c2b6541f29f800fc2bd44620578b8f8a6
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Mon Sep 6 15:04:14 2021 +0200

    s390/bpf: Fix optimizing out zero-extensions
    
    commit db7bee653859ef7179be933e7d1384644f795f26 upstream.
    
    Currently the JIT completely removes things like `reg32 += 0`,
    however, the BPF_ALU semantics requires the target register to be
    zero-extended in such cases.
    
    Fix by optimizing out only the arithmetic operation, but not the
    subsequent zero-extension.
    
    Reported-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
    Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a933932033854fc7be495ed966e47a42132a8c4
Author: Yang Li <yang.lee@linux.alibaba.com>
Date:   Mon Jun 7 16:40:36 2021 +0800

    NTB: perf: Fix an error code in perf_setup_inbuf()
    
    [ Upstream commit 0097ae5f7af5684f961a5f803ff7ad3e6f933668 ]
    
    When the function IS_ALIGNED() returns false, the value of ret is 0.
    So, we set ret to -EINVAL to indicate this error.
    
    Clean up smatch warning:
    drivers/ntb/test/ntb_perf.c:602 perf_setup_inbuf() warn: missing error
    code 'ret'.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce660d6dfcdd2836883673154835636438928929
Author: Yang Li <yang.lee@linux.alibaba.com>
Date:   Mon Jun 7 13:56:20 2021 +0800

    NTB: Fix an error code in ntb_msit_probe()
    
    [ Upstream commit 319f83ac98d7afaabab84ce5281a819a358b9895 ]
    
    When the value of nm->isr_ctx is false, the value of ret is 0.
    So, we set ret to -ENOMEM to indicate this error.
    
    Clean up smatch warning:
    drivers/ntb/test/ntb_msi_test.c:373 ntb_msit_probe() warn: missing
    error code 'ret'.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e76ccbdedbddaf14c65b50bbf2ffe8118958d15e
Author: Yang Li <yang.lee@linux.alibaba.com>
Date:   Fri Sep 3 14:42:33 2021 +0800

    ethtool: Fix an error code in cxgb2.c
    
    [ Upstream commit 7db8263a12155c7ae4ad97e850f1e499c73765fc ]
    
    When adapter->registered_device_map is NULL, the value of err is
    uncertain, we set err to -EINVAL to avoid ambiguity.
    
    Clean up smatch warning:
    drivers/net/ethernet/chelsio/cxgb/cxgb2.c:1114 init_one() warn: missing
    error code 'err'
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70ac967a7b886329f7308b966a690f9d4a94f958
Author: Vishal Aslot <os.vaslot@gmail.com>
Date:   Wed Aug 18 11:57:51 2021 -0500

    PCI: ibmphp: Fix double unmap of io_mem
    
    [ Upstream commit faa2e05ad0dccf37f995bcfbb8d1980d66c02c11 ]
    
    ebda_rsrc_controller() calls iounmap(io_mem) on the error path. Its caller,
    ibmphp_access_ebda(), also calls iounmap(io_mem) on good and error paths.
    
    Remove the iounmap(io_mem) invocation from ebda_rsrc_controller().
    
    [bhelgaas: remove item from TODO]
    Link: https://lore.kernel.org/r/20210818165751.591185-1-os.vaslot@gmail.com
    Signed-off-by: Vishal Aslot <os.vaslot@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ae759a36b6145df9c3cca198f8fcb198044ab34
Author: Paolo Valente <paolo.valente@linaro.org>
Date:   Mon Aug 2 16:13:52 2021 +0200

    block, bfq: honor already-setup queue merges
    
    [ Upstream commit 2d52c58b9c9bdae0ca3df6a1eab5745ab3f7d80b ]
    
    The function bfq_setup_merge prepares the merging between two
    bfq_queues, say bfqq and new_bfqq. To this goal, it assigns
    bfqq->new_bfqq = new_bfqq. Then, each time some I/O for bfqq arrives,
    the process that generated that I/O is disassociated from bfqq and
    associated with new_bfqq (merging is actually a redirection). In this
    respect, bfq_setup_merge increases new_bfqq->ref in advance, adding
    the number of processes that are expected to be associated with
    new_bfqq.
    
    Unfortunately, the stable-merging mechanism interferes with this
    setup. After bfqq->new_bfqq has been set by bfq_setup_merge, and
    before all the expected processes have been associated with
    bfqq->new_bfqq, bfqq may happen to be stably merged with a different
    queue than the current bfqq->new_bfqq. In this case, bfqq->new_bfqq
    gets changed. So, some of the processes that have been already
    accounted for in the ref counter of the previous new_bfqq will not be
    associated with that queue.  This creates an unbalance, because those
    references will never be decremented.
    
    This commit fixes this issue by reestablishing the previous, natural
    behaviour: once bfqq->new_bfqq has been set, it will not be changed
    until all expected redirections have occurred.
    
    Signed-off-by: Davide Zini <davidezini2@gmail.com>
    Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
    Link: https://lore.kernel.org/r/20210802141352.74353-2-paolo.valente@linaro.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f2b3242f0d4c276dc4caf966c0870159d6ef37c
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Thu Sep 2 12:51:22 2021 +0200

    net: usb: cdc_mbim: avoid altsetting toggling for Telit LN920
    
    [ Upstream commit aabbdc67f3485b5db27ab4eba01e5fbf1ffea62c ]
    
    Add quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE for Telit LN920
    0x1061 composition in order to avoid bind error.
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca8ecd7444a9f4295bc7bed1be908564bcc206f0
Author: Ryoga Saito <contact@proelbtn.com>
Date:   Thu Sep 2 05:20:14 2021 +0000

    Set fc_nlinfo in nh_create_ipv4, nh_create_ipv6
    
    [ Upstream commit 9aca491e0dccf8a9d84a5b478e5eee3c6ea7803b ]
    
    This patch fixes kernel NULL pointer dereference when creating nexthop
    which is bound with SRv6 decapsulation. In the creation of nexthop,
    __seg6_end_dt_vrf_build is called. __seg6_end_dt_vrf_build expects
    fc_lninfo in fib6_config is set correctly, but it isn't set in
    nh_create_ipv6, which causes kernel crash.
    
    Here is steps to reproduce kernel crash:
    
    1. modprobe vrf
    2. ip -6 nexthop add encap seg6local action End.DT4 vrftable 1 dev eth0
    
    We got the following message:
    
    [  901.370336] BUG: kernel NULL pointer dereference, address: 0000000000000ba0
    [  901.371658] #PF: supervisor read access in kernel mode
    [  901.372672] #PF: error_code(0x0000) - not-present page
    [  901.373672] PGD 0 P4D 0
    [  901.374248] Oops: 0000 [#1] SMP PTI
    [  901.374944] CPU: 0 PID: 8593 Comm: ip Not tainted 5.14-051400-generic #202108310811-Ubuntu
    [  901.376404] Hardware name: Red Hat KVM, BIOS 1.11.1-4.module_el8.2.0+320+13f867d7 04/01/2014
    [  901.377907] RIP: 0010:vrf_ifindex_lookup_by_table_id+0x19/0x90 [vrf]
    [  901.379182] Code: c1 e9 72 ff ff ff e8 96 49 01 c2 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 89 f5 41 54 53 8b 05 47 4c 00 00 <48> 8b 97 a0 0b 00 00 48 8b 1c c2 e8 57 27 53 c1 4c 8d a3 88 00 00
    [  901.382652] RSP: 0018:ffffbf2d02043590 EFLAGS: 00010282
    [  901.383746] RAX: 000000000000000b RBX: ffff990808255e70 RCX: ffffbf2d02043aa8
    [  901.385436] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000000
    [  901.386924] RBP: ffffbf2d020435b0 R08: 00000000000000c0 R09: ffff990808255e40
    [  901.388537] R10: ffffffff83b08c90 R11: 0000000000000009 R12: 0000000000000000
    [  901.389937] R13: 0000000000000001 R14: 0000000000000000 R15: 000000000000000b
    [  901.391226] FS:  00007fe49381f740(0000) GS:ffff99087dc00000(0000) knlGS:0000000000000000
    [  901.392737] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  901.393803] CR2: 0000000000000ba0 CR3: 000000000e3e8003 CR4: 0000000000770ef0
    [  901.395122] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  901.396496] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  901.397833] PKRU: 55555554
    [  901.398578] Call Trace:
    [  901.399144]  l3mdev_ifindex_lookup_by_table_id+0x3b/0x70
    [  901.400179]  __seg6_end_dt_vrf_build+0x34/0xd0
    [  901.401067]  seg6_end_dt4_build+0x16/0x20
    [  901.401904]  seg6_local_build_state+0x271/0x430
    [  901.402797]  lwtunnel_build_state+0x81/0x130
    [  901.403645]  fib_nh_common_init+0x82/0x100
    [  901.404465]  ? sock_def_readable+0x4b/0x80
    [  901.405285]  fib6_nh_init+0x115/0x7c0
    [  901.406033]  nh_create_ipv6.isra.0+0xe1/0x140
    [  901.406932]  rtm_new_nexthop+0x3b7/0xeb0
    [  901.407828]  rtnetlink_rcv_msg+0x152/0x3a0
    [  901.408663]  ? rtnl_calcit.isra.0+0x130/0x130
    [  901.409535]  netlink_rcv_skb+0x55/0x100
    [  901.410319]  rtnetlink_rcv+0x15/0x20
    [  901.411026]  netlink_unicast+0x1a8/0x250
    [  901.411813]  netlink_sendmsg+0x238/0x470
    [  901.412602]  ? _copy_from_user+0x2b/0x60
    [  901.413394]  sock_sendmsg+0x65/0x70
    [  901.414112]  ____sys_sendmsg+0x218/0x290
    [  901.414929]  ? copy_msghdr_from_user+0x5c/0x90
    [  901.415814]  ___sys_sendmsg+0x81/0xc0
    [  901.416559]  ? fsnotify_destroy_marks+0x27/0xf0
    [  901.417447]  ? call_rcu+0xa4/0x230
    [  901.418153]  ? kmem_cache_free+0x23f/0x410
    [  901.418972]  ? dentry_free+0x37/0x70
    [  901.419705]  ? mntput_no_expire+0x4c/0x260
    [  901.420574]  __sys_sendmsg+0x62/0xb0
    [  901.421297]  __x64_sys_sendmsg+0x1f/0x30
    [  901.422057]  do_syscall_64+0x5c/0xc0
    [  901.422756]  ? syscall_exit_to_user_mode+0x27/0x50
    [  901.423675]  ? __x64_sys_close+0x12/0x40
    [  901.424462]  ? do_syscall_64+0x69/0xc0
    [  901.425219]  ? irqentry_exit_to_user_mode+0x9/0x20
    [  901.426149]  ? irqentry_exit+0x19/0x30
    [  901.426901]  ? exc_page_fault+0x89/0x160
    [  901.427709]  ? asm_exc_page_fault+0x8/0x30
    [  901.428536]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [  901.429514] RIP: 0033:0x7fe493945747
    [  901.430248] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
    [  901.433549] RSP: 002b:00007ffe9932cf68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [  901.434981] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe493945747
    [  901.436303] RDX: 0000000000000000 RSI: 00007ffe9932cfe0 RDI: 0000000000000003
    [  901.437607] RBP: 00000000613053f7 R08: 0000000000000001 R09: 00007ffe9932d07c
    [  901.438990] R10: 000055f4a903a010 R11: 0000000000000246 R12: 0000000000000001
    [  901.440340] R13: 0000000000000001 R14: 000055f4a802b163 R15: 000055f4a8042020
    [  901.441630] Modules linked in: vrf nls_utf8 isofs nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua intel_rapl_msr intel_rapl_common isst_if_mbox_msr isst_if_common nfit rapl input_leds joydev serio_raw qemu_fw_cfg mac_hid sch_fq_codel drm virtio_rng ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd virtio_net net_failover cryptd psmouse virtio_blk failover i2c_piix4 pata_acpi floppy
    [  901.450808] CR2: 0000000000000ba0
    [  901.451514] ---[ end trace c27b934b99ade304 ]---
    [  901.452403] RIP: 0010:vrf_ifindex_lookup_by_table_id+0x19/0x90 [vrf]
    [  901.453626] Code: c1 e9 72 ff ff ff e8 96 49 01 c2 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 89 f5 41 54 53 8b 05 47 4c 00 00 <48> 8b 97 a0 0b 00 00 48 8b 1c c2 e8 57 27 53 c1 4c 8d a3 88 00 00
    [  901.456910] RSP: 0018:ffffbf2d02043590 EFLAGS: 00010282
    [  901.457912] RAX: 000000000000000b RBX: ffff990808255e70 RCX: ffffbf2d02043aa8
    [  901.459238] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000000
    [  901.460552] RBP: ffffbf2d020435b0 R08: 00000000000000c0 R09: ffff990808255e40
    [  901.461882] R10: ffffffff83b08c90 R11: 0000000000000009 R12: 0000000000000000
    [  901.463208] R13: 0000000000000001 R14: 0000000000000000 R15: 000000000000000b
    [  901.464529] FS:  00007fe49381f740(0000) GS:ffff99087dc00000(0000) knlGS:0000000000000000
    [  901.466058] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  901.467189] CR2: 0000000000000ba0 CR3: 000000000e3e8003 CR4: 0000000000770ef0
    [  901.468515] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  901.469858] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  901.471139] PKRU: 55555554
    
    Signed-off-by: Ryoga Saito <contact@proelbtn.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c422c555053e5adc192b0f08d16d26cb59e4f249
Author: Smadar Fuks <smadarf@marvell.com>
Date:   Wed Sep 1 11:08:59 2021 +0530

    octeontx2-af: Add additional register check to rvu_poll_reg()
    
    [ Upstream commit 21274aa1781941884599a97ab59be7f8f36af98c ]
    
    Check one more time before exiting the API with an error.
    Fix API to poll at least twice, in case there are other high priority
    tasks and this API doesn't get CPU cycles for multiple jiffies update.
    
    In addition, increase timeout from usecs_to_jiffies(10000) to
    usecs_to_jiffies(20000), to prevent the case that for CONFIG_100HZ
    timeout will be a single jiffies.
    A single jiffies results actual timeout that can be any time between
    1usec and 10msec. To solve this, a value of usecs_to_jiffies(20000)
    ensures that timeout is 2 jiffies.
    
    Signed-off-by: Smadar Fuks <smadarf@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 1cac475eeb9f5c46c1b5ddb4ca79f531ad15e1c8
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Sun Aug 1 09:56:25 2021 +0200

    watchdog: Start watchdog in watchdog_set_last_hw_keepalive only if appropriate
    
    [ Upstream commit dbe80cf471f940db3063197b7adb1169f89be9ed ]
    
    We must not pet a running watchdog when handle_boot_enabled is off
    because this will kick off automatic triggering before userland is
    running, defeating the purpose of the handle_boot_enabled control.
    Furthermore, don't ping in case watchdog_set_last_hw_keepalive was
    called incorrectly when the hardware watchdog is actually not running.
    
    Fixed: cef9572e9af3 ("watchdog: add support for adjusting last known HW keepalive time")
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/93d56386-6e37-060b-55ce-84de8cde535f@web.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5609d3fd57d4ab53db3bbe291fff2b525abbce1
Author: George Cherian <george.cherian@marvell.com>
Date:   Tue Aug 10 17:54:25 2021 +0530

    PCI: Add ACS quirks for Cavium multi-function devices
    
    [ Upstream commit 32837d8a8f63eb95dcb9cd005524a27f06478832 ]
    
    Some Cavium endpoints are implemented as multi-function devices without ACS
    capability, but they actually don't support peer-to-peer transactions.
    
    Add ACS quirks to declare DMA isolation for the following devices:
    
      - BGX device found on Octeon-TX (8xxx)
      - CGX device found on Octeon-TX2 (9xxx)
      - RPM device found on Octeon-TX3 (10xxx)
    
    Link: https://lore.kernel.org/r/20210810122425.1115156-1-george.cherian@marvell.com
    Signed-off-by: George Cherian <george.cherian@marvell.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 365cdfcc6eba04124f22dc74e4355d307bd4fe05
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Aug 11 18:03:35 2021 +0530

    PCI: j721e: Add PCIe support for AM64
    
    [ Upstream commit c8a375a8e15ac31293d7fda08008d6da8f5df3db ]
    
    AM64 has the same PCIe IP as in J7200 with certain erratas not
    applicable (quirk_detect_quiet_flag). Add support for "ti,am64-pcie-host"
    compatible and "ti,am64-pcie-ep" compatible that is specific to AM64.
    
    Link: https://lore.kernel.org/r/20210811123336.31357-5-kishon@ti.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81381b72f40ca6632402f5cc6dda789b1b6f6310
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Aug 11 18:03:34 2021 +0530

    PCI: j721e: Add PCIe support for J7200
    
    [ Upstream commit f1de58802f0fff364cf49f5e47d1be744baa434f ]
    
    J7200 has the same PCIe IP as in J721E with minor changes in the
    wrapper. J7200 allows byte access of bridge configuration space
    registers and the register field for LINK_DOWN interrupt is different.
    J7200 also requires "quirk_detect_quiet_flag" to be set. Configure these
    changes as part of driver data applicable only to J7200.
    
    Link: https://lore.kernel.org/r/20210811123336.31357-4-kishon@ti.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4892b1515b402b9279ad747f28b087bbdafc1412
Author: Nadeem Athani <nadeem@cadence.com>
Date:   Wed Aug 11 18:03:33 2021 +0530

    PCI: cadence: Add quirk flag to set minimum delay in LTSSM Detect.Quiet state
    
    [ Upstream commit 09c24094b2e3a15ef3fc44f54a191b3db522fb11 ]
    
    PCIe fails to link up if SERDES lanes not used by PCIe are assigned to
    another protocol. For example, link training fails if lanes 2 and 3 are
    assigned to another protocol while lanes 0 and 1 are used for PCIe to
    form a two lane link. This failure is due to an incorrect tie-off on an
    internal status signal indicating electrical idle.
    
    Status signals going from SERDES to PCIe Controller are tied-off when a
    lane is not assigned to PCIe. Signal indicating electrical idle is
    incorrectly tied-off to a state that indicates non-idle. As a result,
    PCIe sees unused lanes to be out of electrical idle and this causes
    LTSSM to exit Detect.Quiet state without waiting for 12ms timeout to
    occur. If a receiver is not detected on the first receiver detection
    attempt in Detect.Active state, LTSSM goes back to Detect.Quiet and
    again moves forward to Detect.Active state without waiting for 12ms as
    required by PCIe base specification. Since wait time in Detect.Quiet is
    skipped, multiple receiver detect operations are performed back-to-back
    without allowing time for capacitance on the transmit lines to
    discharge. This causes subsequent receiver detection to always fail even
    if a receiver gets connected eventually.
    
    Add a quirk flag "quirk_detect_quiet_flag" to program the minimum
    time the LTSSM should wait on entering Detect.Quiet state here.
    This has to be set for J7200 as it has an incorrect tie-off on unused
    lanes.
    
    Link: https://lore.kernel.org/r/20210811123336.31357-3-kishon@ti.com
    Signed-off-by: Nadeem Athani <nadeem@cadence.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a83e032cc48981a77c9fead708fc0f49ad842085
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Aug 11 18:03:32 2021 +0530

    PCI: cadence: Use bitfield for *quirk_retrain_flag* instead of bool
    
    [ Upstream commit f4455748b2126a9ba2bcc9cfb2fbcaa08de29bb2 ]
    
    No functional change. As we are intending to add additional 1-bit
    members in struct j721e_pcie_data/struct cdns_pcie_rc, use bitfields
    instead of bool since it takes less space. As discussed in [1],
    the preference is to use bitfileds instead of bool inside structures.
    
    [1] -> https://lore.kernel.org/linux-fsdevel/CA+55aFzKQ6Pj18TB8p4Yr0M4t+S+BsiHH=BJNmn=76-NcjTj-g@mail.gmail.com/
    
    Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://lore.kernel.org/r/20210811123336.31357-2-kishon@ti.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3aedfe4b080026157a36bf2be6495e158c7d0c62
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Aug 19 19:26:02 2021 +0900

    tracing/probes: Reject events which have the same name of existing one
    
    [ Upstream commit 8e242060c6a4947e8ae7d29794af6a581db08841 ]
    
    Since kprobe_events and uprobe_events only check whether the
    other same-type probe event has the same name or not, if the
    user gives the same name of the existing tracepoint event (or
    the other type of probe events), it silently fails to create
    the tracefs entry (but registered.) as below.
    
    /sys/kernel/tracing # ls events/task/task_rename
    enable   filter   format   hist     id       trigger
    /sys/kernel/tracing # echo p:task/task_rename vfs_read >> kprobe_events
    [  113.048508] Could not create tracefs 'task_rename' directory
    /sys/kernel/tracing # cat kprobe_events
    p:task/task_rename vfs_read
    
    To fix this issue, check whether the existing events have the
    same name or not in trace_probe_register_event_call(). If exists,
    it rejects to register the new event.
    
    Link: https://lkml.kernel.org/r/162936876189.187130.17558311387542061930.stgit@devnote2
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75420f9400a6792dc4b43e5a43ee0f105dd3f9ee
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Thu Apr 8 15:24:02 2021 +0800

    PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe()
    
    [ Upstream commit 1e29cd9983eba1b596bc07f94d81d728007f8a25 ]
    
    pm_runtime_get_sync() will increase the runtime PM counter
    even it returns an error. Thus a pairing decrement is needed
    to prevent refcount leak. Fix this by replacing this API with
    pm_runtime_resume_and_get(), which will not change the runtime
    PM counter on error.
    
    Link: https://lore.kernel.org/r/20210408072402.15069-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6352e2e276469ce756e5d698ea95855535e62a4
Author: Marc Zyngier <maz@kernel.org>
Date:   Sun Jul 25 19:07:54 2021 +0100

    mfd: Don't use irq_create_mapping() to resolve a mapping
    
    [ Upstream commit 9ff80e2de36d0554e3a6da18a171719fe8663c17 ]
    
    Although irq_create_mapping() is able to deal with duplicate
    mappings, it really isn't supposed to be a substitute for
    irq_find_mapping(), and can result in allocations that take place
    in atomic context if the mapping didn't exist.
    
    Fix the handful of MFD drivers that use irq_create_mapping() in
    interrupt context by using irq_find_mapping() instead.
    
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Lee Jones <lee.jones@linaro.org>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa638669c8a47f856eb4a096ca4f18d612f6cd95
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue May 4 19:17:42 2021 +0200

    PCI: tegra: Fix OF node reference leak
    
    [ Upstream commit eff21f5da308265678e7e59821795e606f3e560f ]
    
    Commit 9e38e690ace3 ("PCI: tegra: Fix OF node reference leak") has fixed
    some node reference leaks in this function but missed some of them.
    
    In fact, having 'port' referenced in the 'rp' structure is not enough to
    prevent the leak, until 'rp' is actually added in the 'pcie->ports' list.
    
    Add the missing 'goto err_node_put' accordingly.
    
    Link: https://lore.kernel.org/r/55b11e9a7fa2987fbc0869d68ae59888954d65e2.1620148539.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5c5d1b141faee0be01c93f48f2b714838004ef1
Author: Om Prakash Singh <omp@nvidia.com>
Date:   Wed Jun 23 15:35:22 2021 +0530

    PCI: tegra194: Fix MSI-X programming
    
    [ Upstream commit 43537cf7e351264a1f05ed42ad402942bfc9140e ]
    
    Lower order MSI-X address is programmed in MSIX_ADDR_MATCH_HIGH_OFF
    DBI register instead of higher order address. This patch fixes this
    programming mistake.
    
    Link: https://lore.kernel.org/r/20210623100525.19944-3-omp@nvidia.com
    Signed-off-by: Om Prakash Singh <omp@nvidia.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13f366bab07724d12c8ed73977870c0a9e964ad7
Author: Om Prakash Singh <omp@nvidia.com>
Date:   Wed Jun 23 15:35:21 2021 +0530

    PCI: tegra194: Fix handling BME_CHGED event
    
    [ Upstream commit ceb1412c1c8ca5b28c4252bdb15f2f1f17b4a1b0 ]
    
    In tegra_pcie_ep_hard_irq(), APPL_INTR_STATUS_L0 is stored in val and again
    APPL_INTR_STATUS_L1_0_0 is also stored in val. So when execution reaches
    "if (val & APPL_INTR_STATUS_L0_PCI_CMD_EN_INT)", val is not correct.
    
    Link: https://lore.kernel.org/r/20210623100525.19944-2-omp@nvidia.com
    Signed-off-by: Om Prakash Singh <omp@nvidia.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7d4f310bb8f605cff7c4c70014a9e2b866625c4
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Aug 4 13:22:58 2021 +0200

    fuse: fix use after free in fuse_read_interrupt()
    
    [ Upstream commit e1e71c168813564be0f6ea3d6740a059ca42d177 ]
    
    There is a potential race between fuse_read_interrupt() and
    fuse_request_end().
    
    TASK1
      in fuse_read_interrupt(): delete req->intr_entry (while holding
      fiq->lock)
    
    TASK2
      in fuse_request_end(): req->intr_entry is empty -> skip fiq->lock
      wake up TASK3
    
    TASK3
      request is freed
    
    TASK1
      in fuse_read_interrupt(): dereference req->in.h.unique ***BAM***
    
    Fix by always grabbing fiq->lock if the request was ever interrupted
    (FR_INTERRUPTED set) thereby serializing with concurrent
    fuse_read_interrupt() calls.
    
    FR_INTERRUPTED is set before the request is queued on fiq->interrupts.
    Dequeing the request is done with list_del_init() but FR_INTERRUPTED is not
    cleared in this case.
    
    Reported-by: lijiazi <lijiazi@xiaomi.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03cc3a2923d62f847d148f545c711f73f79617f0
Author: Wasim Khan <wasim.khan@nxp.com>
Date:   Thu Jul 29 14:17:47 2021 +0200

    PCI: Add ACS quirks for NXP LX2xx0 and LX2xx2 platforms
    
    [ Upstream commit d08c8b855140e9f5240b3ffd1b8b9d435675e281 ]
    
    Root Ports in NXP LX2xx0 and LX2xx2, where each Root Port is a Root Complex
    with unique segment numbers, do provide isolation features to disable peer
    transactions and validate bus numbers in requests, but do not provide an
    actual PCIe ACS capability.
    
    Add ACS quirks for NXP LX2xx0 A/C/E/N and LX2xx2 A/C/E/N platforms.
    
      LX2xx0A : without security features + CAN-FD
        LX2160A (0x8d81) - 16 cores
        LX2120A (0x8da1) - 12 cores
        LX2080A (0x8d83) -  8 cores
    
      LX2xx0C : security features + CAN-FD
        LX2160C (0x8d80) - 16 cores
        LX2120C (0x8da0) - 12 cores
        LX2080C (0x8d82) -  8 cores
    
      LX2xx0E : security features + CAN
        LX2160E (0x8d90) - 16 cores
        LX2120E (0x8db0) - 12 cores
        LX2080E (0x8d92) -  8 cores
    
      LX2xx0N : without security features + CAN
        LX2160N (0x8d91) - 16 cores
        LX2120N (0x8db1) - 12 cores
        LX2080N (0x8d93) -  8 cores
    
      LX2xx2A : without security features + CAN-FD
        LX2162A (0x8d89) - 16 cores
        LX2122A (0x8da9) - 12 cores
        LX2082A (0x8d8b) -  8 cores
    
      LX2xx2C : security features + CAN-FD
        LX2162C (0x8d88) - 16 cores
        LX2122C (0x8da8) - 12 cores
        LX2082C (0x8d8a) -  8 cores
    
      LX2xx2E : security features + CAN
        LX2162E (0x8d98) - 16 cores
        LX2122E (0x8db8) - 12 cores
        LX2082E (0x8d9a) -  8 cores
    
      LX2xx2N : without security features + CAN
        LX2162N (0x8d99) - 16 cores
        LX2122N (0x8db9) - 12 cores
        LX2082N (0x8d9b) -  8 cores
    
    [bhelgaas: put PCI_VENDOR_ID_NXP definition next to PCI_VENDOR_ID_FREESCALE
    as a clue that they share the same Device ID namespace]
    Link: https://lore.kernel.org/r/20210729121747.1823086-1-wasim.khan@oss.nxp.com
    Link: https://lore.kernel.org/r/20210803180021.3252886-1-wasim.khan@oss.nxp.com
    Signed-off-by: Wasim Khan <wasim.khan@nxp.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a44361a1f6ac2085e1fb64170a4342898b37f6b
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Mon Aug 2 01:33:13 2021 +0200

    mfd: db8500-prcmu: Adjust map to reality
    
    [ Upstream commit ec343111c056ec3847800302f6dbc57281f833fa ]
    
    These are the actual frequencies reported by the PLL, so let's
    report these. The roundoffs are inappropriate, we should round
    to the frequency that the clock will later report.
    
    Drop some whitespace at the same time.
    
    Cc: phone-devel@vger.kernel.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 619f137ffd691708fec72c785db497fb85b16cd5
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Thu Jun 10 16:39:45 2021 +0200

    dt-bindings: mtd: gpmc: Fix the ECC bytes vs. OOB bytes equation
    
    [ Upstream commit 778cb8e39f6ec252be50fc3850d66f3dcbd5dd5a ]
    
    "PAGESIZE / 512" is the number of ECC chunks.
    "ECC_BYTES" is the number of bytes needed to store a single ECC code.
    "2" is the space reserved by the bad block marker.
    
    "2 + (PAGESIZE / 512) * ECC_BYTES" should of course be lower or equal
    than the total number of OOB bytes, otherwise it won't fit.
    
    Fix the equation by substituting s/>=/<=/.
    
    Suggested-by: Ryan J. Barnett <ryan.barnett@collins.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/linux-mtd/20210610143945.3504781-1-miquel.raynal@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49cf30ebb35c50234144dd2a34fe7a6d50b966e2
Author: David Hildenbrand <david@redhat.com>
Date:   Tue Sep 7 19:54:59 2021 -0700

    mm/memory_hotplug: use "unsigned long" for PFN in zone_for_pfn_range()
    
    commit 7cf209ba8a86410939a24cb1aeb279479a7e0ca6 upstream.
    
    Patch series "mm/memory_hotplug: preparatory patches for new online policy and memory"
    
    These are all cleanups and one fix previously sent as part of [1]:
    [PATCH v1 00/12] mm/memory_hotplug: "auto-movable" online policy and memory
    groups.
    
    These patches make sense even without the other series, therefore I pulled
    them out to make the other series easier to digest.
    
    [1] https://lkml.kernel.org/r/20210607195430.48228-1-david@redhat.com
    
    This patch (of 4):
    
    Checkpatch complained on a follow-up patch that we are using "unsigned"
    here, which defaults to "unsigned int" and checkpatch is correct.
    
    As we will search for a fitting zone using the wrong pfn, we might end
    up onlining memory to one of the special kernel zones, such as ZONE_DMA,
    which can end badly as the onlined memory does not satisfy properties of
    these zones.
    
    Use "unsigned long" instead, just as we do in other places when handling
    PFNs.  This can bite us once we have physical addresses in the range of
    multiple TB.
    
    Link: https://lkml.kernel.org/r/20210712124052.26491-2-david@redhat.com
    Fixes: e5e689302633 ("mm, memory_hotplug: display allowed zones in the preferred ordering")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
    Reviewed-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
    Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Len Brown <lenb@kernel.org>
    Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: virtualization@lists.linux-foundation.org
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
    Cc: Anton Blanchard <anton@ozlabs.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Christophe Leroy <christophe.leroy@c-s.fr>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jia He <justin.he@arm.com>
    Cc: Joe Perches <joe@perches.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Laurent Dufour <ldufour@linux.ibm.com>
    Cc: Michel Lespinasse <michel@lespinasse.org>
    Cc: Nathan Lynch <nathanl@linux.ibm.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Pierre Morel <pmorel@linux.ibm.com>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Scott Cheloha <cheloha@linux.ibm.com>
    Cc: Sergei Trofimovich <slyfox@gentoo.org>
    Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa39eb744a82e35ca6dde7c2279a1b1c315cb357
Author: Jiaran Zhang <zhangjiaran@huawei.com>
Date:   Mon Sep 13 21:08:25 2021 +0800

    net: hns3: fix the timing issue of VF clearing interrupt sources
    
    commit 427900d27d86b820c559037a984bd403f910860f upstream.
    
    Currently, the VF does not clear the interrupt source immediately after
    receiving the interrupt. As a result, if the second interrupt task is
    triggered when processing the first interrupt task, clearing the
    interrupt source before exiting will clear the interrupt sources of the
    two tasks at the same time. As a result, no interrupt is triggered for
    the second task. The VF detects the missed message only when the next
    interrupt is generated.
    
    Clearing it immediately after executing check_evt_cause ensures that:
    1. Even if two interrupt tasks are triggered at the same time, they can
    be processed.
    2. If the second task is triggered during the processing of the first
    task and the interrupt source is not cleared, the interrupt is reported
    after vector0 is enabled.
    
    Fixes: b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")
    Signed-off-by: Jiaran Zhang <zhangjiaran@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad47e092210882ae1b5a2239ea59c4e8339cc980
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Mon Sep 13 21:08:23 2021 +0800

    net: hns3: disable mac in flr process
    
    commit b81d8948746520f989e86d66292ff72b5056114a upstream.
    
    The firmware will not disable mac in flr process. Therefore, the driver
    needs to proactively disable mac during flr, which is the same as the
    function reset.
    
    Fixes: 35d93a30040c ("net: hns3: adjust the process of PF reset")
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b76522c7c349ef35333c8d11e0bba720a5e03244
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Mon Sep 13 21:08:22 2021 +0800

    net: hns3: change affinity_mask to numa node range
    
    commit 1dc839ec09d3ab2a4156dc98328b8bc3586f2b70 upstream.
    
    Currently, affinity_mask is set to a single cpu. As a result,
    irqbalance becomes invalid in SUBSET or EXACT mode. To solve
    this problem, change affinity_mask to numa node range. In this
    way, irqbalance can be performed on the cpu of the numa node.
    
    Fixes: 0812545487ec ("net: hns3: add interrupt affinity support for misc interrupt")
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34fc06d0477e83088243702be08fa503b31e41c0
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Mon Sep 13 21:08:21 2021 +0800

    net: hns3: pad the short tunnel frame before sending to hardware
    
    commit d18e81183b1cb9c309266cbbce9acd3e0c528d04 upstream.
    
    The hardware cannot handle short tunnel frames below 65 bytes,
    and will cause vlan tag missing problem. So pads packet size to
    65 bytes for tunnel frames to fix this bug.
    
    Fixes: 3db084d28dc0("net: hns3: Fix for vxlan tx checksum bug")
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0511d099db6f92680dc4f780d27492211454a02a
Author: Edwin Peer <edwin.peer@broadcom.com>
Date:   Sun Sep 12 12:34:48 2021 -0400

    bnxt_en: make bnxt_free_skbs() safe to call after bnxt_free_mem()
    
    commit 1affc01fdc6035189a5ab2a24948c9419ee0ecf2 upstream.
    
    The call to bnxt_free_mem(..., false) in the bnxt_half_open_nic() error
    path will deallocate ring descriptor memory via bnxt_free_?x_rings(),
    but because irq_re_init is false, the ring info itself is not freed.
    
    To simplify error paths, deallocation functions have generally been
    written to be safe when called on unallocated memory. It should always
    be safe to call dev_close(), which calls bnxt_free_skbs() a second time,
    even in this semi- allocated ring state.
    
    Calling bnxt_free_skbs() a second time with the rings already freed will
    cause NULL pointer dereference.  Fix it by checking the rings are valid
    before proceeding in bnxt_free_tx_skbs() and
    bnxt_free_one_rx_ring_skbs().
    
    Fixes: 975bc99a4a39 ("bnxt_en: Refactor bnxt_free_rx_skbs().")
    Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49eff4ab7d43d625a5906b63c3bfcca9cfac56eb
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Wed Sep 8 20:17:18 2021 +1000

    KVM: PPC: Book3S HV: Tolerate treclaim. in fake-suspend mode changing registers
    
    commit 267cdfa21385d78c794768233678756e32b39ead upstream.
    
    POWER9 DD2.2 and 2.3 hardware implements a "fake-suspend" mode where
    certain TM instructions executed in HV=0 mode cause softpatch interrupts
    so the hypervisor can emulate them and prevent problematic processor
    conditions. In this fake-suspend mode, the treclaim. instruction does
    not modify registers.
    
    Unfortunately the rfscv instruction executed by the guest do not
    generate softpatch interrupts, which can cause the hypervisor to lose
    track of the fake-suspend mode, and it can execute this treclaim. while
    not in fake-suspend mode. This modifies GPRs and crashes the hypervisor.
    
    It's not trivial to disable scv in the guest with HFSCR now, because
    they assume a POWER9 has scv available. So this fix saves and restores
    checkpointed registers across the treclaim.
    
    Fixes: 7854f7545bff ("KVM: PPC: Book3S: Rework TM save/restore code and make it C-callable")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210908101718.118522-2-npiggin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e68795c1101ed6a1eb2954d40945708a459d14c3
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Wed Sep 8 09:58:20 2021 -0700

    ibmvnic: check failover_pending in login response
    
    commit 273c29e944bda9a20a30c26cfc34c9a3f363280b upstream.
    
    If a failover occurs before a login response is received, the login
    response buffer maybe undefined. Check that there was no failover
    before accessing the login response buffer.
    
    Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aeb67214ce94f23e76502d69231e334c17e422d7
Author: David Heidelberg <david@ixit.cz>
Date:   Sun Sep 12 18:51:20 2021 +0200

    dt-bindings: arm: Fix Toradex compatible typo
    
    commit 55c21d57eafb7b379bb7b3e93baf9ca2695895b0 upstream.
    
    Fix board compatible typo reported by dtbs_check.
    
    Fixes: f4d1577e9bc6 ("dt-bindings: arm: Convert Tegra board/soc bindings to json-schema")
    Signed-off-by: David Heidelberg <david@ixit.cz>
    Link: https://lore.kernel.org/r/20210912165120.188490-1-david@ixit.cz
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ab9981fa0c5f1ded9a70b44d9c003e549068e7a
Author: Aya Levin <ayal@nvidia.com>
Date:   Mon Sep 13 10:53:49 2021 +0300

    udp_tunnel: Fix udp_tunnel_nic work-queue type
    
    commit e50e711351bdc656a8e6ca1022b4293cae8dcd59 upstream.
    
    Turn udp_tunnel_nic work-queue to an ordered work-queue. This queue
    holds the UDP-tunnel configuration commands of the different netdevs.
    When the netdevs are functions of the same NIC the order of
    execution may be crucial.
    
    Problem example:
    NIC with 2 PFs, both PFs declare offload quota of up to 3 UDP-ports.
     $ifconfig eth2 1.1.1.1/16 up
    
     $ip link add eth2_19503 type vxlan id 5049 remote 1.1.1.2 dev eth2 dstport 19053
     $ip link set dev eth2_19503 up
    
     $ip link add eth2_19504 type vxlan id 5049 remote 1.1.1.3 dev eth2 dstport 19054
     $ip link set dev eth2_19504 up
    
     $ip link add eth2_19505 type vxlan id 5049 remote 1.1.1.4 dev eth2 dstport 19055
     $ip link set dev eth2_19505 up
    
     $ip link add eth2_19506 type vxlan id 5049 remote 1.1.1.5 dev eth2 dstport 19056
     $ip link set dev eth2_19506 up
    
    NIC RX port offload infrastructure offloads the first 3 UDP-ports (on
    all devices which sets NETIF_F_RX_UDP_TUNNEL_PORT feature) and not
    UDP-port 19056. So both PFs gets this offload configuration.
    
     $ip link set dev eth2_19504 down
    
    This triggers udp-tunnel-core to remove the UDP-port 19504 from
    offload-ports-list and offload UDP-port 19056 instead.
    
    In this scenario it is important that the UDP-port of 19504 will be
    removed from both PFs before trying to add UDP-port 19056. The NIC can
    stop offloading a UDP-port only when all references are removed.
    Otherwise the NIC may report exceeding of the offload quota.
    
    Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure")
    Signed-off-by: Aya Levin <ayal@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5221e66329910239df788f2cf49f4acc072f86d0
Author: Shai Malin <smalin@marvell.com>
Date:   Fri Sep 10 11:33:56 2021 +0300

    qed: Handle management FW error
    
    commit 20e100f52730cd0db609e559799c1712b5f27582 upstream.
    
    Handle MFW (management FW) error response in order to avoid a crash
    during recovery flows.
    
    Changes from v1:
    - Add "Fixes tag".
    
    Fixes: tag 5e7ba042fd05 ("qed: Fix reading stale configuration information")
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: Shai Malin <smalin@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00eae1d6b1fb8eecb1250fdcadcc97ea391cbe5
Author: Andrea Claudi <aclaudi@redhat.com>
Date:   Sat Sep 11 16:14:18 2021 +0200

    selftest: net: fix typo in altname test
    
    commit 1b704b27beb11ce147d64b21c914e57afbfb5656 upstream.
    
    If altname deletion of the short alternative name fails, the error
    message printed is: "Failed to add short alternative name".
    This is obviously a typo, as we are testing altname deletion.
    
    Fix this using a proper error message.
    
    Fixes: f95e6c9c4617 ("selftest: net: add alternative names test")
    Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53947b68c56bbdd2d8c8399b0d1a6ab154203577
Author: zhenggy <zhenggy@chinatelecom.cn>
Date:   Tue Sep 14 09:51:15 2021 +0800

    tcp: fix tp->undo_retrans accounting in tcp_sacktag_one()
    
    commit 4f884f3962767877d7aabbc1ec124d2c307a4257 upstream.
    
    Commit 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit
    time") may directly retrans a multiple segments TSO/GSO packet without
    split, Since this commit, we can no longer assume that a retransmitted
    packet is a single segment.
    
    This patch fixes the tp->undo_retrans accounting in tcp_sacktag_one()
    that use the actual segments(pcount) of the retransmitted packet.
    
    Before that commit (10d3be569243), the assumption underlying the
    tp->undo_retrans-- seems correct.
    
    Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time")
    Signed-off-by: zhenggy <zhenggy@chinatelecom.cn>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35d3ab2ea2ed594406db5cb063dd1f9daf940a83
Author: Will Deacon <will@kernel.org>
Date:   Mon Sep 13 17:35:47 2021 +0100

    x86/uaccess: Fix 32-bit __get_user_asm_u64() when CC_HAS_ASM_GOTO_OUTPUT=y
    
    commit a69ae291e1cc2d08ae77c2029579c59c9bde5061 upstream.
    
    Commit 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT")
    added an optimised version of __get_user_asm() for x86 using 'asm goto'.
    
    Like the non-optimised code, the 32-bit implementation of 64-bit
    get_user() expands to a pair of 32-bit accesses.  Unlike the
    non-optimised code, the _original_ pointer is incremented to copy the
    high word instead of loading through a new pointer explicitly
    constructed to point at a 32-bit type.  Consequently, if the pointer
    points at a 64-bit type then we end up loading the wrong data for the
    upper 32-bits.
    
    This was observed as a mount() failure in Android targeting i686 after
    b0cfcdd9b967 ("d_path: make 'prepend()' fill up the buffer exactly on
    overflow") because the call to copy_from_kernel_nofault() from
    prepend_copy() ends up in __get_kernel_nofault() and casts the source
    pointer to a 'u64 __user *'.  An attempt to mount at "/debug_ramdisk"
    therefore ends up failing trying to mount "/debumdismdisk".
    
    Use the existing '__gu_ptr' source pointer to unsigned int for 32-bit
    __get_user_asm_u64() instead of the original pointer.
    
    Cc: Bill Wendling <morbo@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Fixes: 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT")
    Signed-off-by: Will Deacon <will@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf6f29bb2c18be0aaa54d85b5d58f6a9759bcbf1
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Sep 14 16:43:31 2021 +0300

    net: dsa: destroy the phylink instance on any error in dsa_slave_phy_setup
    
    commit 6a52e73368038f47f6618623d75061dc263b26ae upstream.
    
    DSA supports connecting to a phy-handle, and has a fallback to a non-OF
    based method of connecting to an internal PHY on the switch's own MDIO
    bus, if no phy-handle and no fixed-link nodes were present.
    
    The -ENODEV error code from the first attempt (phylink_of_phy_connect)
    is what triggers the second attempt (phylink_connect_phy).
    
    However, when the first attempt returns a different error code than
    -ENODEV, this results in an unbalance of calls to phylink_create and
    phylink_destroy by the time we exit the function. The phylink instance
    has leaked.
    
    There are many other error codes that can be returned by
    phylink_of_phy_connect. For example, phylink_validate returns -EINVAL.
    So this is a practical issue too.
    
    Fixes: aab9c4067d23 ("net: dsa: Plug in PHYLINK support")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://lore.kernel.org/r/20210914134331.2303380-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df38f941a7e4c966919741b86df5e877a1f69e9a
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 8 17:00:29 2021 -0700

    net/af_unix: fix a data-race in unix_dgram_poll
    
    commit 04f08eb44b5011493d77b602fdec29ff0f5c6cd5 upstream.
    
    syzbot reported another data-race in af_unix [1]
    
    Lets change __skb_insert() to use WRITE_ONCE() when changing
    skb head qlen.
    
    Also, change unix_dgram_poll() to use lockless version
    of unix_recvq_full()
    
    It is verry possible we can switch all/most unix_recvq_full()
    to the lockless version, this will be done in a future kernel version.
    
    [1] HEAD commit: 8596e589b787732c8346f0482919e83cc9362db1
    
    BUG: KCSAN: data-race in skb_queue_tail / unix_dgram_poll
    
    write to 0xffff88814eeb24e0 of 4 bytes by task 25815 on cpu 0:
     __skb_insert include/linux/skbuff.h:1938 [inline]
     __skb_queue_before include/linux/skbuff.h:2043 [inline]
     __skb_queue_tail include/linux/skbuff.h:2076 [inline]
     skb_queue_tail+0x80/0xa0 net/core/skbuff.c:3264
     unix_dgram_sendmsg+0xff2/0x1600 net/unix/af_unix.c:1850
     sock_sendmsg_nosec net/socket.c:703 [inline]
     sock_sendmsg net/socket.c:723 [inline]
     ____sys_sendmsg+0x360/0x4d0 net/socket.c:2392
     ___sys_sendmsg net/socket.c:2446 [inline]
     __sys_sendmmsg+0x315/0x4b0 net/socket.c:2532
     __do_sys_sendmmsg net/socket.c:2561 [inline]
     __se_sys_sendmmsg net/socket.c:2558 [inline]
     __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2558
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff88814eeb24e0 of 4 bytes by task 25834 on cpu 1:
     skb_queue_len include/linux/skbuff.h:1869 [inline]
     unix_recvq_full net/unix/af_unix.c:194 [inline]
     unix_dgram_poll+0x2bc/0x3e0 net/unix/af_unix.c:2777
     sock_poll+0x23e/0x260 net/socket.c:1288
     vfs_poll include/linux/poll.h:90 [inline]
     ep_item_poll fs/eventpoll.c:846 [inline]
     ep_send_events fs/eventpoll.c:1683 [inline]
     ep_poll fs/eventpoll.c:1798 [inline]
     do_epoll_wait+0x6ad/0xf00 fs/eventpoll.c:2226
     __do_sys_epoll_wait fs/eventpoll.c:2238 [inline]
     __se_sys_epoll_wait fs/eventpoll.c:2233 [inline]
     __x64_sys_epoll_wait+0xf6/0x120 fs/eventpoll.c:2233
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x0000001b -> 0x00000001
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 25834 Comm: syz-executor.1 Tainted: G        W         5.14.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 86b18aaa2b5b ("skbuff: fix a data race in skb_queue_len()")
    Cc: Qian Cai <cai@lca.pw>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cad96d0e50e4149758d43bcc3bd13f6381312362
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Sep 8 13:42:09 2021 +0200

    vhost_net: fix OoB on sendmsg() failure.
    
    commit 3c4cea8fa7f71f00c5279547043a84bc2a4d8b8c upstream.
    
    If the sendmsg() call in vhost_tx_batch() fails, both the 'batched_xdp'
    and 'done_idx' indexes are left unchanged. If such failure happens
    when batched_xdp == VHOST_NET_BATCH, the next call to
    vhost_net_build_xdp() will access and write memory outside the xdp
    buffers area.
    
    Since sendmsg() can only error with EBADFD, this change addresses the
    issue explicitly freeing the XDP buffers batch on error.
    
    Fixes: 0a0be13b8fe2 ("vhost_net: batch submitting XDP buffers to underlayer sockets")
    Suggested-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7843861e214026bd867d19e832de10d16a52e757
Author: Kortan <kortanzh@gmail.com>
Date:   Wed Sep 8 11:28:48 2021 +0800

    gen_compile_commands: fix missing 'sys' package
    
    commit ec783c7cb2495c5a3b8ca10db8056d43c528f940 upstream.
    
    We need to import the 'sys' package since the script has called
    sys.exit() method.
    
    Fixes: 6ad7cbc01527 ("Makefile: Add clang-tidy and static analyzer support to makefile")
    Signed-off-by: Kortan <kortanzh@gmail.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 983ef866291cc7e51f151cdea5a7c2fe36f632a3
Author: Alex Elder <elder@linaro.org>
Date:   Tue Sep 7 12:05:54 2021 -0500

    net: ipa: initialize all filter table slots
    
    commit b5c102238cea985d8126b173d06b9e1de88037ee upstream.
    
    There is an off-by-one problem in ipa_table_init_add(), when
    initializing filter tables.
    
    In that function, the number of filter table entries is determined
    based on the number of set bits in the filter map.  However that
    count does *not* include the extra "slot" in the filter table that
    holds the filter map itself.  Meanwhile, ipa_table_addr() *does*
    include the filter map in the memory it returns, but because the
    count it's provided doesn't include it, it includes one too few
    table entries.
    
    Fix this by including the extra slot for the filter map in the count
    computed in ipa_table_init_add().
    
    Note: ipa_filter_reset_table() does not have this problem; it resets
    filter table entries one by one, but does not overwrite the filter
    bitmap.
    
    Fixes: 2b9feef2b6c2 ("soc: qcom: ipa: filter and routing tables")
    Signed-off-by: Alex Elder <elder@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5102ced8ac0a106182332de15ea2b2920581811
Author: Baptiste Lepers <baptiste.lepers@gmail.com>
Date:   Mon Sep 6 11:53:10 2021 +1000

    events: Reuse value read using READ_ONCE instead of re-reading it
    
    commit b89a05b21f46150ac10a962aa50109250b56b03b upstream.
    
    In perf_event_addr_filters_apply, the task associated with
    the event (event->ctx->task) is read using READ_ONCE at the beginning
    of the function, checked, and then re-read from event->ctx->task,
    voiding all guarantees of the checks. Reuse the value that was read by
    READ_ONCE to ensure the consistency of the task struct throughout the
    function.
    
    Fixes: 375637bc52495 ("perf/core: Introduce address range filtering")
    Signed-off-by: Baptiste Lepers <baptiste.lepers@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20210906015310.12802-1-baptiste.lepers@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f8ad122ffe01efb7c14b34f9c33b8b16e02fec5
Author: Keith Busch <kbusch@kernel.org>
Date:   Thu Sep 9 08:54:52 2021 -0700

    nvme-tcp: fix io_work priority inversion
    
    commit 70f437fb4395ad4d1d16fab9a1ad9fbc9fc0579b upstream.
    
    Dispatching requests inline with the .queue_rq() call may block while
    holding the send_mutex. If the tcp io_work also happens to schedule, it
    may see the req_list is non-empty, leaving "pending" true and remaining
    in TASK_RUNNING. Since io_work is of higher scheduling priority, the
    .queue_rq task may not get a chance to run, blocking forward progress
    and leading to io timeouts.
    
    Instead of checking for pending requests within io_work, let the queueing
    restart io_work outside the send_mutex lock if there is more work to be
    done.
    
    Fixes: a0fdd1418007f ("nvme-tcp: rerun io_work if req_list is not empty")
    Reported-by: Samuel Jones <sjones@kalrayinc.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c586bc31d5b9ae7ed202fc0dcaffbaaed77bde06
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Wed Sep 1 11:48:13 2021 +0300

    net/mlx5: Fix potential sleeping in atomic context
    
    commit ee27e330a953595903979ffdb84926843595a9fe upstream.
    
    Fixes the below flow of sleeping in atomic context by releasing
    the RCU lock before calling to free_match_list.
    
    build_match_list() <- disables preempt
    -> free_match_list()
       -> tree_put_node()
          -> down_write_ref_node() <- take write lock
    
    Fixes: 693c6883bbc4 ("net/mlx5: Add hash table for flow groups in flow table")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29a5af9112a279398c0716bd8d932c94c6a03b16
Author: Saeed Mahameed <saeedm@nvidia.com>
Date:   Wed Aug 18 13:09:26 2021 -0700

    net/mlx5: FWTrace, cancel work on alloc pd error flow
    
    commit dfe6fd72b5f1878b16aa2c8603e031bbcd66b96d upstream.
    
    Handle error flow on mlx5_core_alloc_pd() failure,
    read_fw_strings_work must be canceled.
    
    Fixes: c71ad41ccb0c ("net/mlx5: FW tracer, events handling")
    Reported-by: Pavel Machek (CIP) <pavel@denx.de>
    Suggested-by: Pavel Machek (CIP) <pavel@denx.de>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Aya Levin <ayal@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 229e9293b2bada323485dd2168c03b7d69328014
Author: Michael Petlan <mpetlan@redhat.com>
Date:   Mon Jul 19 16:53:32 2021 +0200

    perf machine: Initialize srcline string member in add_location struct
    
    commit 57f0ff059e3daa4e70a811cb1d31a49968262d20 upstream.
    
    It's later supposed to be either a correct address or NULL. Without the
    initialization, it may contain an undefined value which results in the
    following segmentation fault:
    
      # perf top --sort comm -g --ignore-callees=do_idle
    
    terminates with:
    
      #0  0x00007ffff56b7685 in __strlen_avx2 () from /lib64/libc.so.6
      #1  0x00007ffff55e3802 in strdup () from /lib64/libc.so.6
      #2  0x00005555558cb139 in hist_entry__init (callchain_size=<optimized out>, sample_self=true, template=0x7fffde7fb110, he=0x7fffd801c250) at util/hist.c:489
      #3  hist_entry__new (template=template@entry=0x7fffde7fb110, sample_self=sample_self@entry=true) at util/hist.c:564
      #4  0x00005555558cb4ba in hists__findnew_entry (hists=hists@entry=0x5555561d9e38, entry=entry@entry=0x7fffde7fb110, al=al@entry=0x7fffde7fb420,
          sample_self=sample_self@entry=true) at util/hist.c:657
      #5  0x00005555558cba1b in __hists__add_entry (hists=hists@entry=0x5555561d9e38, al=0x7fffde7fb420, sym_parent=<optimized out>, bi=bi@entry=0x0, mi=mi@entry=0x0,
          sample=sample@entry=0x7fffde7fb4b0, sample_self=true, ops=0x0, block_info=0x0) at util/hist.c:288
      #6  0x00005555558cbb70 in hists__add_entry (sample_self=true, sample=0x7fffde7fb4b0, mi=0x0, bi=0x0, sym_parent=<optimized out>, al=<optimized out>, hists=0x5555561d9e38)
          at util/hist.c:1056
      #7  iter_add_single_cumulative_entry (iter=0x7fffde7fb460, al=<optimized out>) at util/hist.c:1056
      #8  0x00005555558cc8a4 in hist_entry_iter__add (iter=iter@entry=0x7fffde7fb460, al=al@entry=0x7fffde7fb420, max_stack_depth=<optimized out>, arg=arg@entry=0x7fffffff7db0)
          at util/hist.c:1231
      #9  0x00005555557cdc9a in perf_event__process_sample (machine=<optimized out>, sample=0x7fffde7fb4b0, evsel=<optimized out>, event=<optimized out>, tool=0x7fffffff7db0)
          at builtin-top.c:842
      #10 deliver_event (qe=<optimized out>, qevent=<optimized out>) at builtin-top.c:1202
      #11 0x00005555558a9318 in do_flush (show_progress=false, oe=0x7fffffff80e0) at util/ordered-events.c:244
      #12 __ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP, timestamp=timestamp@entry=0) at util/ordered-events.c:323
      #13 0x00005555558a9789 in __ordered_events__flush (timestamp=<optimized out>, how=<optimized out>, oe=<optimized out>) at util/ordered-events.c:339
      #14 ordered_events__flush (how=OE_FLUSH__TOP, oe=0x7fffffff80e0) at util/ordered-events.c:341
      #15 ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP) at util/ordered-events.c:339
      #16 0x00005555557cd631 in process_thread (arg=0x7fffffff7db0) at builtin-top.c:1114
      #17 0x00007ffff7bb817a in start_thread () from /lib64/libpthread.so.0
      #18 0x00007ffff5656dc3 in clone () from /lib64/libc.so.6
    
    If you look at the frame #2, the code is:
    
    488      if (he->srcline) {
    489          he->srcline = strdup(he->srcline);
    490          if (he->srcline == NULL)
    491              goto err_rawdata;
    492      }
    
    If he->srcline is not NULL (it is not NULL if it is uninitialized rubbish),
    it gets strdupped and strdupping a rubbish random string causes the problem.
    
    Also, if you look at the commit 1fb7d06a509e, it adds the srcline property
    into the struct, but not initializing it everywhere needed.
    
    Committer notes:
    
    Now I see, when using --ignore-callees=do_idle we end up here at line
    2189 in add_callchain_ip():
    
    2181         if (al.sym != NULL) {
    2182                 if (perf_hpp_list.parent && !*parent &&
    2183                     symbol__match_regex(al.sym, &parent_regex))
    2184                         *parent = al.sym;
    2185                 else if (have_ignore_callees && root_al &&
    2186                   symbol__match_regex(al.sym, &ignore_callees_regex)) {
    2187                         /* Treat this symbol as the root,
    2188                            forgetting its callees. */
    2189                         *root_al = al;
    2190                         callchain_cursor_reset(cursor);
    2191                 }
    2192         }
    
    And the al that doesn't have the ->srcline field initialized will be
    copied to the root_al, so then, back to:
    
    1211 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location *al,
    1212                          int max_stack_depth, void *arg)
    1213 {
    1214         int err, err2;
    1215         struct map *alm = NULL;
    1216
    1217         if (al)
    1218                 alm = map__get(al->map);
    1219
    1220         err = sample__resolve_callchain(iter->sample, &callchain_cursor, &iter->parent,
    1221                                         iter->evsel, al, max_stack_depth);
    1222         if (err) {
    1223                 map__put(alm);
    1224                 return err;
    1225         }
    1226
    1227         err = iter->ops->prepare_entry(iter, al);
    1228         if (err)
    1229                 goto out;
    1230
    1231         err = iter->ops->add_single_entry(iter, al);
    1232         if (err)
    1233                 goto out;
    1234
    
    That al at line 1221 is what hist_entry_iter__add() (called from
    sample__resolve_callchain()) saw as 'root_al', and then:
    
            iter->ops->add_single_entry(iter, al);
    
    will go on with al->srcline with a bogus value, I'll add the above
    sequence to the cset and apply, thanks!
    
    Signed-off-by: Michael Petlan <mpetlan@redhat.com>
    CC: Milian Wolff <milian.wolff@kdab.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Fixes: 1fb7d06a509e ("perf report Use srcline from callchain for hist entries")
    Link: https //lore.kernel.org/r/20210719145332.29747-1-mpetlan@redhat.com
    Reported-by: Juri Lelli <jlelli@redhat.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33c983f7a1821a839fde706ded2fafa18cafeff1
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Apr 28 23:31:24 2020 +0200

    drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unused
    
    commit 040b8907ccf1c78d020aca29800036565d761d73 upstream.
    
    With the new static annotation, the compiler warns when the functions
    are actually unused:
    
       drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' defined but not used [-Werror=unused-function]
        1123 | static int cdn_dp_resume(struct device *dev)
             |            ^~~~~~~~~~~~~
    
    Mark them __maybe_unused to suppress that warning as well.
    
    [ Not so 'new' static annotations any more, and I removed the part of
      the patch that added __maybe_unused to cdn_dp_suspend(), because it's
      used by the shutdown/remove code.
    
      So only the resume function ends up possibly unused if CONFIG_PM isn't
      set     - Linus ]
    
    Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd9ed47fe6be437bccab7afb396a270b6c79e499
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Mon Sep 13 16:28:52 2021 +0700

    tipc: increase timeout in tipc_sk_enqueue()
    
    commit f4bb62e64c88c93060c051195d3bbba804e56945 upstream.
    
    In tipc_sk_enqueue() we use hardcoded 2 jiffies to extract
    socket buffer from generic queue to particular socket.
    The 2 jiffies is too short in case there are other high priority
    tasks get CPU cycles for multiple jiffies update. As result, no
    buffer could be enqueued to particular socket.
    
    To solve this, we switch to use constant timeout 20msecs.
    Then, the function will be expired between 2 jiffies (CONFIG_100HZ)
    and 20 jiffies (CONFIG_1000HZ).
    
    Fixes: c637c1035534 ("tipc: resolve race problem at unicast message reception")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abe460eb6fbb7720010e82cf1e386ace87cec422
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Sep 9 10:33:28 2021 -0700

    r6040: Restore MDIO clock frequency after MAC reset
    
    commit e3f0cc1a945fcefec0c7c9d9dfd028a51daa1846 upstream.
    
    A number of users have reported that they were not able to get the PHY
    to successfully link up, especially after commit c36757eb9dee ("net:
    phy: consider AN_RESTART status when reading link status") where we
    stopped reading just BMSR, but we also read BMCR to determine the link
    status.
    
    Andrius at NetBSD did a wonderful job at debugging the problem
    and found out that the MDIO bus clock frequency would be incorrectly set
    back to its default value which would prevent the MDIO bus controller
    from reading PHY registers properly. Back when we only read BMSR, if we
    read all 1s, we could falsely indicate a link status, though in general
    there is a cable plugged in, so this went unnoticed. After a second read
    of BMCR was added, a wrong read will lead to the inability to determine
    a link UP condition which is when it started to be visibly broken, even
    if it was long before that.
    
    The fix consists in restoring the value of the MD_CSR register that was
    set prior to the MAC reset.
    
    Link: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53494
    Fixes: 90f750a81a29 ("r6040: consolidate MAC reset to its own function")
    Reported-by: Andrius V <vezhlys@gmail.com>
    Reported-by: Darek Strugacz <darek.strugacz@op.pl>
    Tested-by: Darek Strugacz <darek.strugacz@op.pl>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edfab735d5182fbfe5b5773869304291aaa12be8
Author: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Date:   Thu Sep 9 12:32:00 2021 +0800

    net/l2tp: Fix reference count leak in l2tp_udp_recv_core
    
    commit 9b6ff7eb666415e1558f1ba8a742f5db6a9954de upstream.
    
    The reference count leak issue may take place in an error handling
    path. If both conditions of tunnel->version == L2TP_HDR_VER_3 and the
    return value of l2tp_v3_ensure_opt_in_linear is nonzero, the function
    would directly jump to label invalid, without decrementing the reference
    count of the l2tp_session object session increased earlier by
    l2tp_tunnel_get_session(). This may result in refcount leaks.
    
    Fix this issue by decrease the reference count before jumping to the
    label invalid.
    
    Fixes: 4522a70db7aa ("l2tp: fix reading optional fields of L2TPv3")
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c3cb65d561e76fd0398026c023e587fec70e188
Author: Lin, Zhenpeng <zplin@psu.edu>
Date:   Wed Sep 8 03:40:59 2021 +0000

    dccp: don't duplicate ccid when cloning dccp sock
    
    commit d9ea761fdd197351890418acd462c51f241014a7 upstream.
    
    Commit 2677d2067731 ("dccp: don't free ccid2_hc_tx_sock ...") fixed
    a UAF but reintroduced CVE-2017-6074.
    
    When the sock is cloned, two dccps_hc_tx_ccid will reference to the
    same ccid. So one can free the ccid object twice from two socks after
    cloning.
    
    This issue was found by "Hadar Manor" as well and assigned with
    CVE-2020-16119, which was fixed in Ubuntu's kernel. So here I port
    the patch from Ubuntu to fix it.
    
    The patch prevents cloned socks from referencing the same ccid.
    
    Fixes: 2677d2067731410 ("dccp: don't free ccid2_hc_tx_sock ...")
    Signed-off-by: Zhenpeng Lin <zplin@psu.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6f80766558b72d59bd7a25519abc55c71c126c7
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Sep 13 15:06:05 2021 -0700

    ptp: dp83640: don't define PAGE0
    
    commit 7366c23ff492ad260776a3ee1aaabba9fc773a8b upstream.
    
    Building dp83640.c on arch/parisc/ produces a build warning for
    PAGE0 being redefined. Since the macro is not used in the dp83640
    driver, just make it a comment for documentation purposes.
    
    In file included from ../drivers/net/phy/dp83640.c:23:
    ../drivers/net/phy/dp83640_reg.h:8: warning: "PAGE0" redefined
        8 | #define PAGE0                     0x0000
                     from ../drivers/net/phy/dp83640.c:11:
    ../arch/parisc/include/asm/page.h:187: note: this is the location of the previous definition
      187 | #define PAGE0   ((struct zeropage *)__PAGE_OFFSET)
    
    Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Richard Cochran <richard.cochran@omicron.at>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Heiner Kallweit <hkallweit1@gmail.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20210913220605.19682-1-rdunlap@infradead.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd6d9a0dd4111691542ef84db5847fcbdda35686
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Sep 13 11:08:36 2021 -0700

    net-caif: avoid user-triggerable WARN_ON(1)
    
    commit 550ac9c1aaaaf51fd42e20d461f0b1cdbd55b3d2 upstream.
    
    syszbot triggers this warning, which looks something
    we can easily prevent.
    
    If we initialize priv->list_field in chnl_net_init(),
    then always use list_del_init(), we can remove robust_list_del()
    completely.
    
    WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 robust_list_del net/caif/chnl_net.c:67 [inline]
    WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375
    Modules linked in:
    CPU: 0 PID: 3233 Comm: syz-executor.3 Not tainted 5.14.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:robust_list_del net/caif/chnl_net.c:67 [inline]
    RIP: 0010:chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375
    Code: 89 eb e8 3a a3 ba f8 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 bf 01 00 00 48 81 fb 00 14 4e 8d 48 8b 2b 75 d0 e8 17 a3 ba f8 <0f> 0b 5b 5d 41 5c 41 5d e9 0a a3 ba f8 4c 89 e3 e8 02 a3 ba f8 4c
    RSP: 0018:ffffc90009067248 EFLAGS: 00010202
    RAX: 0000000000008780 RBX: ffffffff8d4e1400 RCX: ffffc9000fd34000
    RDX: 0000000000040000 RSI: ffffffff88bb6e49 RDI: 0000000000000003
    RBP: ffff88802cd9ee08 R08: 0000000000000000 R09: ffffffff8d0e6647
    R10: ffffffff88bb6dc2 R11: 0000000000000000 R12: ffff88803791ae08
    R13: dffffc0000000000 R14: 00000000e600ffce R15: ffff888073ed3480
    FS:  00007fed10fa0700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b2c322000 CR3: 00000000164a6000 CR4: 00000000001506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     register_netdevice+0xadf/0x1500 net/core/dev.c:10347
     ipcaif_newlink+0x4c/0x260 net/caif/chnl_net.c:468
     __rtnl_newlink+0x106d/0x1750 net/core/rtnetlink.c:3458
     rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3506
     rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
     netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
     netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
     netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
     sock_sendmsg_nosec net/socket.c:704 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:724
     __sys_sendto+0x21c/0x320 net/socket.c:2036
     __do_sys_sendto net/socket.c:2048 [inline]
     __se_sys_sendto net/socket.c:2044 [inline]
     __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2044
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: cc36a070b590 ("net-caif: add CAIF netdevice")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 855c17ffa65fe61b1e3cc9164833496191dc61e1
Author: Eli Cohen <elic@nvidia.com>
Date:   Wed Sep 15 07:47:27 2021 +0300

    net/{mlx5|nfp|bnxt}: Remove unnecessary RTNL lock assert
    
    commit 7c3a0a018e672a9723a79b128227272562300055 upstream.
    
    Remove the assert from the callback priv lookup function since it does
    not require RTNL lock and is already protected by flow_indr_block_lock.
    
    This will avoid warnings from being emitted to dmesg if the driver
    registers its callback after an ingress qdisc was created for a
    netdevice.
    
    The warnings started after the following patch was merged:
    commit 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation")
    
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5c9ee2d367bf4e9939e2888e20999b932c545e9
Author: Saeed Mahameed <saeedm@nvidia.com>
Date:   Mon Jul 26 15:15:39 2021 -0700

    ethtool: Fix rxnfc copy to user buffer overflow
    
    commit 9b29a161ef38040f000dcf9ccf78e34495edfd55 upstream.
    
    In the cited commit, copy_to_user() got called with the wrong pointer,
    instead of passing the actual buffer ptr to copy from, a pointer to
    the pointer got passed, which causes a buffer overflow calltrace to pop
    up when executing "ethtool -x ethX".
    
    Fix ethtool_rxnfc_copy_to_user() to use the rxnfc pointer as passed
    to the function, instead of a pointer to it.
    
    This fixes below call trace:
    [   15.533533] ------------[ cut here ]------------
    [   15.539007] Buffer overflow detected (8 < 192)!
    [   15.544110] WARNING: CPU: 3 PID: 1801 at include/linux/thread_info.h:200 copy_overflow+0x15/0x20
    [   15.549308] Modules linked in:
    [   15.551449] CPU: 3 PID: 1801 Comm: ethtool Not tainted 5.14.0-rc2+ #1058
    [   15.553919] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [   15.558378] RIP: 0010:copy_overflow+0x15/0x20
    [   15.560648] Code: e9 7c ff ff ff b8 a1 ff ff ff eb c4 66 0f 1f 84 00 00 00 00 00 55 48 89 f2 89 fe 48 c7 c7 88 55 78 8a 48 89 e5 e8 06 5c 1e 00 <0f> 0b 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55
    [   15.565114] RSP: 0018:ffffad49c0523bd0 EFLAGS: 00010286
    [   15.566231] RAX: 0000000000000000 RBX: 00000000000000c0 RCX: 0000000000000000
    [   15.567616] RDX: 0000000000000001 RSI: ffffffff8a7912e7 RDI: 00000000ffffffff
    [   15.569050] RBP: ffffad49c0523bd0 R08: ffffffff8ab2ae28 R09: 00000000ffffdfff
    [   15.570534] R10: ffffffff8aa4ae40 R11: ffffffff8aa4ae40 R12: 0000000000000000
    [   15.571899] R13: 00007ffd4cc2a230 R14: ffffad49c0523c00 R15: 0000000000000000
    [   15.573584] FS:  00007f538112f740(0000) GS:ffff96d5bdd80000(0000) knlGS:0000000000000000
    [   15.575639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   15.577092] CR2: 00007f5381226d40 CR3: 0000000013542000 CR4: 00000000001506e0
    [   15.578929] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   15.580695] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   15.582441] Call Trace:
    [   15.582970]  ethtool_rxnfc_copy_to_user+0x30/0x46
    [   15.583815]  ethtool_get_rxnfc.cold+0x23/0x2b
    [   15.584584]  dev_ethtool+0x29c/0x25f0
    [   15.585286]  ? security_netlbl_sid_to_secattr+0x77/0xd0
    [   15.586728]  ? do_set_pte+0xc4/0x110
    [   15.587349]  ? _raw_spin_unlock+0x18/0x30
    [   15.588118]  ? __might_sleep+0x49/0x80
    [   15.588956]  dev_ioctl+0x2c1/0x490
    [   15.589616]  sock_ioctl+0x18e/0x330
    [   15.591143]  __x64_sys_ioctl+0x41c/0x990
    [   15.591823]  ? irqentry_exit_to_user_mode+0x9/0x20
    [   15.592657]  ? irqentry_exit+0x33/0x40
    [   15.593308]  ? exc_page_fault+0x32f/0x770
    [   15.593877]  ? exit_to_user_mode_prepare+0x3c/0x130
    [   15.594775]  do_syscall_64+0x35/0x80
    [   15.595397]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   15.596037] RIP: 0033:0x7f5381226d4b
    [   15.596492] Code: 0f 1e fa 48 8b 05 3d b1 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 0d b1 0c 00 f7 d8 64 89 01 48
    [   15.598743] RSP: 002b:00007ffd4cc2a1f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    [   15.599804] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5381226d4b
    [   15.600795] RDX: 00007ffd4cc2a350 RSI: 0000000000008946 RDI: 0000000000000003
    [   15.601712] RBP: 00007ffd4cc2a340 R08: 00007ffd4cc2a350 R09: 0000000000000001
    [   15.602751] R10: 00007f538128a990 R11: 0000000000000246 R12: 0000000000000000
    [   15.603882] R13: 00007ffd4cc2a350 R14: 00007ffd4cc2a4b0 R15: 0000000000000000
    [   15.605042] ---[ end trace 325cf185e2795048 ]---
    
    Fixes: dd98d2895de6 ("ethtool: improve compat ioctl handling")
    Reported-by: Shannon Nelson <snelson@pensando.io>
    CC: Arnd Bergmann <arnd@arndb.de>
    CC: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Tested-by: Shannon Nelson <snelson@pensando.io>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee3ffd56b40ea6e5128502d03b49ffb53a09c7f6
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Jul 23 13:25:36 2021 -0400

    tipc: fix an use-after-free issue in tipc_recvmsg
    
    commit cc19862ffe454a5b632ca202e5a51bfec9f89fd2 upstream.
    
    syzbot reported an use-after-free crash:
    
      BUG: KASAN: use-after-free in tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979
      Call Trace:
       tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979
       sock_recvmsg_nosec net/socket.c:943 [inline]
       sock_recvmsg net/socket.c:961 [inline]
       sock_recvmsg+0xca/0x110 net/socket.c:957
       tipc_conn_rcv_from_sock+0x162/0x2f0 net/tipc/topsrv.c:398
       tipc_conn_recv_work+0xeb/0x190 net/tipc/topsrv.c:421
       process_one_work+0x98d/0x1630 kernel/workqueue.c:2276
       worker_thread+0x658/0x11f0 kernel/workqueue.c:2422
    
    As Hoang pointed out, it was caused by skb_cb->bytes_read still accessed
    after calling tsk_advance_rx_queue() to free the skb in tipc_recvmsg().
    
    This patch is to fix it by accessing skb_cb->bytes_read earlier than
    calling tsk_advance_rx_queue().
    
    Fixes: f4919ff59c28 ("tipc: keep the skb in rcv queue until the whole data is read")
    Reported-by: syzbot+e6741b97d5552f97c24d@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12551b75b00b8d1de3a944ab44c997bee7c9bce0
Author: Mike Rapoport <rppt@kernel.org>
Date:   Thu Aug 19 16:27:17 2021 +0300

    x86/mm: Fix kern_addr_valid() to cope with existing but not present entries
    
    commit 34b1999da935a33be6239226bfa6cd4f704c5c88 upstream.
    
    Jiri Olsa reported a fault when running:
    
      # cat /proc/kallsyms | grep ksys_read
      ffffffff8136d580 T ksys_read
      # objdump -d --start-address=0xffffffff8136d580 --stop-address=0xffffffff8136d590 /proc/kcore
    
      /proc/kcore:     file format elf64-x86-64
    
      Segmentation fault
    
      general protection fault, probably for non-canonical address 0xf887ffcbff000: 0000 [#1] SMP PTI
      CPU: 12 PID: 1079 Comm: objdump Not tainted 5.14.0-rc5qemu+ #508
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014
      RIP: 0010:kern_addr_valid
      Call Trace:
       read_kcore
       ? rcu_read_lock_sched_held
       ? rcu_read_lock_sched_held
       ? rcu_read_lock_sched_held
       ? trace_hardirqs_on
       ? rcu_read_lock_sched_held
       ? lock_acquire
       ? lock_acquire
       ? rcu_read_lock_sched_held
       ? lock_acquire
       ? rcu_read_lock_sched_held
       ? rcu_read_lock_sched_held
       ? rcu_read_lock_sched_held
       ? lock_release
       ? _raw_spin_unlock
       ? __handle_mm_fault
       ? rcu_read_lock_sched_held
       ? lock_acquire
       ? rcu_read_lock_sched_held
       ? lock_release
       proc_reg_read
       ? vfs_read
       vfs_read
       ksys_read
       do_syscall_64
       entry_SYSCALL_64_after_hwframe
    
    The fault happens because kern_addr_valid() dereferences existent but not
    present PMD in the high kernel mappings.
    
    Such PMDs are created when free_kernel_image_pages() frees regions larger
    than 2Mb. In this case, a part of the freed memory is mapped with PMDs and
    the set_memory_np_noalias() -> ... -> __change_page_attr() sequence will
    mark the PMD as not present rather than wipe it completely.
    
    Have kern_addr_valid() check whether higher level page table entries are
    present before trying to dereference them to fix this issue and to avoid
    similar issues in the future.
    
    Stable backporting note:
    ------------------------
    
    Note that the stable marking is for all active stable branches because
    there could be cases where pagetable entries exist but are not valid -
    see 9a14aefc1d28 ("x86: cpa, fix lookup_address"), for example. So make
    sure to be on the safe side here and use pXY_present() accessors rather
    than pXY_none() which could #GP when accessing pages in the direct map.
    
    Also see:
    
      c40a56a7818c ("x86/mm/init: Remove freed kernel image areas from alias mapping")
    
    for more info.
    
    Reported-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Acked-by: Dave Hansen <dave.hansen@intel.com>
    Tested-by: Jiri Olsa <jolsa@redhat.com>
    Cc: <stable@vger.kernel.org>    # 4.4+
    Link: https://lkml.kernel.org/r/20210819132717.19358-1-rppt@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6672dc68e28eca6ba8ffc2809db4cdd8f0cc5d12
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Wed Aug 11 17:07:37 2021 -0400

    x86/pat: Pass valid address to sanitize_phys()
    
    commit aeef8b5089b76852bd84889f2809e69a7cfb414e upstream.
    
    The end address passed to memtype_reserve() is handed directly to
    sanitize_phys().  However, end is exclusive and sanitize_phys() expects
    an inclusive address.  If end falls at the end of the physical address
    space, sanitize_phys() will return 0.  This can result in drivers
    failing to load, and the following warning:
    
     WARNING: CPU: 26 PID: 749 at arch/x86/mm/pat.c:354 reserve_memtype+0x262/0x450
     reserve_memtype failed: [mem 0x3ffffff00000-0xffffffffffffffff], req uncached-minus
     Call Trace:
      [<ffffffffa427b1f2>] reserve_memtype+0x262/0x450
      [<ffffffffa42764aa>] ioremap_nocache+0x1a/0x20
      [<ffffffffc04620a1>] mpt3sas_base_map_resources+0x151/0xa60 [mpt3sas]
      [<ffffffffc0465555>] mpt3sas_base_attach+0xf5/0xa50 [mpt3sas]
     ---[ end trace 6d6eea4438db89ef ]---
     ioremap reserve_memtype failed -22
     mpt3sas_cm0: unable to map adapter memory! or resource not found
     mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10597/_scsih_probe()!
    
    Fix this by passing the inclusive end address to sanitize_phys().
    
    Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses")
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/x49o8a3pu5i.fsf@segfault.boston.devel.redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0346f8a2c5ecef2fea9932ebeb447c0d957f749a
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Thu Sep 9 12:20:56 2021 +0200

    s390/sclp: fix Secure-IPL facility detection
    
    commit d76b14f3971a0638b6cd0da289f8b48acee287d0 upstream.
    
    Prevent out-of-range access if the returned SCLP SCCB response is smaller
    in size than the address of the Secure-IPL flag.
    
    Fixes: c9896acc7851 ("s390/ipl: Provide has_secure sysfs attribute")
    Cc: stable@vger.kernel.org # 5.2+
    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc9d96c9f9e009b8a33385fab9b78ccf92e51d6e
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:30 2021 +0200

    drm/etnaviv: add missing MMU context put when reaping MMU mapping
    
    commit f2faea8b64125852fa9acc6771c07fc0311a039b upstream.
    
    When we forcefully evict a mapping from the the address space and thus the
    MMU context, the MMU context is leaked, as the mapping no longer points to
    it, so it doesn't get freed when the GEM object is destroyed. Add the
    mssing context put to fix the leak.
    
    Cc: stable@vger.kernel.org # 5.4
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea995e8a629446c4a27e7f8042fc08e05659298b
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:29 2021 +0200

    drm/etnaviv: reference MMU context when setting up hardware state
    
    commit d6408538f091fb22d47f792d4efa58143d56c3fb upstream.
    
    Move the refcount manipulation of the MMU context to the point where the
    hardware state is programmed. At that point it is also known if a previous
    MMU state is still there, or the state needs to be reprogrammed with a
    potentially different context.
    
    Cc: stable@vger.kernel.org # 5.4
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 660dfbf208a4bf3eaab8560e8671be831b52e1c1
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:28 2021 +0200

    drm/etnaviv: fix MMU context leak on GPU reset
    
    commit f978a5302f5566480c58ffae64a16d34456801bd upstream.
    
    After a reset the GPU is no longer using the MMU context and may be
    restarted with a different context. While the mmu_state proeprly was
    cleared, the context wasn't unreferenced, leading to a memory leak.
    
    Cc: stable@vger.kernel.org # 5.4
    Reported-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22163efedcf303e7d1b73bb3bd3aee26bd41b888
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:27 2021 +0200

    drm/etnaviv: exec and MMU state is lost when resetting the GPU
    
    commit 725cbc7884c37f3b4f1777bc1aea6432cded8ca5 upstream.
    
    When the GPU is reset both the current exec state, as well as all MMU
    state is lost. Move the driver side state tracking into the reset function
    to keep hardware and software state from diverging.
    
    Cc: stable@vger.kernel.org # 5.4
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b1c223d8a53a9b08f06c65d932eeb3278022ee8
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:26 2021 +0200

    drm/etnaviv: keep MMU context across runtime suspend/resume
    
    commit 8f3eea9d01d7b0f95b0fe04187c0059019ada85b upstream.
    
    The MMU state may be kept across a runtime suspend/resume cycle, as we
    avoid a full hardware reset to keep the latency of the runtime PM small.
    
    Don't pretend that the MMU state is lost in driver state. The MMU
    context is pushed out when new HW jobs with a different context are
    coming in. The only exception to this is when the GPU is unbound, in
    which case we need to make sure to also free the last active context.
    
    Cc: stable@vger.kernel.org # 5.4
    Reported-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c63e6e0951ff4ab021947b834db37f591781ee28
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:25 2021 +0200

    drm/etnaviv: stop abusing mmu_context as FE running marker
    
    commit 23e0f5a57d0ecec86e1fc82194acd94aede21a46 upstream.
    
    While the DMA frontend can only be active when the MMU context is set, the
    reverse isn't necessarily true, as the frontend can be stopped while the
    MMU state is kept. Stop treating mmu_context being set as a indication that
    the frontend is running and instead add a explicit property.
    
    Cc: stable@vger.kernel.org # 5.4
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf24bd826e4b4c99b2f183a2cc605b0ae641420a
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:24 2021 +0200

    drm/etnaviv: put submit prev MMU context when it exists
    
    commit cda7532916f7bc860b36a1806cb8352e6f63dacb upstream.
    
    The prev context is the MMU context at the time of the job
    queueing in hardware. As a job might be queued multiple times
    due to recovery after a GPU hang, we need to make sure to put
    the stale prev MMU context from a prior queuing, to avoid the
    reference and thus the MMU context leaking.
    
    Cc: stable@vger.kernel.org # 5.4
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0759f648470b5713b0ed89353607a8e0cd3f395e
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 20 22:18:23 2021 +0200

    drm/etnaviv: return context from etnaviv_iommu_context_get
    
    commit 78edefc05e41352099ffb8f06f8d9b2d091e29cd upstream.
    
    Being able to have the refcount manipulation in an assignment makes
    it much easier to parse the code.
    
    Cc: stable@vger.kernel.org # 5.4
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Michael Walle <michael@walle.cc>
    Tested-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f95553f0016c3994d9c022b5af4a1a433d6714e
Author: Ernst Sjöstrand <ernstp@gmail.com>
Date:   Thu Sep 2 09:50:27 2021 +0200

    drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10
    
    commit 67a44e659888569a133a8f858c8230e9d7aad1d5 upstream.
    
    Seems like newer cards can have even more instances now.
    Found by UBSAN: array-index-out-of-bounds in
    drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29
    index 8 is out of range for type 'uint32_t *[8]'
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697
    Cc: stable@vger.kernel.org
    Signed-off-by: Ernst Sjöstrand <ernstp@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87f7032dc2276cec3317c01d626c86093353f39e
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Sep 3 14:33:11 2021 +0800

    PCI: Add AMD GPU multi-function power dependencies
    
    commit 60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a upstream.
    
    Some AMD GPUs have built-in USB xHCI and USB Type-C UCSI controllers with
    power dependencies between the GPU and the other functions as in
    6d2e369f0d4c ("PCI: Add NVIDIA GPU multi-function power dependencies").
    
    Add device link support for the AMD integrated USB xHCI and USB Type-C UCSI
    controllers.
    
    Without this, runtime power management, including GPU resume and temp and
    fan sensors don't work correctly.
    
    Reported-at: https://gitlab.freedesktop.org/drm/amd/-/issues/1704
    Link: https://lore.kernel.org/r/20210903063311.3606226-1-evan.quan@amd.com
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd64b416aed2f152d89c25db2ebf4f05e16fc08d
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Sep 3 10:49:36 2021 +0200

    PM: base: power: don't try to use non-existing RTC for storing data
    
    commit 0560204b360a332c321124dbc5cdfd3364533a74 upstream.
    
    If there is no legacy RTC device, don't try to use it for storing trace
    data across suspend/resume.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
    Link: https://lore.kernel.org/r/20210903084937.19392-2-jgross@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a67e7cdbc633076e5e54ae40d68581c55daea5b5
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Sep 9 17:53:56 2021 +0100

    arm64/sve: Use correct size when reinitialising SVE state
    
    commit e35ac9d0b56e9efefaeeb84b635ea26c2839ea86 upstream.
    
    When we need a buffer for SVE register state we call sve_alloc() to make
    sure that one is there. In order to avoid repeated allocations and frees
    we keep the buffer around unless we change vector length and just memset()
    it to ensure a clean register state. The function that deals with this
    takes the task to operate on as an argument, however in the case where we
    do a memset() we initialise using the SVE state size for the current task
    rather than the task passed as an argument.
    
    This is only an issue in the case where we are setting the register state
    for a task via ptrace and the task being configured has a different vector
    length to the task tracing it. In the case where the buffer is larger in
    the traced process we will leak old state from the traced process to
    itself, in the case where the buffer is smaller in the traced process we
    will overflow the buffer and corrupt memory.
    
    Fixes: bc0ee4760364 ("arm64/sve: Core task context handling")
    Cc: <stable@vger.kernel.org> # 4.15.x
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210909165356.10675-1-broonie@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84da60070c36ddcd8bf4a576e637be8e86535ede
Author: Adrian Bunk <bunk@kernel.org>
Date:   Sun Sep 12 22:05:23 2021 +0300

    bnx2x: Fix enabling network interfaces without VFs
    
    commit 52ce14c134a003fee03d8fc57442c05a55b53715 upstream.
    
    This function is called to enable SR-IOV when available,
    not enabling interfaces without VFs was a regression.
    
    Fixes: 65161c35554f ("bnx2x: Fix missing error code in bnx2x_iov_init_one()")
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
    Reported-by: YunQiang Su <wzssyqa@gmail.com>
    Tested-by: YunQiang Su <wzssyqa@gmail.com>
    Cc: stable@vger.kernel.org
    Acked-by: Shai Malin <smalin@marvell.com>
    Link: https://lore.kernel.org/r/20210912190523.27991-1-bunk@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a5a3ba21aeebc6908c06c31125bcdc7584194a2
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Sep 3 10:49:37 2021 +0200

    xen: reset legacy rtc flag for PV domU
    
    commit f68aa100d815b5b4467fd1c3abbe3b99d65fd028 upstream.
    
    A Xen PV guest doesn't have a legacy RTC device, so reset the legacy
    RTC flag. Otherwise the following WARN splat will occur at boot:
    
    [    1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210
    [    1.333404] Modules linked in:
    [    1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W         5.14.0-rc7-default+ #282
    [    1.333404] RIP: e030:mc146818_get_time+0x1be/0x210
    [    1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff
    [    1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002
    [    1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000
    [    1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d
    [    1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000
    [    1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200
    [    1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4
    [    1.333404] FS:  0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000
    [    1.333404] CS:  10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660
    [    1.333404] Call Trace:
    [    1.333404]  ? wakeup_sources_sysfs_init+0x30/0x30
    [    1.333404]  ? rdinit_setup+0x2b/0x2b
    [    1.333404]  early_resume_init+0x23/0xa4
    [    1.333404]  ? cn_proc_init+0x36/0x36
    [    1.333404]  do_one_initcall+0x3e/0x200
    [    1.333404]  kernel_init_freeable+0x232/0x28e
    [    1.333404]  ? rest_init+0xd0/0xd0
    [    1.333404]  kernel_init+0x16/0x120
    [    1.333404]  ret_from_fork+0x1f/0x30
    
    Cc: <stable@vger.kernel.org>
    Fixes: 8d152e7a5c7537 ("x86/rtc: Replace paravirt rtc check with platform legacy quirk")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: https://lore.kernel.org/r/20210903084937.19392-3-jgross@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce8f81b76d3bef7b9fe6c8f84d029ab898b19469
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Sep 12 06:45:07 2021 -0600

    io_uring: ensure symmetry in handling iter types in loop_rw_iter()
    
    commit 16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc upstream.
    
    When setting up the next segment, we check what type the iter is and
    handle it accordingly. However, when incrementing and processed amount
    we do not, and both iter advance and addr/len are adjusted, regardless
    of type. Split the increment side just like we do on the setup side.
    
    Fixes: 4017eb91a9e7 ("io_uring: make loop_rw_iter() use original user supplied pointers")
    Cc: stable@vger.kernel.org
    Reported-by: Valentina Palmiotti <vpalmiotti@gmail.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88f3d951e2dbdc7927da799792d885c20b8b94d5
Author: Anand Jain <anand.jain@oracle.com>
Date:   Tue Aug 10 23:23:44 2021 +0800

    btrfs: fix upper limit for max_inline for page size 64K
    
    commit 6f93e834fa7c5faa0372e46828b4b2a966ac61d7 upstream.
    
    The mount option max_inline ranges from 0 to the sectorsize (which is
    now equal to page size). But we parse the mount options too early and
    before the actual sectorsize is read from the superblock. So the upper
    limit of max_inline is unaware of the actual sectorsize and is limited
    by the temporary sectorsize 4096, even on a system where the default
    sectorsize is 64K.
    
    Fix this by reading the superblock sectorsize before the mount option
    parse.
    
    Reported-by: Alexander Tsvetkov <alexander.tsvetkov@oracle.com>
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 575279059e26b27aababbb7edae2f0f19205779d
Author: Robert Foss <robert.foss@linaro.org>
Date:   Thu Dec 17 15:09:33 2020 +0100

    drm/bridge: lt9611: Fix handling of 4k panels
    
    commit d1a97648ae028a44536927c87837c45ada7141c9 upstream.
    
    4k requires two dsi pipes, so don't report MODE_OK when only a
    single pipe is configured. But rather report MODE_PANEL to
    signal that requirements of the panel are not being met.
    
    Reported-by: Peter Collingbourne <pcc@google.com>
    Suggested-by: Peter Collingbourne <pcc@google.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Tested-by: John Stultz <john.stultz@linaro.org>
    Tested-by: Anibal Limon <anibal.limon@linaro.org>
    Tested-by: Peter Collingbourne <pcc@google.com>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Acked-by: Vinod Koul <vkoul@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org
    Cc: Peter Collingbourne <pcc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
