commit e90fbe65c6b31ed48a6f13c232b0ca26688218d5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 29 10:08:36 2022 +0200

    Linux 6.0.6
    
    Link: https://lore.kernel.org/r/20221027165057.208202132@linuxfoundation.org
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>=20
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97898139ca9b81ba9322a585e07490983c53b55a
Author: Seth Jenkins <sethjenkins@google.com>
Date:   Thu Oct 27 11:36:52 2022 -0400

    mm: /proc/pid/smaps_rollup: fix no vma's null-deref
    
    Commit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value
    seq_file") introduced a null-deref if there are no vma's in the task in
    show_smaps_rollup.
    
    Fixes: 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file")
    Signed-off-by: Seth Jenkins <sethjenkins@google.com>
    Reviewed-by: Alexey Dobriyan <adobriyan@gmail.com>
    Tested-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f9134dd5a8307336c145ec054963680409ef26c
Author: Werner Sembach <wse@tuxedocomputers.com>
Date:   Wed Oct 26 17:22:46 2022 +0200

    ACPI: video: Force backlight native for more TongFang devices
    
    commit 3dbc80a3e4c55c4a5b89ef207bed7b7de36157b4 upstream.
    
    This commit is very different from the upstream commit! It fixes the same
    issue by adding more quirks, rather then the general fix from the 6.1
    kernel, because the general fix from the 6.1 kernel is part of a larger
    refactoring of the backlight code which is not suitable for the stable
    series.
    
    As described in "ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U??
    acpi_backlight=native quirks" (10212754a0d2) the upstream commit "ACPI:
    video: Make backlight class device registration a separate step (v2)"
    (3dbc80a3e4c5) makes these quirks unnecessary. However as mentioned in this
    bugtracker ticket https://bugzilla.kernel.org/show_bug.cgi?id=215683#c17
    the upstream fix is part of a larger patchset that is overall too complex
    for stable.
    
    The TongFang GKxNRxx, GMxNGxx, GMxZGxx, and GMxRGxx / TUXEDO
    Stellaris/Polaris Gen 1-4, have the same problem as the Clevo NL5xRU and
    NL5xNU / TUXEDO Aura 15 Gen1 and Gen2:
    They have a working native and video interface for screen backlight.
    However the default detection mechanism first registers the video interface
    before unregistering it again and switching to the native interface during
    boot. This results in a dangling SBIOS request for backlight change for
    some reason, causing the backlight to switch to ~2% once per boot on the
    first power cord connect or disconnect event. Setting the native interface
    explicitly circumvents this buggy behaviour by avoiding the unregistering
    process.
    
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f234294812c9b68d603650d28743eafb718e7ad5
Author: Ye Bin <yebin10@huawei.com>
Date:   Sat Sep 24 15:52:33 2022 +0800

    ext4: fix potential out of bound read in ext4_fc_replay_scan()
    
    [ Upstream commit 1b45cc5c7b920fd8bf72e5a888ec7abeadf41e09 ]
    
    For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain
    space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read
    when mounting corrupt file system image.
    ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this
    three tags will read data during scan, tag length couldn't less than data length
    which will read.
    
    Cc: stable@kernel.org
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Link: https://lore.kernel.org/r/20220924075233.2315259-4-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d6873c4a695867964ee04c4cf7f1d1f2ce8cfed
Author: Ye Bin <yebin10@huawei.com>
Date:   Sat Sep 24 15:52:32 2022 +0800

    ext4: factor out ext4_fc_get_tl()
    
    [ Upstream commit dcc5827484d6e53ccda12334f8bbfafcc593ceda ]
    
    Factor out ext4_fc_get_tl() to fill 'tl' with host byte order.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Link: https://lore.kernel.org/r/20220924075233.2315259-3-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 1b45cc5c7b92 ("ext4: fix potential out of bound read in ext4_fc_replay_scan()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85ddefaa901bb74e2d90635f3a0b8d7e1b9ce5f6
Author: Ye Bin <yebin10@huawei.com>
Date:   Sat Sep 24 15:52:31 2022 +0800

    ext4: introduce EXT4_FC_TAG_BASE_LEN helper
    
    [ Upstream commit fdc2a3c75dd8345c5b48718af90bad1a7811bedb ]
    
    Introduce EXT4_FC_TAG_BASE_LEN helper for calculate length of
    struct ext4_fc_tl.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Link: https://lore.kernel.org/r/20220924075233.2315259-2-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 1b45cc5c7b92 ("ext4: fix potential out of bound read in ext4_fc_replay_scan()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a7d9406321093b75393ae6524a9f929f5544c07
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Sep 29 15:29:13 2022 -0600

    io_uring: don't gate task_work run on TIF_NOTIFY_SIGNAL
    
    [ Upstream commit 46a525e199e4037516f7e498c18f065b09df32ac ]
    
    This isn't a reliable mechanism to tell if we have task_work pending, we
    really should be looking at whether we have any items queued. This is
    problematic if forward progress is gated on running said task_work. One
    such example is reading from a pipe, where the write side has been closed
    right before the read is started. The fput() of the file queues TWA_RESUME
    task_work, and we need that task_work to be run before ->release() is
    called for the pipe. If ->release() isn't called, then the read will sit
    forever waiting on data that will never arise.
    
    Fix this by io_run_task_work() so it checks if we have task_work pending
    rather than rely on TIF_NOTIFY_SIGNAL for that. The latter obviously
    doesn't work for task_work that is queued without TWA_SIGNAL.
    
    Reported-by: Christiano Haesbaert <haesbaert@haesbaert.org>
    Cc: stable@vger.kernel.org
    Link: https://github.com/axboe/liburing/issues/665
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4c2e8f738488d83ebb81a9788b5e3b7f9806ccf
Author: Deren Wu <deren.wu@mediatek.com>
Date:   Mon Sep 12 16:45:52 2022 +0800

    wifi: mt76: mt7921e: fix random fw download fail
    
    [ Upstream commit 29e247ece5d3edfa71495768a9ab5fc7bba76bd4 ]
    
    In case of PCIe interoperability problem shows up, the firmware
    payload may be corrupted in download stage. Turn off L0s to keep
    fw download process accurately.
    
    [ 1093.528363] mt7921e 0000:3b:00.0: Message 00000007 (seq 7) timeout
    [ 1093.528414] mt7921e 0000:3b:00.0: Failed to start patch
    [ 1096.600156] mt7921e 0000:3b:00.0: Message 00000010 (seq 8) timeout
    [ 1096.600207] mt7921e 0000:3b:00.0: Failed to release patch semaphore
    [ 1097.699031] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1098.758427] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1099.834408] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1100.915264] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1101.990625] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1103.077587] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1104.173258] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1105.248466] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1106.336969] mt7921e 0000:3b:00.0: Timeout for driver own
    [ 1106.397542] mt7921e 0000:3b:00.0: hardware init failed
    
    Cc: stable@vger.kernel.org
    Fixes: bf3747ae2e25 ("mt76: mt7921: enable aspm by default")
    Signed-off-by: Deren Wu <deren.wu@mediatek.com>
    Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4ad3ae4c6be9d8b0701761c839771116bca6ea3
Author: Jerry Snitselaar <jsnitsel@redhat.com>
Date:   Wed Oct 19 08:44:47 2022 +0800

    iommu/vt-d: Clean up si_domain in the init_dmars() error path
    
    [ Upstream commit 620bf9f981365c18cc2766c53d92bf8131c63f32 ]
    
    A splat from kmem_cache_destroy() was seen with a kernel prior to
    commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")
    when there was a failure in init_dmars(), because the iommu_domain
    cache still had objects. While the mempool code is now gone, there
    still is a leak of the si_domain memory if init_dmars() fails. So
    clean up si_domain in the init_dmars() error path.
    
    Cc: Lu Baolu <baolu.lu@linux.intel.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Fixes: 86080ccc223a ("iommu/vt-d: Allocate si_domain in init_dmars()")
    Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Link: https://lore.kernel.org/r/20221010144842.308890-1-jsnitsel@redhat.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit beea336ebe1d9821d6ff68dcba3b6058303791e0
Author: Charlotte Tan <charlotte@extrahop.com>
Date:   Wed Oct 19 08:44:46 2022 +0800

    iommu/vt-d: Allow NVS regions in arch_rmrr_sanity_check()
    
    [ Upstream commit 5566e68d829f5d87670d5984c1c2ccb4c518405f ]
    
    arch_rmrr_sanity_check() warns if the RMRR is not covered by an ACPI
    Reserved region, but it seems like it should accept an NVS region as
    well. The ACPI spec
    https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html
    uses similar wording for "Reserved" and "NVS" region types; for NVS
    regions it says "This range of addresses is in use or reserved by the
    system and must not be used by the operating system."
    
    There is an old comment on this mailing list that also suggests NVS
    regions should pass the arch_rmrr_sanity_check() test:
    
     The warnings come from arch_rmrr_sanity_check() since it checks whether
     the region is E820_TYPE_RESERVED. However, if the purpose of the check
     is to detect RMRR has regions that may be used by OS as free memory,
     isn't  E820_TYPE_NVS safe, too?
    
    This patch overlaps with another proposed patch that would add the region
    type to the log since sometimes the bug reporter sees this log on the
    console but doesn't know to include the kernel log:
    
    https://lore.kernel.org/lkml/20220611204859.234975-3-atomlin@redhat.com/
    
    Here's an example of the "Firmware Bug" apparent false positive (wrapped
    for line length):
    
     DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR
           [0x000000006f760000-0x000000006f762fff], contact BIOS vendor for
           fixes
     DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR
           [0x000000006f760000-0x000000006f762fff]
    
    This is the snippet from the e820 table:
    
     BIOS-e820: [mem 0x0000000068bff000-0x000000006ebfefff] reserved
     BIOS-e820: [mem 0x000000006ebff000-0x000000006f9fefff] ACPI NVS
     BIOS-e820: [mem 0x000000006f9ff000-0x000000006fffefff] ACPI data
    
    Fixes: f036c7fa0ab6 ("iommu/vt-d: Check VT-d RMRR region in BIOS is reported as reserved")
    Cc: Will Mortensen <will@extrahop.com>
    Link: https://lore.kernel.org/linux-iommu/64a5843d-850d-e58c-4fc2-0a0eeeb656dc@nec.com/
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216443
    Signed-off-by: Charlotte Tan <charlotte@extrahop.com>
    Reviewed-by: Aaron Tomlin <atomlin@redhat.com>
    Link: https://lore.kernel.org/r/20220929044449.32515-1-charlotte@extrahop.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 671e822241dcd7264b865d7ac0acf256c5a6b6d5
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Tue Aug 23 17:20:28 2022 +0200

    rv/dot2c: Make automaton definition static
    
    [ Upstream commit 21a1994b6492b12e55dbf39d15271430ef6839f0 ]
    
    Monitor's automata definition is only used locally, so make dot2c generate
    a static definition.
    
    Link: https://lore.kernel.org/all/202208210332.gtHXje45-lkp@intel.com
    Link: https://lore.kernel.org/all/202208210358.6HH3OrVs-lkp@intel.com
    Link: https://lkml.kernel.org/r/ffbb92010f643307766c9307fd42f416e5b85fa0.1661266564.git.bristot@kernel.org
    
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Fixes: e3c9fc78f096 ("tools/rv: Add dot2c")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf
Author: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Date:   Thu Oct 20 10:52:05 2022 +0200

    drbd: only clone bio if we have a backing device
    
    [ Upstream commit 6d42ddf7f27b6723549ee6d4c8b1b418b59bf6b5 ]
    
    Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a
    bio_set_dev call (which has since been removed) to "earlier", from
    drbd_request_prepare to drbd_req_new.
    
    The problem is that this accesses device->ldev->backing_bdev, which is
    not NULL-checked at this point. When we don't have an ldev (i.e. when
    the DRBD device is diskless), this leads to a null pointer deref.
    
    So, only allocate the private_bio if we actually have a disk. This is
    also a small optimization, since we don't clone the bio to only to
    immediately free it again in the diskless case.
    
    Fixes: c347a787e34cb ("drbd: set ->bi_bdev in drbd_req_new")
    Co-developed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
    Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
    Co-developed-by: Joel Colledge <joel.colledge@linbit.com>
    Signed-off-by: Joel Colledge <joel.colledge@linbit.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20221020085205.129090-1-christoph.boehmwalder@linbit.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0f8ac08d1874c5a81731e5a52d9dd19f0ee3293
Author: Felix Riemann <felix.riemann@sma.de>
Date:   Tue Oct 18 12:47:54 2022 +0200

    net: phy: dp83822: disable MDI crossover status change interrupt
    
    [ Upstream commit 7f378c03aa4952507521174fb0da7b24a9ad0be6 ]
    
    If the cable is disconnected the PHY seems to toggle between MDI and
    MDI-X modes. With the MDI crossover status interrupt active this causes
    roughly 10 interrupts per second.
    
    As the crossover status isn't checked by the driver, the interrupt can
    be disabled to reduce the interrupt load.
    
    Fixes: 87461f7a58ab ("net: phy: DP83822 initial driver submission")
    Signed-off-by: Felix Riemann <felix.riemann@sma.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20221018104755.30025-1-svc.sw.rte.linux@sma.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit caee0b9d74119911423111a10c4e9f4e5c8e6d41
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 18 20:32:58 2022 +0000

    net: sched: fix race condition in qdisc_graft()
    
    [ Upstream commit ebda44da44f6f309d302522b049f43d6f829f7aa ]
    
    We had one syzbot report [1] in syzbot queue for a while.
    I was waiting for more occurrences and/or a repro but
    Dmitry Vyukov spotted the issue right away.
    
    <quoting Dmitry>
    qdisc_graft() drops reference to qdisc in notify_and_destroy
    while it's still assigned to dev->qdisc
    </quoting>
    
    Indeed, RCU rules are clear when replacing a data structure.
    The visible pointer (dev->qdisc in this case) must be updated
    to the new object _before_ RCU grace period is started
    (qdisc_put(old) in this case).
    
    [1]
    BUG: KASAN: use-after-free in __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066
    Read of size 4 at addr ffff88802065e038 by task syz-executor.4/21027
    
    CPU: 0 PID: 21027 Comm: syz-executor.4 Not tainted 6.0.0-rc3-syzkaller-00363-g7726d4c3e60b #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
    Call Trace:
    <TASK>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
    print_address_description mm/kasan/report.c:317 [inline]
    print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
    kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
    __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066
    __tcf_qdisc_find net/sched/cls_api.c:1051 [inline]
    tc_new_tfilter+0x34f/0x2200 net/sched/cls_api.c:2018
    rtnetlink_rcv_msg+0x955/0xca0 net/core/rtnetlink.c:6081
    netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
    netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
    netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
    netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xcf/0x120 net/socket.c:734
    ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
    __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
    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+0x63/0xcd
    RIP: 0033:0x7f5efaa89279
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f5efbc31168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f5efab9bf80 RCX: 00007f5efaa89279
    RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
    RBP: 00007f5efaae32e9 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007f5efb0cfb1f R14: 00007f5efbc31300 R15: 0000000000022000
    </TASK>
    
    Allocated by task 21027:
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
    kasan_set_track mm/kasan/common.c:45 [inline]
    set_alloc_info mm/kasan/common.c:437 [inline]
    ____kasan_kmalloc mm/kasan/common.c:516 [inline]
    ____kasan_kmalloc mm/kasan/common.c:475 [inline]
    __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525
    kmalloc_node include/linux/slab.h:623 [inline]
    kzalloc_node include/linux/slab.h:744 [inline]
    qdisc_alloc+0xb0/0xc50 net/sched/sch_generic.c:938
    qdisc_create_dflt+0x71/0x4a0 net/sched/sch_generic.c:997
    attach_one_default_qdisc net/sched/sch_generic.c:1152 [inline]
    netdev_for_each_tx_queue include/linux/netdevice.h:2437 [inline]
    attach_default_qdiscs net/sched/sch_generic.c:1170 [inline]
    dev_activate+0x760/0xcd0 net/sched/sch_generic.c:1229
    __dev_open+0x393/0x4d0 net/core/dev.c:1441
    __dev_change_flags+0x583/0x750 net/core/dev.c:8556
    rtnl_configure_link+0xee/0x240 net/core/rtnetlink.c:3189
    rtnl_newlink_create net/core/rtnetlink.c:3371 [inline]
    __rtnl_newlink+0x10b8/0x17e0 net/core/rtnetlink.c:3580
    rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
    rtnetlink_rcv_msg+0x43a/0xca0 net/core/rtnetlink.c:6090
    netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
    netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
    netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
    netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xcf/0x120 net/socket.c:734
    ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
    __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
    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+0x63/0xcd
    
    Freed by task 21020:
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
    kasan_set_track+0x21/0x30 mm/kasan/common.c:45
    kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
    ____kasan_slab_free mm/kasan/common.c:367 [inline]
    ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329
    kasan_slab_free include/linux/kasan.h:200 [inline]
    slab_free_hook mm/slub.c:1754 [inline]
    slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1780
    slab_free mm/slub.c:3534 [inline]
    kfree+0xe2/0x580 mm/slub.c:4562
    rcu_do_batch kernel/rcu/tree.c:2245 [inline]
    rcu_core+0x7b5/0x1890 kernel/rcu/tree.c:2505
    __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571
    
    Last potentially related work creation:
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
    __kasan_record_aux_stack+0xbe/0xd0 mm/kasan/generic.c:348
    call_rcu+0x99/0x790 kernel/rcu/tree.c:2793
    qdisc_put+0xcd/0xe0 net/sched/sch_generic.c:1083
    notify_and_destroy net/sched/sch_api.c:1012 [inline]
    qdisc_graft+0xeb1/0x1270 net/sched/sch_api.c:1084
    tc_modify_qdisc+0xbb7/0x1a00 net/sched/sch_api.c:1671
    rtnetlink_rcv_msg+0x43a/0xca0 net/core/rtnetlink.c:6090
    netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
    netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
    netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
    netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xcf/0x120 net/socket.c:734
    ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
    __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
    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+0x63/0xcd
    
    Second to last potentially related work creation:
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
    __kasan_record_aux_stack+0xbe/0xd0 mm/kasan/generic.c:348
    kvfree_call_rcu+0x74/0x940 kernel/rcu/tree.c:3322
    neigh_destroy+0x431/0x630 net/core/neighbour.c:912
    neigh_release include/net/neighbour.h:454 [inline]
    neigh_cleanup_and_release+0x1f8/0x330 net/core/neighbour.c:103
    neigh_del net/core/neighbour.c:225 [inline]
    neigh_remove_one+0x37d/0x460 net/core/neighbour.c:246
    neigh_forced_gc net/core/neighbour.c:276 [inline]
    neigh_alloc net/core/neighbour.c:447 [inline]
    ___neigh_create+0x18b5/0x29a0 net/core/neighbour.c:642
    ip6_finish_output2+0xfb8/0x1520 net/ipv6/ip6_output.c:125
    __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
    ip6_finish_output+0x690/0x1160 net/ipv6/ip6_output.c:206
    NF_HOOK_COND include/linux/netfilter.h:296 [inline]
    ip6_output+0x1ed/0x540 net/ipv6/ip6_output.c:227
    dst_output include/net/dst.h:451 [inline]
    NF_HOOK include/linux/netfilter.h:307 [inline]
    NF_HOOK include/linux/netfilter.h:301 [inline]
    mld_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820
    mld_send_cr net/ipv6/mcast.c:2121 [inline]
    mld_ifc_work+0x71c/0xdc0 net/ipv6/mcast.c:2653
    process_one_work+0x991/0x1610 kernel/workqueue.c:2289
    worker_thread+0x665/0x1080 kernel/workqueue.c:2436
    kthread+0x2e4/0x3a0 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
    
    The buggy address belongs to the object at ffff88802065e000
    which belongs to the cache kmalloc-1k of size 1024
    The buggy address is located 56 bytes inside of
    1024-byte region [ffff88802065e000, ffff88802065e400)
    
    The buggy address belongs to the physical page:
    page:ffffea0000819600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20658
    head:ffffea0000819600 order:3 compound_mapcount:0 compound_pincount:0
    flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
    raw: 00fff00000010200 0000000000000000 dead000000000001 ffff888011841dc0
    raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 3523, tgid 3523 (sshd), ts 41495190986, free_ts 41417713212
    prep_new_page mm/page_alloc.c:2532 [inline]
    get_page_from_freelist+0x109b/0x2ce0 mm/page_alloc.c:4283
    __alloc_pages+0x1c7/0x510 mm/page_alloc.c:5515
    alloc_pages+0x1a6/0x270 mm/mempolicy.c:2270
    alloc_slab_page mm/slub.c:1824 [inline]
    allocate_slab+0x27e/0x3d0 mm/slub.c:1969
    new_slab mm/slub.c:2029 [inline]
    ___slab_alloc+0x7f1/0xe10 mm/slub.c:3031
    __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3118
    slab_alloc_node mm/slub.c:3209 [inline]
    __kmalloc_node_track_caller+0x2f2/0x380 mm/slub.c:4955
    kmalloc_reserve net/core/skbuff.c:358 [inline]
    __alloc_skb+0xd9/0x2f0 net/core/skbuff.c:430
    alloc_skb_fclone include/linux/skbuff.h:1307 [inline]
    tcp_stream_alloc_skb+0x38/0x580 net/ipv4/tcp.c:861
    tcp_sendmsg_locked+0xc36/0x2f80 net/ipv4/tcp.c:1325
    tcp_sendmsg+0x2b/0x40 net/ipv4/tcp.c:1483
    inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xcf/0x120 net/socket.c:734
    sock_write_iter+0x291/0x3d0 net/socket.c:1108
    call_write_iter include/linux/fs.h:2187 [inline]
    new_sync_write fs/read_write.c:491 [inline]
    vfs_write+0x9e9/0xdd0 fs/read_write.c:578
    ksys_write+0x1e8/0x250 fs/read_write.c:631
    page last free stack trace:
    reset_page_owner include/linux/page_owner.h:24 [inline]
    free_pages_prepare mm/page_alloc.c:1449 [inline]
    free_pcp_prepare+0x5e4/0xd20 mm/page_alloc.c:1499
    free_unref_page_prepare mm/page_alloc.c:3380 [inline]
    free_unref_page+0x19/0x4d0 mm/page_alloc.c:3476
    __unfreeze_partials+0x17c/0x1a0 mm/slub.c:2548
    qlink_free mm/kasan/quarantine.c:168 [inline]
    qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187
    kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:294
    __kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:447
    kasan_slab_alloc include/linux/kasan.h:224 [inline]
    slab_post_alloc_hook mm/slab.h:727 [inline]
    slab_alloc_node mm/slub.c:3243 [inline]
    slab_alloc mm/slub.c:3251 [inline]
    __kmem_cache_alloc_lru mm/slub.c:3258 [inline]
    kmem_cache_alloc+0x267/0x3b0 mm/slub.c:3268
    kmem_cache_zalloc include/linux/slab.h:723 [inline]
    alloc_buffer_head+0x20/0x140 fs/buffer.c:2974
    alloc_page_buffers+0x280/0x790 fs/buffer.c:829
    create_empty_buffers+0x2c/0xee0 fs/buffer.c:1558
    ext4_block_write_begin+0x1004/0x1530 fs/ext4/inode.c:1074
    ext4_da_write_begin+0x422/0xae0 fs/ext4/inode.c:2996
    generic_perform_write+0x246/0x560 mm/filemap.c:3738
    ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:270
    ext4_file_write_iter+0x44a/0x1660 fs/ext4/file.c:679
    call_write_iter include/linux/fs.h:2187 [inline]
    new_sync_write fs/read_write.c:491 [inline]
    vfs_write+0x9e9/0xdd0 fs/read_write.c:578
    
    Fixes: af356afa010f ("net_sched: reintroduce dev->qdisc for use by sch_api")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Diagnosed-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20221018203258.2793282-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02dc0db19d944b4a90941db505ecf1aaec714be4
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Oct 18 20:24:51 2022 +0800

    net: hns: fix possible memory leak in hnae_ae_register()
    
    [ Upstream commit ff2f5ec5d009844ec28f171123f9e58750cef4bf ]
    
    Inject fault while probing module, if device_register() fails,
    but the refcount of kobject is not decreased to 0, the name
    allocated in dev_set_name() is leaked. Fix this by calling
    put_device(), so that name can be freed in callback function
    kobject_cleanup().
    
    unreferenced object 0xffff00c01aba2100 (size 128):
      comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)
      hex dump (first 32 bytes):
        68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff  hnae0....!......
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0
        [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0
        [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390
        [<000000006c0ffb13>] kvasprintf+0x8c/0x118
        [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8
        [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0
        [<000000000b87affc>] dev_set_name+0x7c/0xa0
        [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae]
        [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]
        [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
    
    Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20221018122451.1749171-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d87973314aba6de80a49f4271dd9be4ddc08e729
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Oct 18 21:16:07 2022 +0800

    wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new()
    
    [ Upstream commit 258ad2fe5ede773625adfda88b173f4123e59f45 ]
    
    Inject fault while probing module, if device_register() fails,
    but the refcount of kobject is not decreased to 0, the name
    allocated in dev_set_name() is leaked. Fix this by calling
    put_device(), so that name can be freed in callback function
    kobject_cleanup().
    
    unreferenced object 0xffff88810152ad20 (size 8):
      comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s)
      hex dump (first 8 bytes):
        68 77 73 69 6d 30 00 ff                          hwsim0..
      backtrace:
        [<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0
        [<00000000c0228a5e>] kvasprintf+0xb5/0x140
        [<00000000cff8c21f>] kvasprintf_const+0x55/0x180
        [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150
        [<000000000a80b139>] dev_set_name+0xab/0xe0
    
    Fixes: f36a111a74e7 ("wwan_hwsim: WWAN device simulator")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
    Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
    Link: https://lore.kernel.org/r/20221018131607.1901641-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb56ab8ecf4a4496770355970a088c4a8bca54be
Author: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>
Date:   Tue Oct 18 10:28:41 2022 +0100

    sfc: include vport_id in filter spec hash and equal()
    
    [ Upstream commit c2bf23e4a5af37a4d77901d9ff14c50a269f143d ]
    
    Filters on different vports are qualified by different implicit MACs and/or
    VLANs, so shouldn't be considered equal even if their other match fields
    are identical.
    
    Fixes: 7c460d9be610 ("sfc: Extend and abstract efx_filter_spec to cover Huntington/EF10")
    Co-developed-by: Edward Cree <ecree.xilinx@gmail.com>
    Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
    Signed-off-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>
    Reviewed-by: Martin Habets <habetsm.xilinx@gmail.com>
    Link: https://lore.kernel.org/r/20221018092841.32206-1-pieter.jansen-van-vuuren@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0163e04ea64cc3dfaa12390286e5f2f481c3b2e3
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Wed Oct 19 10:12:18 2022 -0700

    io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()
    
    [ Upstream commit 16bbdfe5fb0e78e0acb13e45fc127e9a296913f2 ]
    
    Syzkaller produced the below call trace:
    
     BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0
     Write of size 8 at addr 0000000000000070 by task repro/16399
    
     CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
     Call Trace:
      <TASK>
      dump_stack_lvl+0xcd/0x134
      ? io_msg_ring+0x3cb/0x9f0
      kasan_report+0xbc/0xf0
      ? io_msg_ring+0x3cb/0x9f0
      kasan_check_range+0x140/0x190
      io_msg_ring+0x3cb/0x9f0
      ? io_msg_ring_prep+0x300/0x300
      io_issue_sqe+0x698/0xca0
      io_submit_sqes+0x92f/0x1c30
      __do_sys_io_uring_enter+0xae4/0x24b0
    ....
     RIP: 0033:0x7f2eaf8f8289
     RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa
     RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289
     RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004
     RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039
     R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0
     R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000
      </TASK>
     Kernel panic - not syncing: panic_on_warn set ...
    
    We don't have a NULL check on file_ptr in io_msg_send_fd() function,
    so when file_ptr is NUL src_file is also NULL and get_file()
    dereferences a NULL pointer and leads to above crash.
    
    Add a NULL check to fix this issue.
    
    Fixes: e6130eba8a84 ("io_uring: add support for passing fixed file descriptors")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Link: https://lore.kernel.org/r/20221019171218.1337614-1-harshit.m.mogalapalli@oracle.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d7f7277df6e4be9a7621d84fe35cb2da76c3b5d
Author: Paul Blakey <paulb@nvidia.com>
Date:   Tue Oct 18 10:34:38 2022 +0300

    net: Fix return value of qdisc ingress handling on success
    
    [ Upstream commit 672e97ef689a38cb20c2cc6a1814298fea34461e ]
    
    Currently qdisc ingress handling (sch_handle_ingress()) doesn't
    set a return value and it is left to the old return value of
    the caller (__netif_receive_skb_core()) which is RX drop, so if
    the packet is consumed, caller will stop and return this value
    as if the packet was dropped.
    
    This causes a problem in the kernel tcp stack when having a
    egress tc rule forwarding to a ingress tc rule.
    The tcp stack sending packets on the device having the egress rule
    will see the packets as not successfully transmitted (although they
    actually were), will not advance it's internal state of sent data,
    and packets returning on such tcp stream will be dropped by the tcp
    stack with reason ack-of-unsent-data. See reproduction in [0] below.
    
    Fix that by setting the return value to RX success if
    the packet was handled successfully.
    
    [0] Reproduction steps:
     $ ip link add veth1 type veth peer name peer1
     $ ip link add veth2 type veth peer name peer2
     $ ifconfig peer1 5.5.5.6/24 up
     $ ip netns add ns0
     $ ip link set dev peer2 netns ns0
     $ ip netns exec ns0 ifconfig peer2 5.5.5.5/24 up
     $ ifconfig veth2 0 up
     $ ifconfig veth1 0 up
    
     #ingress forwarding veth1 <-> veth2
     $ tc qdisc add dev veth2 ingress
     $ tc qdisc add dev veth1 ingress
     $ tc filter add dev veth2 ingress prio 1 proto all flower \
       action mirred egress redirect dev veth1
     $ tc filter add dev veth1 ingress prio 1 proto all flower \
       action mirred egress redirect dev veth2
    
     #steal packet from peer1 egress to veth2 ingress, bypassing the veth pipe
     $ tc qdisc add dev peer1 clsact
     $ tc filter add dev peer1 egress prio 20 proto ip flower \
       action mirred ingress redirect dev veth1
    
     #run iperf and see connection not running
     $ iperf3 -s&
     $ ip netns exec ns0 iperf3 -c 5.5.5.6 -i 1
    
     #delete egress rule, and run again, now should work
     $ tc filter del dev peer1 egress
     $ ip netns exec ns0 iperf3 -c 5.5.5.6 -i 1
    
    Fixes: f697c3e8b35c ("[NET]: Avoid unnecessary cloning for ingress filtering")
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 723399af2795fb95687a531c9480464b5f489333
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Tue Oct 18 14:32:01 2022 +0800

    net: sched: sfb: fix null pointer access issue when sfb_init() fails
    
    [ Upstream commit 2a3fc78210b9f0e85372a2435368962009f480fc ]
    
    When the default qdisc is sfb, if the qdisc of dev_queue fails to be
    inited during mqprio_init(), sfb_reset() is invoked to clear resources.
    In this case, the q->qdisc is NULL, and it will cause gpf issue.
    
    The process is as follows:
    qdisc_create_dflt()
            sfb_init()
                    tcf_block_get()          --->failed, q->qdisc is NULL
            ...
            qdisc_put()
                    ...
                    sfb_reset()
                            qdisc_reset(q->qdisc)    --->q->qdisc is NULL
                                    ops = qdisc->ops
    
    The following is the Call Trace information:
    general protection fault, probably for non-canonical address
    0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
    RIP: 0010:qdisc_reset+0x2b/0x6f0
    Call Trace:
    <TASK>
    sfb_reset+0x37/0xd0
    qdisc_reset+0xed/0x6f0
    qdisc_destroy+0x82/0x4c0
    qdisc_put+0x9e/0xb0
    qdisc_create_dflt+0x2c3/0x4a0
    mqprio_init+0xa71/0x1760
    qdisc_create+0x3eb/0x1000
    tc_modify_qdisc+0x408/0x1720
    rtnetlink_rcv_msg+0x38e/0xac0
    netlink_rcv_skb+0x12d/0x3a0
    netlink_unicast+0x4a2/0x740
    netlink_sendmsg+0x826/0xcc0
    sock_sendmsg+0xc5/0x100
    ____sys_sendmsg+0x583/0x690
    ___sys_sendmsg+0xe8/0x160
    __sys_sendmsg+0xbf/0x160
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f2164122d04
    </TASK>
    
    Fixes: e13e02a3c68d ("net_sched: SFB flow scheduler")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c23f9adda4ed31b074dfd4a4d86cbc5fe77f9e3
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Wed Aug 24 08:52:31 2022 +0800

    net: sched: delete duplicate cleanup of backlog and qlen
    
    [ Upstream commit c19d893fbf3f2f8fa864ae39652c7fee939edde2 ]
    
    qdisc_reset() is clearing qdisc->q.qlen and qdisc->qstats.backlog
    _after_ calling qdisc->ops->reset. There is no need to clear them
    again in the specific reset function.
    
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Link: https://lore.kernel.org/r/20220824005231.345727-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 2a3fc78210b9 ("net: sched: sfb: fix null pointer access issue when sfb_init() fails")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dc0a019550fd38ec6cab2d73c90df2bd659c96b
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Tue Oct 18 14:31:59 2022 +0800

    net: sched: cake: fix null pointer access issue when cake_init() fails
    
    [ Upstream commit 51f9a8921ceacd7bf0d3f47fa867a64988ba1dcb ]
    
    When the default qdisc is cake, if the qdisc of dev_queue fails to be
    inited during mqprio_init(), cake_reset() is invoked to clear
    resources. In this case, the tins is NULL, and it will cause gpf issue.
    
    The process is as follows:
    qdisc_create_dflt()
            cake_init()
                    q->tins = kvcalloc(...)        --->failed, q->tins is NULL
            ...
            qdisc_put()
                    ...
                    cake_reset()
                            ...
                            cake_dequeue_one()
                                    b = &q->tins[...]   --->q->tins is NULL
    
    The following is the Call Trace information:
    general protection fault, probably for non-canonical address
    0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    RIP: 0010:cake_dequeue_one+0xc9/0x3c0
    Call Trace:
    <TASK>
    cake_reset+0xb1/0x140
    qdisc_reset+0xed/0x6f0
    qdisc_destroy+0x82/0x4c0
    qdisc_put+0x9e/0xb0
    qdisc_create_dflt+0x2c3/0x4a0
    mqprio_init+0xa71/0x1760
    qdisc_create+0x3eb/0x1000
    tc_modify_qdisc+0x408/0x1720
    rtnetlink_rcv_msg+0x38e/0xac0
    netlink_rcv_skb+0x12d/0x3a0
    netlink_unicast+0x4a2/0x740
    netlink_sendmsg+0x826/0xcc0
    sock_sendmsg+0xc5/0x100
    ____sys_sendmsg+0x583/0x690
    ___sys_sendmsg+0xe8/0x160
    __sys_sendmsg+0xbf/0x160
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f89e5122d04
    </TASK>
    
    Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c707a6c7899f143c320d5c3d908d440ad4ac3ca
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Wed Sep 28 09:39:10 2022 +0300

    nvmet: fix workqueue MEM_RECLAIM flushing dependency
    
    [ Upstream commit ddd2b8de9f85b388925e7dc46b3890fc1a0d8d24 ]
    
    The keep alive timer needs to stay on nvmet_wq, and not
    modified to reschedule on the system_wq.
    
    This fixes a warning:
    ------------[ cut here ]------------
    workqueue: WQ_MEM_RECLAIM
    nvmet-wq:nvmet_rdma_release_queue_work [nvmet_rdma] is flushing
    !WQ_MEM_RECLAIM events:nvmet_keep_alive_timer [nvmet]
    WARNING: CPU: 3 PID: 1086 at kernel/workqueue.c:2628
    check_flush_dependency+0x16c/0x1e0
    
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Fixes: 8832cf922151 ("nvmet: use a private workqueue instead of the system workqueue")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 704d5f5d119588d18d125573cfdbef04e1f44f07
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Tue Oct 18 17:33:52 2022 +0200

    nvme-hwmon: kmalloc the NVME SMART log buffer
    
    [ Upstream commit c94b7f9bab22ac504f9153767676e659988575ad ]
    
    Recent commit 52fde2c07da6 ("nvme: set dma alignment to dword") has
    caused a regression on our platform.
    
    It turned out that the nvme_get_log() method invocation caused the
    nvme_hwmon_data structure instance corruption.  In particular the
    nvme_hwmon_data.ctrl pointer was overwritten either with zeros or with
    garbage.  After some research we discovered that the problem happened
    even before the actual NVME DMA execution, but during the buffer mapping.
    Since our platform is DMA-noncoherent, the mapping implied the cache-line
    invalidations or write-backs depending on the DMA-direction parameter.
    In case of the NVME SMART log getting the DMA was performed
    from-device-to-memory, thus the cache-invalidation was activated during
    the buffer mapping.  Since the log-buffer isn't cache-line aligned, the
    cache-invalidation caused the neighbour data to be discarded.  The
    neighbouring data turned to be the data surrounding the buffer in the
    framework of the nvme_hwmon_data structure.
    
    In order to fix that we need to make sure that the whole log-buffer is
    defined within the cache-line-aligned memory region so the
    cache-invalidation procedure wouldn't involve the adjacent data. One of
    the option to guarantee that is to kmalloc the DMA-buffer [1]. Seeing the
    rest of the NVME core driver prefer that method it has been chosen to fix
    this problem too.
    
    Note after a deeper researches we found out that the denoted commit wasn't
    a root cause of the problem. It just revealed the invalidity by activating
    the DMA-based NVME SMART log getting performed in the framework of the
    NVME hwmon driver. The problem was here since the initial commit of the
    driver.
    
    [1] Documentation/core-api/dma-api-howto.rst
    
    Fixes: 400b6a7b13a3 ("nvme: Add hardware monitoring support")
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dece37b2e032e5241dcabae953ca2da8096f0ec7
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Oct 18 16:55:55 2022 +0200

    nvme-hwmon: consistently ignore errors from nvme_hwmon_init
    
    [ Upstream commit 6b8cf94005187952f794c0c4ed3920a1e8accfa3 ]
    
    An NVMe controller works perfectly fine even when the hwmon
    initialization fails.  Stop returning errors that do not come from a
    controller reset from nvme_hwmon_init to handle this case consistently.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Stable-dep-of: c94b7f9bab22 ("nvme-hwmon: kmalloc the NVME SMART log buffer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47772604cedeb3286310830830dd086d3a860463
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Oct 17 14:12:58 2022 +0200

    netfilter: nf_tables: relax NFTA_SET_ELEM_KEY_END set flags requirements
    
    [ Upstream commit 96df8360dbb435cc69f7c3c8db44bf8b1c24cd7b ]
    
    Otherwise EINVAL is bogusly reported to userspace when deleting a set
    element. NFTA_SET_ELEM_KEY_END does not need to be set in case of:
    
    - insertion: if not present, start key is used as end key.
    - deletion: only start key needs to be specified, end key is ignored.
    
    Hence, relax the sanity check.
    
    Fixes: 88cccd908d51 ("netfilter: nf_tables: NFTA_SET_ELEM_KEY_END requires concat and interval flags")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de16491c13a74f194229fd835a7fa3db1bf7240f
Author: Guillaume Nault <gnault@redhat.com>
Date:   Thu Oct 13 16:37:47 2022 +0200

    netfilter: rpfilter/fib: Set ->flowic_uid correctly for user namespaces.
    
    [ Upstream commit 1fcc064b305a1aadeff0d4bff961094d27660acd ]
    
    Currently netfilter's rpfilter and fib modules implicitely initialise
    ->flowic_uid with 0. This is normally the root UID. However, this isn't
    the case in user namespaces, where user ID 0 is mapped to a different
    kernel UID. By initialising ->flowic_uid with sock_net_uid(), we get
    the root UID of the user namespace, thus keeping the same behaviour
    whether or not we're running in a user namepspace.
    
    Note, this is similar to commit 8bcfd0925ef1 ("ipv4: add missing
    initialization for flowi4_uid"), which fixed the rp_filter sysctl.
    
    Fixes: 622ec2c9d524 ("net: core: add UID to flows, rules, and routes")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14051ae7d470cd93069d1cfa8ca21d24d527c97b
Author: Phil Sutter <phil@nwl.cc>
Date:   Wed Oct 5 18:07:05 2022 +0200

    netfilter: rpfilter/fib: Populate flowic_l3mdev field
    
    [ Upstream commit acc641ab95b66b813c1ce856c377a2bbe71e7f52 ]
    
    Use the introduced field for correct operation with VRF devices instead
    of conditionally overwriting flowic_oif. This is a partial revert of
    commit b575b24b8eee3 ("netfilter: Fix rpfilter dropping vrf packets by
    mistake"), implementing a simpler solution.
    
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Stable-dep-of: 1fcc064b305a ("netfilter: rpfilter/fib: Set ->flowic_uid correctly for user namespaces.")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e0bf291c15b8639b15bca423db000b1219ae4bd
Author: Brett Creeley <brett@pensando.io>
Date:   Mon Oct 17 16:31:23 2022 -0700

    ionic: catch NULL pointer issue on reconfig
    
    [ Upstream commit aa1d7e1267c12e07d979aa34c613716a89029db2 ]
    
    It's possible that the driver will dereference a qcq that doesn't exist
    when calling ionic_reconfigure_queues(), which causes a page fault BUG.
    
    If a reduction in the number of queues is followed by a different
    reconfig such as changing the ring size, the driver can hit a NULL
    pointer when trying to clean up non-existent queues.
    
    Fix this by checking to make sure both the qcqs array and qcq entry
    exists bofore trying to use and free the entry.
    
    Fixes: 101b40a0171f ("ionic: change queue count with no reset")
    Signed-off-by: Brett Creeley <brett@pensando.io>
    Signed-off-by: Shannon Nelson <snelson@pensando.io>
    Link: https://lore.kernel.org/r/20221017233123.15869-1-snelson@pensando.io
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c46f2e0fcd1ecfc6046e5cf785ff89f0572f94e4
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 17 16:59:28 2022 +0000

    net: hsr: avoid possible NULL deref in skb_clone()
    
    [ Upstream commit d8b57135fd9ffe9a5b445350a686442a531c5339 ]
    
    syzbot got a crash [1] in skb_clone(), caused by a bug
    in hsr_get_untagged_frame().
    
    When/if create_stripped_skb_hsr() returns NULL, we must
    not attempt to call skb_clone().
    
    While we are at it, replace a WARN_ONCE() by netdev_warn_once().
    
    [1]
    general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
    CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
    RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641
    Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00
    RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207
    
    RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000
    RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000
    RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140
    R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640
    R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620
    FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164
    hsr_forward_do net/hsr/hsr_forward.c:461 [inline]
    hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623
    hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69
    __netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379
    __netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483
    __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599
    netif_receive_skb_internal net/core/dev.c:5685 [inline]
    netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744
    tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544
    tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995
    tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025
    call_write_iter include/linux/fs.h:2187 [inline]
    new_sync_write fs/read_write.c:491 [inline]
    vfs_write+0x9e9/0xdd0 fs/read_write.c:584
    ksys_write+0x127/0x250 fs/read_write.c:637
    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+0x63/0xcd
    
    Fixes: f266a683a480 ("net/hsr: Better frame dispatch")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20221017165928.2150130-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be083d97031712a2e16fd915ddb8fe1a6cb1fbc5
Author: Vikas Gupta <vikas.gupta@broadcom.com>
Date:   Mon Oct 17 11:32:22 2022 -0400

    bnxt_en: fix memory leak in bnxt_nvm_test()
    
    [ Upstream commit ba077d683d45190afc993c1ce45bcdbfda741a40 ]
    
    Free the kzalloc'ed buffer before returning in the success path.
    
    Fixes: 5b6ff128fdf6 ("bnxt_en: implement callbacks for devlink selftests")
    Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/1666020742-25834-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 84ea92c6297031235db125c653b0500092785446
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Oct 13 11:25:23 2022 -0700

    drm/amd/display: Increase frame size limit for display_mode_vba_util_32.o
    
    [ Upstream commit 8a70b2d89ea3f2dc1449f0634ca6befb41472f24 ]
    
    Building 32-bit images may fail with the following error.
    
    drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
            In function ‘dml32_UseMinimumDCFCLK’:
    drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:3142:1:
            error: the frame size of 1096 bytes is larger than 1024 bytes
    
    This is seen when building i386:allmodconfig with any of the following
    compilers.
    
            gcc (Debian 12.2.0-3) 12.2.0
            gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
    
    The problem is not seen if the compiler supports GCC_PLUGIN_LATENT_ENTROPY
    because in that case CONFIG_FRAME_WARN is already set to 2048 even for
    32-bit builds.
    
    dml32_UseMinimumDCFCLK() was introduced with commit dda4fb85e433
    ("drm/amd/display: DML changes for DCN32/321"). It declares a large
    number of local variables. Increase the frame size for the affected
    file to 2048, similar to other files in the same directory, to enable
    32-bit build tests with affected compilers.
    
    Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321")
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Reported-by: Łukasz Bartosik <ukaszb@google.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9b4cfa74592f8d0d4c7470fe7ef59553fa14f1f
Author: Genjian Zhang <zhanggenjian@kylinos.cn>
Date:   Thu Sep 29 16:20:36 2022 +0800

    dm: remove unnecessary assignment statement in alloc_dev()
    
    [ Upstream commit 99f4f5bcb975527508eb7a5e3e34bdb91d576746 ]
    
    Fixes: 74fe6ba923949 ("dm: convert to blk_alloc_disk/blk_cleanup_disk")
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa5a70bdd5e565c8696fb04dfe18a4e8aff4695d
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue Oct 18 11:49:16 2022 +0800

    cifs: Fix memory leak when build ntlmssp negotiate blob failed
    
    [ Upstream commit 30b2d7f8f13664655480d6af45f60270b3eb6736 ]
    
    There is a memory leak when mount cifs:
      unreferenced object 0xffff888166059600 (size 448):
        comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s)
        hex dump (first 32 bytes):
          fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00  .SMB@...........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<0000000060609a61>] mempool_alloc+0xe1/0x260
          [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60
          [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460
          [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0
          [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480
          [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410
          [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0
          [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0
          [<000000006cbc43d9>] mount_get_conns+0x7a/0x730
          [<000000005922d816>] cifs_mount+0x103/0xd10
          [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90
          [<0000000078034979>] smb3_get_tree+0x1d5/0x300
          [<000000004371f980>] vfs_get_tree+0x41/0xf0
          [<00000000b670d8a7>] path_mount+0x9b3/0xdd0
          [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0
          [<000000009404c3b9>] do_syscall_64+0x35/0x80
    
    When build ntlmssp negotiate blob failed, the session setup request
    should be freed.
    
    Fixes: 49bd49f983b5 ("cifs: send workstation name during ntlmssp session setup")
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db2a8b6c17e128d91f35d836c569f4a6bda4471b
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Mon Oct 17 22:45:24 2022 +0800

    cifs: Fix xid leak in cifs_ses_add_channel()
    
    [ Upstream commit e909d054bdea75ef1ec48c18c5936affdaecbb2c ]
    
    Before return, should free the xid, otherwise, the
    xid will be leaked.
    
    Fixes: d70e9fa55884 ("cifs: try opening channels after mounting")
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8c9b4a963fec5d0e37e3e8522bb19b0c28e1a73
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Mon Oct 17 22:45:23 2022 +0800

    cifs: Fix xid leak in cifs_flock()
    
    [ Upstream commit 575e079c782b9862ec2626403922d041a42e6ed6 ]
    
    If not flock, before return -ENOLCK, should free the xid,
    otherwise, the xid will be leaked.
    
    Fixes: d0677992d2af ("cifs: add support for flock")
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc283313d1ca378d787cb55c1e580dc3de852680
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Mon Oct 17 22:45:22 2022 +0800

    cifs: Fix xid leak in cifs_copy_file_range()
    
    [ Upstream commit 9a97df404a402fe1174d2d1119f87ff2a0ca2fe9 ]
    
    If the file is used by swap, before return -EOPNOTSUPP, should
    free the xid, otherwise, the xid will be leaked.
    
    Fixes: 4e8aea30f775 ("smb3: enable swap on SMB3 mounts")
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92aa09c86ef297976a3c27c6574c0839418dc2c4
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Mon Oct 17 22:45:21 2022 +0800

    cifs: Fix xid leak in cifs_create()
    
    [ Upstream commit fee0fb1f15054bb6a0ede452acb42da5bef4d587 ]
    
    If the cifs already shutdown, we should free the xid before return,
    otherwise, the xid will be leaked.
    
    Fixes: 087f757b0129 ("cifs: add shutdown support")
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22a68c3b9362eaac7b035eba09e95e6b3f7a912c
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Mon Oct 17 16:03:31 2022 +0800

    ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed
    
    [ Upstream commit 1ca695207ed2271ecbf8ee6c641970f621c157cc ]
    
    If the initialization fails in calling addrconf_init_net(), devconf_all is
    the pointer that has been released. Then ip6mr_sk_done() is called to
    release the net, accessing devconf->mc_forwarding directly causes invalid
    pointer access.
    
    The process is as follows:
    setup_net()
            ops_init()
                    addrconf_init_net()
                    all = kmemdup(...)           ---> alloc "all"
                    ...
                    net->ipv6.devconf_all = all;
                    __addrconf_sysctl_register() ---> failed
                    ...
                    kfree(all);                  ---> ipv6.devconf_all invalid
                    ...
            ops_exit_list()
                    ...
                    ip6mr_sk_done()
                            devconf = net->ipv6.devconf_all;
                            //devconf is invalid pointer
                            if (!devconf || !atomic_read(&devconf->mc_forwarding))
    
    The following is the Call Trace information:
    BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0
    Read of size 4 at addr ffff888075508e88 by task ip/14554
    Call Trace:
    <TASK>
    dump_stack_lvl+0x8e/0xd1
    print_report+0x155/0x454
    kasan_report+0xba/0x1f0
    kasan_check_range+0x35/0x1b0
    ip6mr_sk_done+0x112/0x3a0
    rawv6_close+0x48/0x70
    inet_release+0x109/0x230
    inet6_release+0x4c/0x70
    sock_release+0x87/0x1b0
    igmp6_net_exit+0x6b/0x170
    ops_exit_list+0xb0/0x170
    setup_net+0x7ac/0xbd0
    copy_net_ns+0x2e6/0x6b0
    create_new_namespaces+0x382/0xa50
    unshare_nsproxy_namespaces+0xa6/0x1c0
    ksys_unshare+0x3a4/0x7e0
    __x64_sys_unshare+0x2d/0x40
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f7963322547
    
    </TASK>
    Allocated by task 14554:
    kasan_save_stack+0x1e/0x40
    kasan_set_track+0x21/0x30
    __kasan_kmalloc+0xa1/0xb0
    __kmalloc_node_track_caller+0x4a/0xb0
    kmemdup+0x28/0x60
    addrconf_init_net+0x1be/0x840
    ops_init+0xa5/0x410
    setup_net+0x5aa/0xbd0
    copy_net_ns+0x2e6/0x6b0
    create_new_namespaces+0x382/0xa50
    unshare_nsproxy_namespaces+0xa6/0x1c0
    ksys_unshare+0x3a4/0x7e0
    __x64_sys_unshare+0x2d/0x40
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Freed by task 14554:
    kasan_save_stack+0x1e/0x40
    kasan_set_track+0x21/0x30
    kasan_save_free_info+0x2a/0x40
    ____kasan_slab_free+0x155/0x1b0
    slab_free_freelist_hook+0x11b/0x220
    __kmem_cache_free+0xa4/0x360
    addrconf_init_net+0x623/0x840
    ops_init+0xa5/0x410
    setup_net+0x5aa/0xbd0
    copy_net_ns+0x2e6/0x6b0
    create_new_namespaces+0x382/0xa50
    unshare_nsproxy_namespaces+0xa6/0x1c0
    ksys_unshare+0x3a4/0x7e0
    __x64_sys_unshare+0x2d/0x40
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Fixes: 7d9b1b578d67 ("ip6mr: fix use-after-free in ip6mr_sk_done()")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20221017080331.16878-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fb3a672317fba2a54f1bc8a6401235c6f11f883
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Fri Oct 14 11:26:25 2022 -0700

    udp: Update reuse->has_conns under reuseport_lock.
    
    [ Upstream commit 69421bf98482d089e50799f45e48b25ce4a8d154 ]
    
    When we call connect() for a UDP socket in a reuseport group, we have
    to update sk->sk_reuseport_cb->has_conns to 1.  Otherwise, the kernel
    could select a unconnected socket wrongly for packets sent to the
    connected socket.
    
    However, the current way to set has_conns is illegal and possible to
    trigger that problem.  reuseport_has_conns() changes has_conns under
    rcu_read_lock(), which upgrades the RCU reader to the updater.  Then,
    it must do the update under the updater's lock, reuseport_lock, but
    it doesn't for now.
    
    For this reason, there is a race below where we fail to set has_conns
    resulting in the wrong socket selection.  To avoid the race, let's split
    the reader and updater with proper locking.
    
     cpu1                               cpu2
    +----+                             +----+
    
    __ip[46]_datagram_connect()        reuseport_grow()
    .                                  .
    |- reuseport_has_conns(sk, true)   |- more_reuse = __reuseport_alloc(more_socks_size)
    |  .                               |
    |  |- rcu_read_lock()
    |  |- reuse = rcu_dereference(sk->sk_reuseport_cb)
    |  |
    |  |                               |  /* reuse->has_conns == 0 here */
    |  |                               |- more_reuse->has_conns = reuse->has_conns
    |  |- reuse->has_conns = 1         |  /* more_reuse->has_conns SHOULD BE 1 HERE */
    |  |                               |
    |  |                               |- rcu_assign_pointer(reuse->socks[i]->sk_reuseport_cb,
    |  |                               |                     more_reuse)
    |  `- rcu_read_unlock()            `- kfree_rcu(reuse, rcu)
    |
    |- sk->sk_state = TCP_ESTABLISHED
    
    Note the likely(reuse) in reuseport_has_conns_set() is always true,
    but we put the test there for ease of review.  [0]
    
    For the record, usually, sk_reuseport_cb is changed under lock_sock().
    The only exception is reuseport_grow() & TCP reqsk migration case.
    
      1) shutdown() TCP listener, which is moved into the latter part of
         reuse->socks[] to migrate reqsk.
    
      2) New listen() overflows reuse->socks[] and call reuseport_grow().
    
      3) reuse->max_socks overflows u16 with the new listener.
    
      4) reuseport_grow() pops the old shutdown()ed listener from the array
         and update its sk->sk_reuseport_cb as NULL without lock_sock().
    
    shutdown()ed TCP sk->sk_reuseport_cb can be changed without lock_sock(),
    but, reuseport_has_conns_set() is called only for UDP under lock_sock(),
    so likely(reuse) never be false in reuseport_has_conns_set().
    
    [0]: https://lore.kernel.org/netdev/CANn89iLja=eQHbsM_Ta2sQF0tOGU8vAGrh_izRuuHjuO1ouUag@mail.gmail.com/
    
    Fixes: acdcecc61285 ("udp: correct reuseport selection with connected sockets")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20221014182625.89913-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ea1f195f51c2bb5915ccfb2b2885ca81ce9262b
Author: Rafael Mendonca <rafaelmendsr@gmail.com>
Date:   Fri Sep 16 00:59:07 2022 -0300

    scsi: lpfc: Fix memory leak in lpfc_create_port()
    
    [ Upstream commit dc8e483f684a24cc06e1d5fa958b54db58855093 ]
    
    Commit 5e633302ace1 ("scsi: lpfc: vmid: Add support for VMID in mailbox
    command") introduced allocations for the VMID resources in
    lpfc_create_port() after the call to scsi_host_alloc(). Upon failure on the
    VMID allocations, the new code would branch to the 'out' label, which
    returns NULL without unwinding anything, thus skipping the call to
    scsi_host_put().
    
    Fix the problem by creating a separate label 'out_free_vmid' to unwind the
    VMID resources and make the 'out_put_shost' label call only
    scsi_host_put(), as was done before the introduction of allocations for
    VMID.
    
    Fixes: 5e633302ace1 ("scsi: lpfc: vmid: Add support for VMID in mailbox command")
    Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com>
    Link: https://lore.kernel.org/r/20220916035908.712799-1-rafaelmendsr@gmail.com
    Reviewed-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e491fed1d12ec5dfb59722b3615da688e63c2690
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 17 11:51:56 2022 +0800

    net: ethernet: mtk_eth_wed: add missing of_node_put()
    
    [ Upstream commit e0bb4659e235770e6f53b3692e958591f49448f5 ]
    
    The device_node pointer returned by of_parse_phandle() with refcount
    incremented, when finish using it, the refcount need be decreased.
    
    Fixes: 804775dfc288 ("net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED)")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit faba5b9e065632babdee96d99bfcbfe1ce25c4ef
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 17 11:51:55 2022 +0800

    net: ethernet: mtk_eth_wed: add missing put_device() in mtk_wed_add_hw()
    
    [ Upstream commit 9d4f20a476ca57e4c9246eb1fa2a61bea2354720 ]
    
    After calling get_device() in mtk_wed_add_hw(), in error path, put_device()
    needs be called.
    
    Fixes: 804775dfc288 ("net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED)")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96bde7c4f5683d8c1c809ddb781ef3fdec9b7215
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 17 11:51:54 2022 +0800

    net: ethernet: mtk_eth_soc: fix possible memory leak in mtk_probe()
    
    [ Upstream commit b3d0d98179d62f9d55635a600679c4fa362baf8d ]
    
    If mtk_wed_add_hw() has been called, mtk_wed_exit() needs be called
    in error path or removing module to free the memory allocated in
    mtk_wed_add_hw().
    
    Fixes: 804775dfc288 ("net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED)")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eedddf8c1c4d3bb3469dc20ad09650116754284a
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Oct 16 17:24:10 2022 -0600

    io_uring/rw: remove leftover debug statement
    
    [ Upstream commit 5c61795ea97c170347c5c4af0c159bd877b8af71 ]
    
    This debug statement was never meant to go into the upstream release,
    kill it off before it ends up in a release. It was just part of the
    testing for the initial version of the patch.
    
    Fixes: 2ec33a6c3cca ("io_uring/rw: ensure kiocb_end_write() is always called")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a440e6d04431e774dc084abe88c106e2a474c1a
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Oct 11 22:22:53 2022 +0800

    blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()
    
    [ Upstream commit 76dd298094f484c6250ebd076fa53287477b2328 ]
    
    Our syzkaller report a null pointer dereference, root cause is
    following:
    
    __blk_mq_alloc_map_and_rqs
     set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs
      blk_mq_alloc_map_and_rqs
       blk_mq_alloc_rqs
        // failed due to oom
        alloc_pages_node
        // set->tags[hctx_idx] is still NULL
        blk_mq_free_rqs
         drv_tags = set->tags[hctx_idx];
         // null pointer dereference is triggered
         blk_mq_clear_rq_mapping(drv_tags, ...)
    
    This is because commit 63064be150e4 ("blk-mq:
    Add blk_mq_alloc_map_and_rqs()") merged the two steps:
    
    1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()
    2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])
    
    into one step:
    
    set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()
    
    Since tags is not initialized yet in this case, fix the problem by
    checking if tags is NULL pointer in blk_mq_clear_rq_mapping().
    
    Fixes: 63064be150e4 ("blk-mq: Add blk_mq_alloc_map_and_rqs()")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Link: https://lore.kernel.org/r/20221011142253.4015966-1-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82fa018dc82858a39b6aa77943aaaef38ac652e2
Author: Gao Xiang <xiang@kernel.org>
Date:   Wed Oct 12 12:50:56 2022 +0800

    erofs: shouldn't churn the mapping page for duplicated copies
    
    [ Upstream commit 63bbb85658ea43dd35dbfde6d4150b47c407fc87 ]
    
    If other duplicated copies exist in one decompression shot, should
    leave the old page as is rather than replace it with the new duplicated
    one.  Otherwise, the following cold path to deal with duplicated copies
    will use the invalid bvec.  It impacts compressed data deduplication.
    
    Also, shift the onlinepage EIO bit to avoid touching the signed bit.
    
    Fixes: 267f2492c8f7 ("erofs: introduce multi-reference pclusters (fully-referenced)")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20221012045056.13421-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 693ddd6ffc05b228ea1638f9d757c5d3541f9446
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Oct 15 21:24:41 2022 +0000

    skmsg: pass gfp argument to alloc_sk_msg()
    
    [ Upstream commit 2d1f274b95c6e4ba6a813b3b8e7a1a38d54a0a08 ]
    
    syzbot found that alloc_sk_msg() could be called from a
    non sleepable context. sk_psock_verdict_recv() uses
    rcu_read_lock() protection.
    
    We need the callers to pass a gfp_t argument to avoid issues.
    
    syzbot report was:
    
    BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
    in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414
    preempt_count: 0, expected: 0
    RCU nest depth: 1, expected: 0
    INFO: lockdep is turned off.
    CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
    Call Trace:
    <TASK>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
    __might_resched+0x538/0x6a0 kernel/sched/core.c:9877
    might_alloc include/linux/sched/mm.h:274 [inline]
    slab_pre_alloc_hook mm/slab.h:700 [inline]
    slab_alloc_node mm/slub.c:3162 [inline]
    slab_alloc mm/slub.c:3256 [inline]
    kmem_cache_alloc_trace+0x59/0x310 mm/slub.c:3287
    kmalloc include/linux/slab.h:600 [inline]
    kzalloc include/linux/slab.h:733 [inline]
    alloc_sk_msg net/core/skmsg.c:507 [inline]
    sk_psock_skb_ingress_self+0x5c/0x330 net/core/skmsg.c:600
    sk_psock_verdict_apply+0x395/0x440 net/core/skmsg.c:1014
    sk_psock_verdict_recv+0x34d/0x560 net/core/skmsg.c:1201
    tcp_read_skb+0x4a1/0x790 net/ipv4/tcp.c:1770
    tcp_rcv_established+0x129d/0x1a10 net/ipv4/tcp_input.c:5971
    tcp_v4_do_rcv+0x479/0xac0 net/ipv4/tcp_ipv4.c:1681
    sk_backlog_rcv include/net/sock.h:1109 [inline]
    __release_sock+0x1d8/0x4c0 net/core/sock.c:2906
    release_sock+0x5d/0x1c0 net/core/sock.c:3462
    tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1483
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg net/socket.c:734 [inline]
    __sys_sendto+0x46d/0x5f0 net/socket.c:2117
    __do_sys_sendto net/socket.c:2129 [inline]
    __se_sys_sendto net/socket.c:2125 [inline]
    __x64_sys_sendto+0xda/0xf0 net/socket.c:2125
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: 43312915b5ba ("skmsg: Get rid of unncessary memset()")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Cong Wang <cong.wang@bytedance.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d774f41d74e4a837f60dab360e68d72736e75761
Author: Shenwei Wang <shenwei.wang@nxp.com>
Date:   Fri Oct 14 09:47:29 2022 -0500

    net: stmmac: Enable mac_managed_pm phylink config
    
    [ Upstream commit f151c147b3afcf92dedff53f5f0e965414e4fd2c ]
    
    Enable the mac_managed_pm configuration in the phylink_config
    structure to avoid the kernel warning during system resume.
    
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
    Acked-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 ac4a26bc8e6ed34e1531555df8c5710efd71926a
Author: Shenwei Wang <shenwei.wang@nxp.com>
Date:   Fri Oct 14 09:47:28 2022 -0500

    net: phylink: add mac_managed_pm in phylink_config structure
    
    [ Upstream commit 96de900ae78e7dbedc937fd91bafe2934579c65a ]
    
    The recent commit
    
    'commit 744d23c71af3 ("net: phy: Warn about incorrect
    mdio_bus_phy_resume() state")'
    
    requires the MAC driver explicitly tell the phy driver who is
    managing the PM, otherwise you will see warning during resume
    stage.
    
    Add a boolean property in the phylink_config structure so that
    the MAC driver can use it to tell the PHY driver if it wants to
    manage the PM.
    
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 294a8e9a3cecbf6e6faf6b37d031a0ded5671403
Author: Dan Carpenter <error27@gmail.com>
Date:   Fri Oct 14 12:34:36 2022 +0300

    net/smc: Fix an error code in smc_lgr_create()
    
    [ Upstream commit bdee15e8c58b450ad736a2b62ef8c7a12548b704 ]
    
    If smc_wr_alloc_lgr_mem() fails then return an error code.  Don't return
    success.
    
    Fixes: 8799e310fb3f ("net/smc: add v2 support to the work request layer")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1d403180d14b7e441e89e491c9109c1f406977f
Author: Harini Katakam <harini.katakam@amd.com>
Date:   Fri Oct 14 12:17:35 2022 +0530

    net: phy: dp83867: Extend RX strap quirk for SGMII mode
    
    [ Upstream commit 0c9efbd5c50c64ead434960a404c9c9a097b0403 ]
    
    When RX strap in HW is not set to MODE 3 or 4, bit 7 and 8 in CF4
    register should be set. The former is already handled in
    dp83867_config_init; add the latter in SGMII specific initialization.
    
    Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy")
    Signed-off-by: Harini Katakam <harini.katakam@amd.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 255ff20b970d6a3434e5467f7b5c0c6f7a7e60c7
Author: Xiaobo Liu <cppcoffee@gmail.com>
Date:   Fri Oct 14 10:05:40 2022 +0800

    net/atm: fix proc_mpc_write incorrect return value
    
    [ Upstream commit d8bde3bf7f82dac5fc68a62c2816793a12cafa2a ]
    
    Then the input contains '\0' or '\n', proc_mpc_write has read them,
    so the return value needs +1.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd66e3004ddc56e3da6ee9d422f8d08c9ac2e8c8
Author: Jonathan Cooper <jonathan.s.cooper@amd.com>
Date:   Thu Oct 13 10:55:53 2022 +0100

    sfc: Change VF mac via PF as first preference if available.
    
    [ Upstream commit a8aed7b35becfd21f22a77c7014029ea837b018f ]
    
    Changing a VF's mac address through the VF (rather than via the PF)
    fails with EPERM because the latter part of efx_ef10_set_mac_address
    attempts to change the vport mac address list as the VF.
    Even with this fixed it still fails with EBUSY because the vadaptor
    is still assigned on the VF - the vadaptor reassignment must be within
    a section where the VF has torn down its state.
    
    A major reason this has broken is because we have two functions that
    ostensibly do the same thing - have a PF and VF cooperate to change a
    VF mac address. Rather than do this, if we are changing the mac of a VF
    that has a link to the PF in the same VM then simply call
    sriov_set_vf_mac instead, which is a proven working function that does
    that.
    
    If there is no PF available, or that fails non-fatally, then attempt to
    change the VF's mac address as we would a PF, without updating the PF's
    data.
    
    Test case:
    Create a VF:
      echo 1 > /sys/class/net/<if>/device/sriov_numvfs
    Set the mac address of the VF directly:
      ip link set <vf> addr 00:11:22:33:44:55
    Set the MAC address of the VF via the PF:
      ip link set <pf> vf 0 mac 00:11:22:33:44:66
    Without this patch the last command will fail with ENOENT.
    
    Signed-off-by: Jonathan Cooper <jonathan.s.cooper@amd.com>
    Reported-by: Íñigo Huguet <ihuguet@redhat.com>
    Fixes: 910c8789a777 ("set the MAC address using MC_CMD_VADAPTOR_SET_MAC")
    Acked-by: Edward Cree <ecree.xilinx@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90433e5815b81465f711c43d2bd1945841eb3d60
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Sun Oct 9 20:27:47 2022 +0200

    HID: magicmouse: Do not set BTN_MOUSE on double report
    
    [ Upstream commit bb5f0c855dcfc893ae5ed90e4c646bde9e4498bf ]
    
    Under certain conditions the Magic Trackpad can group 2 reports in a
    single packet. The packet is split and the raw event function is
    invoked recursively for each part.
    
    However, after processing each part, the BTN_MOUSE status is updated,
    sending multiple click events. [1]
    
    Return after processing double reports to avoid this issue.
    
    Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/811  # [1]
    Fixes: a462230e16ac ("HID: magicmouse: enable Magic Trackpad support")
    Reported-by: Nulo <git@nulo.in>
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Link: https://lore.kernel.org/r/20221009182747.90730-1-jose.exposito89@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2277d7cbdf47531b2c3cd01ba15255fa955aab35
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Oct 12 15:55:20 2022 -0700

    tls: strp: make sure the TCP skbs do not have overlapping data
    
    [ Upstream commit 0d87bbd39d7fd1135ab9eca672d760470f6508e8 ]
    
    TLS tries to get away with using the TCP input queue directly.
    This does not work if there is duplicated data (multiple skbs
    holding bytes for the same seq number range due to retransmits).
    Check for this condition and fall back to copy mode, it should
    be rare.
    
    Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f499596dfa3db9b3172645b6de9e1096a669c95
Author: Jan Sokolowski <jan.sokolowski@intel.com>
Date:   Wed Oct 12 13:54:40 2022 -0700

    i40e: Fix DMA mappings leak
    
    [ Upstream commit aae425efdfd1b1d8452260a3cb49344ebf20b1f5 ]
    
    During reallocation of RX buffers, new DMA mappings are created for
    those buffers.
    
    steps for reproduction:
    while :
    do
    for ((i=0; i<=8160; i=i+32))
    do
    ethtool -G enp130s0f0 rx $i tx $i
    sleep 0.5
    ethtool -g enp130s0f0
    done
    done
    
    This resulted in crash:
    i40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536
    Driver BUG
    WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50
    Call Trace:
    i40e_free_rx_resources+0x70/0x80 [i40e]
    i40e_set_ringparam+0x27c/0x800 [i40e]
    ethnl_set_rings+0x1b2/0x290
    genl_family_rcv_msg_doit.isra.15+0x10f/0x150
    genl_family_rcv_msg+0xb3/0x160
    ? rings_fill_reply+0x1a0/0x1a0
    genl_rcv_msg+0x47/0x90
    ? genl_family_rcv_msg+0x160/0x160
    netlink_rcv_skb+0x4c/0x120
    genl_rcv+0x24/0x40
    netlink_unicast+0x196/0x230
    netlink_sendmsg+0x204/0x3d0
    sock_sendmsg+0x4c/0x50
    __sys_sendto+0xee/0x160
    ? handle_mm_fault+0xbe/0x1e0
    ? syscall_trace_enter+0x1d3/0x2c0
    __x64_sys_sendto+0x24/0x30
    do_syscall_64+0x5b/0x1a0
    entry_SYSCALL_64_after_hwframe+0x65/0xca
    RIP: 0033:0x7f5eac8b035b
    Missing register, driver bug
    WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140
    Call Trace:
    xdp_rxq_info_unreg+0x1e/0x50
    i40e_free_rx_resources+0x70/0x80 [i40e]
    i40e_set_ringparam+0x27c/0x800 [i40e]
    ethnl_set_rings+0x1b2/0x290
    genl_family_rcv_msg_doit.isra.15+0x10f/0x150
    genl_family_rcv_msg+0xb3/0x160
    ? rings_fill_reply+0x1a0/0x1a0
    genl_rcv_msg+0x47/0x90
    ? genl_family_rcv_msg+0x160/0x160
    netlink_rcv_skb+0x4c/0x120
    genl_rcv+0x24/0x40
    netlink_unicast+0x196/0x230
    netlink_sendmsg+0x204/0x3d0
    sock_sendmsg+0x4c/0x50
    __sys_sendto+0xee/0x160
    ? handle_mm_fault+0xbe/0x1e0
    ? syscall_trace_enter+0x1d3/0x2c0
    __x64_sys_sendto+0x24/0x30
    do_syscall_64+0x5b/0x1a0
    entry_SYSCALL_64_after_hwframe+0x65/0xca
    RIP: 0033:0x7f5eac8b035b
    
    This was caused because of new buffers with different RX ring count should
    substitute older ones, but those buffers were freed in
    i40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi,
    thus kfree on rx_bi caused leak of already mapped DMA.
    
    Fix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally
    reallocate back to rx_bi when BPF program unloads.
    
    If BPF program is loaded/unloaded and XSK pools are created, reallocate
    RX queues accordingly in XSP_SETUP_XSK_POOL handler.
    
    Fixes: be1222b585fd ("i40e: Separate kernel allocated rx_bi rings from AF_XDP rings")
    Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Chandan <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24dc1d70fe32e4b580da70ab24a4862e2e73d034
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Wed Oct 12 19:18:37 2022 +0200

    net: dsa: qca8k: fix ethtool autocast mib for big-endian systems
    
    [ Upstream commit 0d4636f7d72df3179b20a2d32b647881917a5e2a ]
    
    The switch sends autocast mib in little-endian. This is problematic for
    big-endian system as the values needs to be converted.
    
    Fix this by converting each mib value to cpu byte order.
    
    Fixes: 5c957c7ca78c ("net: dsa: qca8k: add support for mib autocast in Ethernet packet")
    Tested-by: Pawel Dembicki <paweldembicki@gmail.com>
    Tested-by: Lech Perczak <lech.perczak@gmail.com>
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ee5269a50707c6473f6ca75b786400ca05da3b3
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Wed Oct 12 19:18:36 2022 +0200

    net: dsa: qca8k: fix inband mgmt for big-endian systems
    
    [ Upstream commit a2550d3ce53c68f54042bc5e468c4d07491ffe0e ]
    
    The header and the data of the skb for the inband mgmt requires
    to be in little-endian. This is problematic for big-endian system
    as the mgmt header is written in the cpu byte order.
    
    Fix this by converting each value for the mgmt header and data to
    little-endian, and convert to cpu byte order the mgmt header and
    data sent by the switch.
    
    Fixes: 5950c7c0a68c ("net: dsa: qca8k: add support for mgmt read/write in Ethernet packet")
    Tested-by: Pawel Dembicki <paweldembicki@gmail.com>
    Tested-by: Lech Perczak <lech.perczak@gmail.com>
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Reviewed-by: Lech Perczak <lech.perczak@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fef70f978bc289642501d88d2a3f5e841bd31a67
Author: Alexander Potapenko <glider@google.com>
Date:   Wed Oct 12 17:25:14 2022 +0200

    tipc: fix an information leak in tipc_topsrv_kern_subscr
    
    [ Upstream commit 777ecaabd614d47c482a5c9031579e66da13989a ]
    
    Use a 8-byte write to initialize sub.usr_handle in
    tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized
    when issuing setsockopt(..., SOL_TIPC, ...).
    This resulted in an infoleak reported by KMSAN when the packet was
    received:
    
      =====================================================
      BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169
       instrument_copy_to_user ./include/linux/instrumented.h:121
       copyout+0xbc/0x100 lib/iov_iter.c:169
       _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527
       copy_to_iter ./include/linux/uio.h:176
       simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513
       __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419
       skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527
       skb_copy_datagram_msg ./include/linux/skbuff.h:3903
       packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469
       ____sys_recvmsg+0x2c4/0x810 net/socket.c:?
       ___sys_recvmsg+0x217/0x840 net/socket.c:2743
       __sys_recvmsg net/socket.c:2773
       __do_sys_recvmsg net/socket.c:2783
       __se_sys_recvmsg net/socket.c:2780
       __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780
       do_syscall_x64 arch/x86/entry/common.c:50
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120
    
      ...
    
      Uninit was stored to memory at:
       tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156
       tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375
       tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579
       tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190
       tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084
       tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201
       __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252
       __do_sys_setsockopt net/socket.c:2263
       __se_sys_setsockopt net/socket.c:2260
       __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260
       do_syscall_x64 arch/x86/entry/common.c:50
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120
    
      Local variable sub created at:
       tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562
       tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190
    
      Bytes 84-87 of 88 are uninitialized
      Memory access of size 88 starts at ffff88801ed57cd0
      Data copied to user address 0000000020000400
      ...
      =====================================================
    
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Fixes: 026321c6d056a5 ("tipc: rename tipc_server to tipc_topsrv")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e21f28563af691eb669c3e45f8ece5bd8bf19fb
Author: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Date:   Mon Oct 10 15:46:13 2022 +1300

    tipc: Fix recognition of trial period
    
    [ Upstream commit 28be7ca4fcfd69a2d52aaa331adbf9dbe91f9e6e ]
    
    The trial period exists until jiffies is after addr_trial_end. But as
    jiffies will eventually overflow, just using time_after will eventually
    give incorrect results. As the node address is set once the trial period
    ends, this can be used to know that we are not in the trial period.
    
    Fixes: e415577f57f4 ("tipc: correct discovery message handling during address trial period")
    Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01201fc4c48cfb31d2ef8184f1404205bf99fa45
Author: Tony Luck <tony.luck@intel.com>
Date:   Mon Oct 10 13:34:23 2022 -0700

    ACPI: extlog: Handle multiple records
    
    [ Upstream commit f6ec01da40e4139b41179f046044ee7c4f6370dc ]
    
    If there is no user space consumer of extlog_mem trace records, then
    Linux properly handles multiple error records in an ELOG block
    
            extlog_print()
              print_extlog_rcd()
                __print_extlog_rcd()
                  cper_estatus_print()
                    apei_estatus_for_each_section()
    
    But the other code path hard codes looking for a single record to
    output a trace record.
    
    Fix by using the same apei_estatus_for_each_section() iterator
    to step over all records.
    
    Fixes: 2dfb7d51a61d ("trace, RAS: Add eMCA trace event interface")
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f43fc13cf8a21c15681c7e3e308002c633d00df3
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Thu Sep 29 11:21:17 2022 +0200

    drm/vc4: hdmi: Enforce the minimum rate at runtime_resume
    
    [ Upstream commit ae71ab585c819f83aec84f91eb01157a90552ef2 ]
    
    This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock
    rate initialization"), with the code slightly moved around.
    
    It turns out that we can't downright remove that code from the driver,
    since the Pi0-3 and Pi4 are in different cases, and it only works for
    the Pi4.
    
    Indeed, the commit mentioned above was relying on the RaspberryPi
    firmware clocks driver to initialize the rate if it wasn't done by the
    firmware. However, the Pi0-3 are using the clk-bcm2835 clock driver that
    wasn't doing this initialization. We therefore end up with the clock not
    being assigned a rate, and the CPU stalling when trying to access a
    register.
    
    We can't move that initialization in the clk-bcm2835 driver, since the
    HSM clock we depend on is actually part of the HDMI power domain, so any
    rate setup is only valid when the power domain is enabled. Thus, we
    reinstated the minimum rate setup at runtime_suspend, which should
    address both issues.
    
    Link: https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak2et@pengutronix.de/
    Fixes: fd5894fa2413 ("drm/vc4: hdmi: Remove clock rate initialization")
    Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-1-cd22e962296c@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cec069a68487413cfb612739fb36597ed789f1ab
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Fri Sep 2 16:41:11 2022 +0200

    drm/vc4: Add module dependency on hdmi-codec
    
    [ Upstream commit d1c0b7de4dfa5505cf7a1d6220aa72aace4435d0 ]
    
    The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
    order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
    will register a device matching the HDMI codec driver, and then register
    an ASoC card using that codec.
    
    However, if vc4 is compiled as a module, chances are that the hdmi-codec
    driver will be too. In such a case, the module loader will have a very
    narrow window to load the module between the device registration and the
    card registration.
    
    If it fails to load the module in time, the card registration will fail
    with EPROBE_DEFER, and we'll abort the audio initialisation,
    unregistering the HDMI codec device in the process.
    
    The next time the bind callback will be run, it's likely that we end up
    missing that window again, effectively preventing vc4 to probe entirely.
    
    In order to prevent this, we can create a soft dependency of the vc4
    driver on the HDMI codec one so that we're sure the HDMI codec will be
    loaded before the VC4 module is, and thus we'll never end up in the
    previous situation.
    
    Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec")
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220902144111.3424560-1-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 622e9c5bd4ed5bd4318f9c6649405b8d3d4c1a3a
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Oct 11 13:16:52 2022 +0100

    btrfs: fix processing of delayed tree block refs during backref walking
    
    [ Upstream commit 943553ef9b51db303ab2b955c1025261abfdf6fb ]
    
    During backref walking, when processing a delayed reference with a type of
    BTRFS_TREE_BLOCK_REF_KEY, we have two bugs there:
    
    1) We are accessing the delayed references extent_op, and its key, without
       the protection of the delayed ref head's lock;
    
    2) If there's no extent op for the delayed ref head, we end up with an
       uninitialized key in the stack, variable 'tmp_op_key', and then pass
       it to add_indirect_ref(), which adds the reference to the indirect
       refs rb tree.
    
       This is wrong, because indirect references should have a NULL key
       when we don't have access to the key, and in that case they should be
       added to the indirect_missing_keys rb tree and not to the indirect rb
       tree.
    
       This means that if have BTRFS_TREE_BLOCK_REF_KEY delayed ref resulting
       from freeing an extent buffer, therefore with a count of -1, it will
       not cancel out the corresponding reference we have in the extent tree
       (with a count of 1), since both references end up in different rb
       trees.
    
       When using fiemap, where we often need to check if extents are shared
       through shared subtrees resulting from snapshots, it means we can
       incorrectly report an extent as shared when it's no longer shared.
       However this is temporary because after the transaction is committed
       the extent is no longer reported as shared, as running the delayed
       reference results in deleting the tree block reference from the extent
       tree.
    
       Outside the fiemap context, the result is unpredictable, as the key was
       not initialized but it's used when navigating the rb trees to insert
       and search for references (prelim_ref_compare()), and we expect all
       references in the indirect rb tree to have valid keys.
    
    The following reproducer triggers the second bug:
    
       $ cat test.sh
       #!/bin/bash
    
       DEV=/dev/sdj
       MNT=/mnt/sdj
    
       mkfs.btrfs -f $DEV
       mount -o compress $DEV $MNT
    
       # With a compressed 128M file we get a tree height of 2 (level 1 root).
       xfs_io -f -c "pwrite -b 1M 0 128M" $MNT/foo
    
       btrfs subvolume snapshot $MNT $MNT/snap
    
       # Fiemap should output 0x2008 in the flags column.
       # 0x2000 means shared extent
       # 0x8 means encoded extent (because it's compressed)
       echo
       echo "fiemap after snapshot, range [120M, 120M + 128K):"
       xfs_io -c "fiemap -v 120M 128K" $MNT/foo
       echo
    
       # Overwrite one extent and fsync to flush delalloc and COW a new path
       # in the snapshot's tree.
       #
       # After this we have a BTRFS_DROP_DELAYED_REF delayed ref of type
       # BTRFS_TREE_BLOCK_REF_KEY with a count of -1 for every COWed extent
       # buffer in the path.
       #
       # In the extent tree we have inline references of type
       # BTRFS_TREE_BLOCK_REF_KEY, with a count of 1, for the same extent
       # buffers, so they should cancel each other, and the extent buffers in
       # the fs tree should no longer be considered as shared.
       #
       echo "Overwriting file range [120M, 120M + 128K)..."
       xfs_io -c "pwrite -b 128K 120M 128K" $MNT/snap/foo
       xfs_io -c "fsync" $MNT/snap/foo
    
       # Fiemap should output 0x8 in the flags column. The extent in the range
       # [120M, 120M + 128K) is no longer shared, it's now exclusive to the fs
       # tree.
       echo
       echo "fiemap after overwrite range [120M, 120M + 128K):"
       xfs_io -c "fiemap -v 120M 128K" $MNT/foo
       echo
    
       umount $MNT
    
    Running it before this patch:
    
       $ ./test.sh
       (...)
       wrote 134217728/134217728 bytes at offset 0
       128 MiB, 128 ops; 0.1152 sec (1.085 GiB/sec and 1110.5809 ops/sec)
       Create a snapshot of '/mnt/sdj' in '/mnt/sdj/snap'
    
       fiemap after snapshot, range [120M, 120M + 128K):
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [245760..246015]: 34304..34559       256 0x2008
    
       Overwriting file range [120M, 120M + 128K)...
       wrote 131072/131072 bytes at offset 125829120
       128 KiB, 1 ops; 0.0001 sec (683.060 MiB/sec and 5464.4809 ops/sec)
    
       fiemap after overwrite range [120M, 120M + 128K):
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [245760..246015]: 34304..34559       256 0x2008
    
    The extent in the range [120M, 120M + 128K) is still reported as shared
    (0x2000 bit set) after overwriting that range and flushing delalloc, which
    is not correct - an entire path was COWed in the snapshot's tree and the
    extent is now only referenced by the original fs tree.
    
    Running it after this patch:
    
       $ ./test.sh
       (...)
       wrote 134217728/134217728 bytes at offset 0
       128 MiB, 128 ops; 0.1198 sec (1.043 GiB/sec and 1068.2067 ops/sec)
       Create a snapshot of '/mnt/sdj' in '/mnt/sdj/snap'
    
       fiemap after snapshot, range [120M, 120M + 128K):
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [245760..246015]: 34304..34559       256 0x2008
    
       Overwriting file range [120M, 120M + 128K)...
       wrote 131072/131072 bytes at offset 125829120
       128 KiB, 1 ops; 0.0001 sec (694.444 MiB/sec and 5555.5556 ops/sec)
    
       fiemap after overwrite range [120M, 120M + 128K):
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [245760..246015]: 34304..34559       256   0x8
    
    Now the extent is not reported as shared anymore.
    
    So fix this by passing a NULL key pointer to add_indirect_ref() when
    processing a delayed reference for a tree block if there's no extent op
    for our delayed ref head with a defined key. Also access the extent op
    only after locking the delayed ref head's lock.
    
    The reproducer will be converted later to a test case for fstests.
    
    Fixes: 86d5f994425252 ("btrfs: convert prelimary reference tracking to use rbtrees")
    Fixes: a6dbceafb915e8 ("btrfs: Remove unused op_key var from add_delayed_refs")
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 327964ea7da53d73f7d2c4edcbb5a8e467b1cd1d
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Oct 11 13:16:51 2022 +0100

    btrfs: fix processing of delayed data refs during backref walking
    
    [ Upstream commit 4fc7b57228243d09c0d878873bf24fa64a90fa01 ]
    
    When processing delayed data references during backref walking and we are
    using a share context (we are being called through fiemap), whenever we
    find a delayed data reference for an inode different from the one we are
    interested in, then we immediately exit and consider the data extent as
    shared. This is wrong, because:
    
    1) This might be a DROP reference that will cancel out a reference in the
       extent tree;
    
    2) Even if it's an ADD reference, it may be followed by a DROP reference
       that cancels it out.
    
    In either case we should not exit immediately.
    
    Fix this by never exiting when we find a delayed data reference for
    another inode - instead add the reference and if it does not cancel out
    other delayed reference, we will exit early when we call
    extent_is_shared() after processing all delayed references. If we find
    a drop reference, then signal the code that processes references from
    the extent tree (add_inline_refs() and add_keyed_refs()) to not exit
    immediately if it finds there a reference for another inode, since we
    have delayed drop references that may cancel it out. In this later case
    we exit once we don't have references in the rb trees that cancel out
    each other and have two references for different inodes.
    
    Example reproducer for case 1):
    
       $ cat test-1.sh
       #!/bin/bash
    
       DEV=/dev/sdj
       MNT=/mnt/sdj
    
       mkfs.btrfs -f $DEV
       mount $DEV $MNT
    
       xfs_io -f -c "pwrite 0 64K" $MNT/foo
       cp --reflink=always $MNT/foo $MNT/bar
    
       echo
       echo "fiemap after cloning:"
       xfs_io -c "fiemap -v" $MNT/foo
    
       rm -f $MNT/bar
       echo
       echo "fiemap after removing file bar:"
       xfs_io -c "fiemap -v" $MNT/foo
    
       umount $MNT
    
    Running it before this patch, the extent is still listed as shared, it has
    the flag 0x2000 (FIEMAP_EXTENT_SHARED) set:
    
       $ ./test-1.sh
       fiemap after cloning:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128 0x2001
    
       fiemap after removing file bar:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128 0x2001
    
    Example reproducer for case 2):
    
       $ cat test-2.sh
       #!/bin/bash
    
       DEV=/dev/sdj
       MNT=/mnt/sdj
    
       mkfs.btrfs -f $DEV
       mount $DEV $MNT
    
       xfs_io -f -c "pwrite 0 64K" $MNT/foo
       cp --reflink=always $MNT/foo $MNT/bar
    
       # Flush delayed references to the extent tree and commit current
       # transaction.
       sync
    
       echo
       echo "fiemap after cloning:"
       xfs_io -c "fiemap -v" $MNT/foo
    
       rm -f $MNT/bar
       echo
       echo "fiemap after removing file bar:"
       xfs_io -c "fiemap -v" $MNT/foo
    
       umount $MNT
    
    Running it before this patch, the extent is still listed as shared, it has
    the flag 0x2000 (FIEMAP_EXTENT_SHARED) set:
    
       $ ./test-2.sh
       fiemap after cloning:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128 0x2001
    
       fiemap after removing file bar:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128 0x2001
    
    After this patch, after deleting bar in both tests, the extent is not
    reported with the 0x2000 flag anymore, it gets only the flag 0x1
    (which is FIEMAP_EXTENT_LAST):
    
       $ ./test-1.sh
       fiemap after cloning:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128 0x2001
    
       fiemap after removing file bar:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128   0x1
    
       $ ./test-2.sh
       fiemap after cloning:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128 0x2001
    
       fiemap after removing file bar:
       /mnt/sdj/foo:
        EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
          0: [0..127]:        26624..26751       128   0x1
    
    These tests will later be converted to a test case for fstests.
    
    Fixes: dc046b10c8b7d4 ("Btrfs: make fiemap not blow when you have lots of snapshots")
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb5de75933d12185b3a85471a49ce21304de5328
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Oct 18 10:06:45 2022 -0400

    dm bufio: use the acquire memory barrier when testing for B_READING
    
    commit 141b3523e9be6f15577acf4bbc3bc1f82d81d6d1 upstream.
    
    The function test_bit doesn't provide any memory barrier. It may be
    possible that the read requests that follow test_bit(B_READING, &b->state)
    are reordered before the test, reading invalid data that existed before
    B_READING was cleared.
    
    Fix this bug by changing test_bit to test_bit_acquire. This is
    particularly important on arches with weak(er) memory ordering
    (e.g. arm64).
    
    Depends-On: 8238b4579866 ("wait_on_bit: add an acquire memory barrier")
    Depends-On: d6ffe6067a54 ("provide arch_test_bit_acquire for architectures that define test_bit")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9847175b266f12365160e124a207907da3dbe8e
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Thu Oct 20 06:37:49 2022 -0500

    platform/x86/amd: pmc: Read SMU version during suspend on Cezanne systems
    
    commit 0b6e6e149c136677f1cc859d4185b5a2db50ffbf upstream.
    
    commit b0c07116c894 ("platform/x86: amd-pmc: Avoid reading SMU version at
    probe time") adjusted the behavior for amd-pmc to avoid reading the SMU
    version at startup but rather on first use to improve boot time.
    
    However the SMU version is also used to decide whether to place a timer
    based wakeup in the OS_HINT message. If the idlemask hasn't been read
    before this message was sent then the SMU version will not have been
    cached.
    
    Ensure the SMU version has been read before deciding whether or not to
    run this codepath.
    
    Cc: stable@vger.kernel.org # 6.0
    Reported-by: You-Sheng Yang <vicamo.yang@canonical.com>
    Tested-by: Anson Tsao <anson.tsao@amd.com>
    Fixes: b0c07116c894 ("platform/x86: amd-pmc: Avoid reading SMU version at probe time")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20221020113749.6621-2-mario.limonciello@amd.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddc5bdddd1811ddba7310b10ecb5f9536fd146b5
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Oct 14 17:01:47 2022 +0800

    x86/topology: Fix duplicated core ID within a package
    
    commit 71eac7063698b7d7b8fafb1683ac24a034541141 upstream.
    
    Today, core ID is assumed to be unique within each package.
    
    But an AlderLake-N platform adds a Module level between core and package,
    Linux excludes the unknown modules bits from the core ID, resulting in
    duplicate core ID's.
    
    To keep core ID unique within a package, Linux must include all APIC-ID
    bits for known or unknown levels above the core and below the package
    in the core ID.
    
    It is important to understand that core ID's have always come directly
    from the APIC-ID encoding, which comes from the BIOS. Thus there is no
    guarantee that they start at 0, or that they are contiguous.
    As such, naively using them for array indexes can be problematic.
    
    [ dhansen: un-known -> unknown ]
    
    Fixes: 7745f03eb395 ("x86/topology: Add CPUID.1F multi-die/package support")
    Suggested-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Len Brown <len.brown@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20221014090147.1836-5-rui.zhang@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d3ab3660cb1ab7c6f83d2c6dd6ad18d15e413d9
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Oct 14 17:01:46 2022 +0800

    x86/topology: Fix multiple packages shown on a single-package system
    
    commit 2b12a7a126d62bdbd81f4923c21bf6e9a7fbd069 upstream.
    
    CPUID.1F/B does not enumerate Package level explicitly, instead, all the
    APIC-ID bits above the enumerated levels are assumed to be package ID
    bits.
    
    Current code gets package ID by shifting out all the APIC-ID bits that
    Linux supports, rather than shifting out all the APIC-ID bits that
    CPUID.1F enumerates. This introduces problems when CPUID.1F enumerates a
    level that Linux does not support.
    
    For example, on a single package AlderLake-N, there are 2 Ecore Modules
    with 4 atom cores in each module.  Linux does not support the Module
    level and interprets the Module ID bits as package ID and erroneously
    reports a multi module system as a multi-package system.
    
    Fix this by using APIC-ID bits above all the CPUID.1F enumerated levels
    as package ID.
    
    [ dhansen: spelling fix ]
    
    Fixes: 7745f03eb395 ("x86/topology: Add CPUID.1F multi-die/package support")
    Suggested-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Len Brown <len.brown@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20221014090147.1836-4-rui.zhang@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25d44602bfa7342b661b7a10bda4a91ba5ab2a06
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Sep 29 08:20:10 2022 -0700

    x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB
    
    commit 33806e7cb8d50379f55c3e8f335e91e1b359dc7b upstream.
    
    A recent change in LLVM made CONFIG_EFI_STUB unselectable because it no
    longer pretends to support -mabi=ms, breaking the dependency in
    Kconfig. Lack of CONFIG_EFI_STUB can prevent kernels from booting via
    EFI in certain circumstances.
    
    This check was added by
    
      8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
    
    to ensure that __attribute__((ms_abi)) was available, as -mabi=ms is
    not actually used in any cflags.
    
    According to the GCC documentation, this attribute has been supported
    since GCC 4.4.7. The kernel currently requires GCC 5.1 so this check is
    not necessary; even when that change landed in 5.6, the kernel required
    GCC 4.9 so it was unnecessary then as well.
    
    Clang supports __attribute__((ms_abi)) for all versions that are
    supported for building the kernel so no additional check is needed.
    Remove the 'depends on' line altogether to allow CONFIG_EFI_STUB to be
    selected when CONFIG_EFI is enabled, regardless of compiler.
    
    Fixes: 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://github.com/llvm/llvm-project/commit/d1ad006a8f64bdc17f618deffa9e7c91d82c444d
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50b46d4db3f3b8f8c88aa330717ff8c1320096ed
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Tue Jul 26 04:14:55 2022 +0200

    media: venus: Fix NV12 decoder buffer discovery on HFI_VERSION_1XX
    
    commit 7f77fa9f378c528edb38dbf23ff1273c81429d49 upstream.
    
    HFI_VERSION_1XX uses HFI_BUFFER_OUTPUT not HFI_BUFFER_OUTPUT2 for decoder
    buffers.
    
    venus_helper_check_format() places a constraint on an output buffer to be
    of type HFI_BUFFER_OUTPUT2. HFI_1XX uses HFI_BUFFER_OUTPUT though.
    
    Switching to the logic used in venus_helper_get_out_fmts() first checking
    for HFI_BUFFER_OUTPUT and then HFI_BUFFER_OUTPUT2 resolves on HFI_1XX.
    
    db410c before:
    root@linaro-alip:~# v4l2-ctl  -d /dev/video0 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Type: Video Capture Multiplanar
    
            [0]: 'MPG4' (MPEG-4 Part 2 ES, compressed)
            [1]: 'H263' (H.263, compressed)
            [2]: 'H264' (H.264, compressed)
            [3]: 'VP80' (VP8, compressed)
    
    root@linaro-alip:~# v4l2-ctl  -d /dev/video1 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Type: Video Capture Multiplanar
    
    db410c after:
    root@linaro-alip:~# v4l2-ctl  -d /dev/video0 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Type: Video Capture Multiplanar
    
            [0]: 'MPG4' (MPEG-4 Part 2 ES, compressed)
            [1]: 'H263' (H.263, compressed)
            [2]: 'H264' (H.264, compressed)
            [3]: 'VP80' (VP8, compressed)
    
    root@linaro-alip:~# v4l2-ctl  -d /dev/video1 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Type: Video Capture Multiplanar
    
            [0]: 'NV12' (Y/CbCr 4:2:0)
    
    Validated playback with ffplay on db410c with h264 and vp8 decoding.
    
    Fixes: 9593126dae3e ("media: venus: Add a handling of QC08C compressed format")
    Cc: stable@vger.kernel.org  # v5.19
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb5a56fe8a0d939729d1219fad32eebeaa1c3d67
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Tue Jul 26 04:14:54 2022 +0200

    media: venus: dec: Handle the case where find_format fails
    
    commit 06a2da340f762addc5935bf851d95b14d4692db2 upstream.
    
    Debugging the decoder on msm8916 I noticed the vdec probe was crashing if
    the fmt pointer was NULL.
    
    A similar fix from Colin Ian King found by Coverity was implemented for the
    encoder. Implement the same fix on the decoder.
    
    Fixes: 7472c1c69138 ("[media] media: venus: vdec: add video decoder files")
    Cc: stable@vger.kernel.org  # v4.13+
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a22770b6c7e2196ae611c8c40bae0b25584aab21
Author: Sean Young <sean@mess.org>
Date:   Fri Sep 2 12:32:21 2022 +0200

    media: mceusb: set timeout to at least timeout provided
    
    commit 20b794ddce475ed012deb365000527c17b3e93e6 upstream.
    
    By rounding down, the actual timeout can be lower than requested. As a
    result, long spaces just below the requested timeout can be incorrectly
    reported as timeout and truncated.
    
    Fixes: 877f1a7cee3f ("media: rc: mceusb: allow the timeout to be configurable")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 740717b756c17190dc2d2ad4c6de1e63f214e0c9
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Aug 25 20:36:37 2022 +0200

    media: ipu3-imgu: Fix NULL pointer dereference in active selection access
    
    commit b9eb3ab6f30bf32f7326909f17949ccb11bab514 upstream.
    
    What the IMGU driver did was that it first acquired the pointers to active
    and try V4L2 subdev state, and only then figured out which one to use.
    
    The problem with that approach and a later patch (see Fixes: tag) is that
    as sd_state argument to v4l2_subdev_get_try_crop() et al is NULL, there is
    now an attempt to dereference that.
    
    Fix this.
    
    Also rewrap lines a little.
    
    Fixes: 0d346d2a6f54 ("media: v4l2-subdev: add subdev-wide state struct")
    Cc: stable@vger.kernel.org # for v5.14 and later
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc2654a2e8b19f0055851b498d1fcbb1fed43d51
Author: Eric Ren <renzhengeek@gmail.com>
Date:   Sat Oct 15 11:19:28 2022 +0800

    KVM: arm64: vgic: Fix exit condition in scan_its_table()
    
    commit c000a2607145d28b06c697f968491372ea56c23a upstream.
    
    With some PCIe topologies, restoring a guest fails while
    parsing the ITS device tables.
    
    Reproducer hints:
    1. Create ARM virt VM with pxb-pcie bus which adds
       extra host bridges, with qemu command like:
    
    ```
      -device pxb-pcie,bus_nr=8,id=pci.x,numa_node=0,bus=pcie.0 \
      -device pcie-root-port,..,bus=pci.x \
      ...
      -device pxb-pcie,bus_nr=37,id=pci.y,numa_node=1,bus=pcie.0 \
      -device pcie-root-port,..,bus=pci.y \
      ...
    
    ```
    2. Ensure the guest uses 2-level device table
    3. Perform VM migration which calls save/restore device tables
    
    In that setup, we get a big "offset" between 2 device_ids,
    which makes unsigned "len" round up a big positive number,
    causing the scan loop to continue with a bad GPA. For example:
    
    1. L1 table has 2 entries;
    2. and we are now scanning at L2 table entry index 2075 (pointed
       to by L1 first entry)
    3. if next device id is 9472, we will get a big offset: 7397;
    4. with unsigned 'len', 'len -= offset * esz', len will underflow to a
       positive number, mistakenly into next iteration with a bad GPA;
       (It should break out of the current L2 table scanning, and jump
       into the next L1 table entry)
    5. that bad GPA fails the guest read.
    
    Fix it by stopping the L2 table scan when the next device id is
    outside of the current table, allowing the scan to continue from
    the next L1 table entry.
    
    Thanks to Eric Auger for the fix suggestion.
    
    Fixes: 920a7a8fa92a ("KVM: arm64: vgic-its: Add infrastructure for tableookup")
    Suggested-by: Eric Auger <eric.auger@redhat.com>
    Signed-off-by: Eric Ren <renzhengeek@gmail.com>
    [maz: commit message tidy-up]
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/d9c3a564af9e2c5bf63f48a7dcbf08cd593c5c0b.1665802985.git.renzhengeek@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d7321a767e13d905df3404275422146202a3e8d
Author: Alexander Graf <graf@amazon.com>
Date:   Mon Oct 17 20:45:41 2022 +0200

    KVM: x86: Add compat handler for KVM_X86_SET_MSR_FILTER
    
    commit 1739c7017fb1d759965dcbab925ff5980a5318cb upstream.
    
    The KVM_X86_SET_MSR_FILTER ioctls contains a pointer in the passed in
    struct which means it has a different struct size depending on whether
    it gets called from 32bit or 64bit code.
    
    This patch introduces compat code that converts from the 32bit struct to
    its 64bit counterpart which then gets used going forward internally.
    With this applied, 32bit QEMU can successfully set MSR bitmaps when
    running on 64bit kernels.
    
    Reported-by: Andrew Randrianasulu <randrianasulu@gmail.com>
    Fixes: 1a155254ff937 ("KVM: x86: Introduce MSR filtering")
    Signed-off-by: Alexander Graf <graf@amazon.com>
    Message-Id: <20221017184541.2658-4-graf@amazon.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c47a228013212fb939d82f35aedb753aca54eebf
Author: Alexander Graf <graf@amazon.com>
Date:   Mon Oct 17 20:45:40 2022 +0200

    KVM: x86: Copy filter arg outside kvm_vm_ioctl_set_msr_filter()
    
    commit 2e3272bc1790825c43d2c39690bf2836b81c6d36 upstream.
    
    In the next patch we want to introduce a second caller to
    set_msr_filter() which constructs its own filter list on the stack.
    Refactor the original function so it takes it as argument instead of
    reading it through copy_from_user().
    
    Signed-off-by: Alexander Graf <graf@amazon.com>
    Message-Id: <20221017184541.2658-3-graf@amazon.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b7ebdcae2b62652978dd3139f77ff58e30a769a
Author: Alexander Graf <graf@amazon.com>
Date:   Mon Oct 17 20:45:39 2022 +0200

    kvm: Add support for arch compat vm ioctls
    
    commit ed51862f2f57cbce6fed2d4278cfe70a490899fd upstream.
    
    We will introduce the first architecture specific compat vm ioctl in the
    next patch. Add all necessary boilerplate to allow architectures to
    override compat vm ioctls when necessary.
    
    Signed-off-by: Alexander Graf <graf@amazon.com>
    Message-Id: <20221017184541.2658-2-graf@amazon.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c828fab903725279aa9dc6ae3d44bb7e4778f92c
Author: Rik van Riel <riel@surriel.com>
Date:   Mon Oct 17 20:25:05 2022 -0400

    mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages
    
    commit 12df140f0bdfae5dcfc81800970dd7f6f632e00c upstream.
    
    The h->*_huge_pages counters are protected by the hugetlb_lock, but
    alloc_huge_page has a corner case where it can decrement the counter
    outside of the lock.
    
    This could lead to a corrupted value of h->resv_huge_pages, which we have
    observed on our systems.
    
    Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a
    potential race.
    
    Link: https://lkml.kernel.org/r/20221017202505.0e6a4fcd@imladris.surriel.com
    Fixes: a88c76954804 ("mm: hugetlb: fix hugepage memory leak caused by wrong reserve count")
    Signed-off-by: Rik van Riel <riel@surriel.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Glen McCready <gkmccready@meta.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e2c60da6284dd1a2f173ad8d62b8d72c8ba2bfc
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Oct 19 16:57:42 2022 -0400

    drm/amdgpu: fix sdma doorbell init ordering on APUs
    
    commit 50b0e4d4da09fa501e722af886f97e60a4f820d6 upstream.
    
    Commit 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
    uncovered a bug in amdgpu that required a reordering of the driver
    init sequence to avoid accessing a special register on the GPU
    before it was properly set up leading to an PCI AER error.  This
    reordering uncovered a different hw programming ordering dependency
    in some APUs where the SDMA doorbells need to be programmed before
    the GFX doorbells. To fix this, move the SDMA doorbell programming
    back into the soc15 common code, but use the actual doorbell range
    values directly rather than the values stored in the ring structure
    since those will not be initialized at this point.
    
    This is a partial revert, but with the doorbell assignment
    fixed so the proper doorbell index is set before it's used.
    
    Fixes: e3163bc8ffdfdb ("drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega")
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: skhan@linuxfoundation.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6ea267e0c6bdf5463358e2a2e5280cfa6cacc48
Author: Fabien Parent <fabien.parent@linaro.org>
Date:   Sat Oct 15 15:04:22 2022 +0200

    cpufreq: qcom: fix memory leak in error path
    
    commit 9f42cf54403a42cb092636804d2628d8ecf71e75 upstream.
    
    If for some reason the speedbin length is incorrect, then there is a
    memory leak in the error path because we never free the speedbin buffer.
    This commit fixes the error path to always free the speedbin buffer.
    
    Cc: v5.7+ <stable@vger.kernel.org> # v5.7+
    Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs")
    Signed-off-by: Fabien Parent <fabien.parent@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5572e66d27bbe78e66472e756dd23afde08fbdd
Author: Babu Moger <babu.moger@amd.com>
Date:   Tue Sep 27 15:16:29 2022 -0500

    x86/resctrl: Fix min_cbm_bits for AMD
    
    commit 67bf6493449b09590f9f71d7df29efb392b12d25 upstream.
    
    AMD systems support zero CBM (capacity bit mask) for cache allocation.
    That is reflected in rdt_init_res_defs_amd() by:
    
      r->cache.arch_has_empty_bitmaps = true;
    
    However given the unified code in cbm_validate(), checking for:
    
      val == 0 && !arch_has_empty_bitmaps
    
    is not enough because of another check in cbm_validate():
    
      if ((zero_bit - first_bit) < r->cache.min_cbm_bits)
    
    The default value of r->cache.min_cbm_bits = 1.
    
    Leading to:
    
      $ cd /sys/fs/resctrl
      $ mkdir foo
      $ cd foo
      $ echo L3:0=0 > schemata
        -bash: echo: write error: Invalid argument
      $ cat /sys/fs/resctrl/info/last_cmd_status
        Need at least 1 bits in the mask
    
    Initialize the min_cbm_bits to 0 for AMD. Also, remove the default
    setting of min_cbm_bits and initialize it separately.
    
    After the fix:
    
      $ cd /sys/fs/resctrl
      $ mkdir foo
      $ cd foo
      $ echo L3:0=0 > schemata
      $ cat /sys/fs/resctrl/info/last_cmd_status
        ok
    
    Fixes: 316e7f901f5a ("x86/resctrl: Add struct rdt_cache::arch_has_{sparse, empty}_bitmaps")
    Co-developed-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Babu Moger <babu.moger@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: James Morse <james.morse@arm.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/lkml/20220517001234.3137157-1-eranian@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6314d5f68764550c84d732ce901ddd3ac6b415f
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Oct 11 10:46:17 2022 +0800

    ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS
    
    commit 1e41e693f458eef2d5728207dbd327cd3b16580a upstream.
    
    UBSAN complains about array-index-out-of-bounds:
    [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41
    [ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'
    [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu
    [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010
    [ 1.980718] kernel: Call Trace:
    [ 1.980721] kernel: <TASK>
    [ 1.980723] kernel: show_stack+0x52/0x58
    [ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f
    [ 1.980734] kernel: dump_stack+0x10/0x12
    [ 1.980736] kernel: ubsan_epilogue+0x9/0x45
    [ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49
    [ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci]
    [ 1.980748] kernel: ata_qc_issue+0x135/0x240
    [ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580
    [ 1.980754] kernel: ? vprintk_default+0x1d/0x20
    [ 1.980759] kernel: ata_exec_internal+0x67/0xa0
    [ 1.980762] kernel: sata_pmp_read+0x8d/0xc0
    [ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90
    [ 1.980768] kernel: sata_pmp_attach+0x8b/0x310
    [ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0
    [ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30
    [ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci]
    [ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci]
    [ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci]
    [ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0
    [ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560
    [ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40
    [ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci]
    [ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600
    [ 1.980810] kernel: ata_scsi_error+0x9c/0xd0
    [ 1.980813] kernel: scsi_error_handler+0xa1/0x180
    [ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0
    [ 1.980820] kernel: kthread+0x12a/0x150
    [ 1.980823] kernel: ? set_kthread_struct+0x50/0x50
    [ 1.980826] kernel: ret_from_fork+0x22/0x30
    [ 1.980831] kernel: </TASK>
    
    This happens because sata_pmp_init_links() initialize link->pmp up to
    SATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.
    
    I can't find the maximum Enclosure Management ports specified in AHCI
    spec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier
    Information" can utilize 4 bits, which implies it can support up to 16
    ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the
    issue.
    
    BugLink: https://bugs.launchpad.net/bugs/1970074
    Cc: stable@vger.kernel.org
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91a0eac09b9e6624b0263f7c87482c31044a6c86
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Wed Oct 12 15:11:05 2022 +0200

    ata: ahci-imx: Fix MODULE_ALIAS
    
    commit 979556f1521a835a059de3b117b9c6c6642c7d58 upstream.
    
    'ahci:' is an invalid prefix, preventing the module from autoloading.
    Fix this by using the 'platform:' prefix and DRV_NAME.
    
    Fixes: 9e54eae23bc9 ("ahci_imx: add ahci sata support on imx platforms")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1de8e1ae924d9dc31548676e4a665b52ebee27e
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Oct 14 17:01:45 2022 +0800

    hwmon/coretemp: Handle large core ID value
    
    commit 7108b80a542b9d65e44b36d64a700a83658c0b73 upstream.
    
    The coretemp driver supports up to a hard-coded limit of 128 cores.
    
    Today, the driver can not support a core with an ID above that limit.
    Yet, the encoding of core ID's is arbitrary (BIOS APIC-ID) and so they
    may be sparse and they may be large.
    
    Update the driver to map arbitrary core ID numbers into appropriate
    array indexes so that 128 cores can be supported, no matter the encoding
    of core ID's.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Acked-by: Len Brown <len.brown@intel.com>
    Acked-by: Guenter Roeck <linux@roeck-us.net>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20221014090147.1836-3-rui.zhang@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3820554c59a37d955ce9fc877751b4c9ab166d25
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Oct 5 12:00:08 2022 +0200

    x86/microcode/AMD: Apply the patch early on every logical thread
    
    commit e7ad18d1169c62e6c78c01ff693fd362d9d65278 upstream.
    
    Currently, the patch application logic checks whether the revision
    needs to be applied on each logical CPU (SMT thread). Therefore, on SMT
    designs where the microcode engine is shared between the two threads,
    the application happens only on one of them as that is enough to update
    the shared microcode engine.
    
    However, there are microcode patches which do per-thread modification,
    see Link tag below.
    
    Therefore, drop the revision check and try applying on each thread. This
    is what the BIOS does too so this method is very much tested.
    
    Btw, change only the early paths. On the late loading paths, there's no
    point in doing per-thread modification because if is it some case like
    in the bugzilla below - removing a CPUID flag - the kernel cannot go and
    un-use features it has detected are there early. For that, one should
    use early loading anyway.
    
      [ bp: Fixes does not contain the oldest commit which did check for
        equality but that is good enough. ]
    
    Fixes: 8801b3fcb574 ("x86/microcode/AMD: Rework container parsing")
    Reported-by:  Ștefan Talpalaru <stefantalpalaru@yahoo.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by:  Ștefan Talpalaru <stefantalpalaru@yahoo.com>
    Cc: <stable@vger.kernel.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216211
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1a2634fab8dc3e824b1fc2c3e2f773b781bb69
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Tue Oct 11 16:32:43 2022 +0100

    cpufreq: tegra194: Fix module loading
    
    commit 1dcaf30725c32b26daa70d22083999972ab99c29 upstream.
    
    When the Tegra194 CPUFREQ driver is built as a module it is not
    automatically loaded as expected on Tegra194 devices. Populate the
    MODULE_DEVICE_TABLE to fix this.
    
    Cc: v5.9+ <stable@vger.kernel.org> # v5.9+
    Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f373414cbe878afc3050b7d37d58a140ab3841
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Tue Oct 18 03:19:20 2022 +0100

    i2c: qcom-cci: Fix ordering of pm_runtime_xx and i2c_add_adapter
    
    commit 61775d54d674ff8ec3658495e0dbc537227dc5c1 upstream.
    
    When we compile-in the CCI along with the imx412 driver and run on the RB5
    we see that i2c_add_adapter() causes the probe of the imx412 driver to
    happen.
    
    This probe tries to perform an i2c xfer() and the xfer() in i2c-qcom-cci.c
    fails on pm_runtime_get() because the i2c-qcom-cci.c::probe() function has
    not completed to pm_runtime_enable(dev).
    
    Fix this sequence by ensuring pm_runtime_xxx() calls happen prior to adding
    the i2c adapter.
    
    Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver")
    Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b74ee4e301ca01e431e240c046173332966e2431
Author: Fabien Parent <fabien.parent@linaro.org>
Date:   Sat Oct 15 15:04:23 2022 +0200

    cpufreq: qcom: fix writes in read-only memory region
    
    commit 01039fb8e90c9cb684430414bff70cea9eb168c5 upstream.
    
    This commit fixes a kernel oops because of a write in some read-only memory:
    
            [    9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8
            ..snip..
            [    9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP
            ..snip..
            [    9.269161] Call trace:
            [    9.276271]  __memcpy+0x5c/0x230
            [    9.278531]  snprintf+0x58/0x80
            [    9.282002]  qcom_cpufreq_msm8939_name_version+0xb4/0x190
            [    9.284869]  qcom_cpufreq_probe+0xc8/0x39c
            ..snip..
    
    The following line defines a pointer that point to a char buffer stored
    in read-only memory:
    
            char *pvs_name = "speedXX-pvsXX-vXX";
    
    This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the
    XX values get overridden by the qcom_cpufreq_krait_name_version function. Since
    the template is actually stored in read-only memory, when the function
    executes the following call we get an oops:
    
            snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d",
                     speed, pvs, pvs_ver);
    
    To fix this issue, we instead store the template name onto the stack by
    using the following syntax:
    
            char pvs_name_buffer[] = "speedXX-pvsXX-vXX";
    
    Because the `pvs_name` needs to be able to be assigned to NULL, the
    template buffer is stored in the pvs_name_buffer and not under the
    pvs_name variable.
    
    Cc: v5.7+ <stable@vger.kernel.org> # v5.7+
    Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs")
    Signed-off-by: Fabien Parent <fabien.parent@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 277378631d26477451424cc73982b977961f3d8b
Author: GONG, Ruiqi <gongruiqi1@huawei.com>
Date:   Wed Oct 19 10:57:10 2022 +0800

    selinux: enable use of both GFP_KERNEL and GFP_ATOMIC in convert_context()
    
    commit abe3c631447dcd1ba7af972fe6f054bee6f136fa upstream.
    
    The following warning was triggered on a hardware environment:
    
      SELinux: Converting 162 SID table entries...
      BUG: sleeping function called from invalid context at
           __might_sleep+0x60/0x74 0x0
      in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 5943, name: tar
      CPU: 7 PID: 5943 Comm: tar Tainted: P O 5.10.0 #1
      Call trace:
       dump_backtrace+0x0/0x1c8
       show_stack+0x18/0x28
       dump_stack+0xe8/0x15c
       ___might_sleep+0x168/0x17c
       __might_sleep+0x60/0x74
       __kmalloc_track_caller+0xa0/0x7dc
       kstrdup+0x54/0xac
       convert_context+0x48/0x2e4
       sidtab_context_to_sid+0x1c4/0x36c
       security_context_to_sid_core+0x168/0x238
       security_context_to_sid_default+0x14/0x24
       inode_doinit_use_xattr+0x164/0x1e4
       inode_doinit_with_dentry+0x1c0/0x488
       selinux_d_instantiate+0x20/0x34
       security_d_instantiate+0x70/0xbc
       d_splice_alias+0x4c/0x3c0
       ext4_lookup+0x1d8/0x200 [ext4]
       __lookup_slow+0x12c/0x1e4
       walk_component+0x100/0x200
       path_lookupat+0x88/0x118
       filename_lookup+0x98/0x130
       user_path_at_empty+0x48/0x60
       vfs_statx+0x84/0x140
       vfs_fstatat+0x20/0x30
       __se_sys_newfstatat+0x30/0x74
       __arm64_sys_newfstatat+0x1c/0x2c
       el0_svc_common.constprop.0+0x100/0x184
       do_el0_svc+0x1c/0x2c
       el0_svc+0x20/0x34
       el0_sync_handler+0x80/0x17c
       el0_sync+0x13c/0x140
      SELinux: Context system_u:object_r:pssp_rsyslog_log_t:s0:c0 is
               not valid (left unmapped).
    
    It was found that within a critical section of spin_lock_irqsave in
    sidtab_context_to_sid(), convert_context() (hooked by
    sidtab_convert_params.func) might cause the process to sleep via
    allocating memory with GFP_KERNEL, which is problematic.
    
    As Ondrej pointed out [1], convert_context()/sidtab_convert_params.func
    has another caller sidtab_convert_tree(), which is okay with GFP_KERNEL.
    Therefore, fix this problem by adding a gfp_t argument for
    convert_context()/sidtab_convert_params.func and pass GFP_KERNEL/_ATOMIC
    properly in individual callers.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20221018120111.1474581-1-gongruiqi1@huawei.com/ [1]
    Reported-by: Tan Ninghao <tanninghao1@huawei.com>
    Fixes: ee1a84fdfeed ("selinux: overhaul sidtab to fix bug and improve performance")
    Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
    Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
    [PM: wrap long BUG() output lines, tweak subject line]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22cdc6d325d474d73de32d1dbeea05e24d6cf65d
Author: Steve French <stfrench@microsoft.com>
Date:   Sat Oct 15 17:02:30 2022 -0500

    smb3: interface count displayed incorrectly
    
    commit 096bbeec7bd6fb683831a9ca4850a6b6a3f04740 upstream.
    
    The "Server interfaces" count in /proc/fs/cifs/DebugData increases
    as the interfaces are requeried, rather than being reset to the new
    value.  This could cause a problem if the server disabled
    multichannel as the iface_count is checked in try_adding_channels
    to see if multichannel still supported.
    
    Also fixes a coverity warning:
    
    Addresses-Coverity: 1526374 ("Concurrent data access violations  (MISSING_LOCK)")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Bharath SM <bharathsm@microsoft.com>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c01f389fbf7616298963a6a19f1fbc5a9b8b0aac
Author: Joseph Qi <joseph.qi@linux.alibaba.com>
Date:   Mon Oct 17 21:02:26 2022 +0800

    ocfs2: fix BUG when iput after ocfs2_mknod fails
    
    commit 759a7c6126eef5635506453e9b9d55a6a3ac2084 upstream.
    
    Commit b1529a41f777 "ocfs2: should reclaim the inode if
    '__ocfs2_mknod_locked' returns an error" tried to reclaim the claimed
    inode if __ocfs2_mknod_locked() fails later.  But this introduce a race,
    the freed bit may be reused immediately by another thread, which will
    update dinode, e.g.  i_generation.  Then iput this inode will lead to BUG:
    inode->i_generation != le32_to_cpu(fe->i_generation)
    
    We could make this inode as bad, but we did want to do operations like
    wipe in some cases.  Since the claimed inode bit can only affect that an
    dinode is missing and will return back after fsck, it seems not a big
    problem.  So just leave it as is by revert the reclaim logic.
    
    Link: https://lkml.kernel.org/r/20221017130227.234480-1-joseph.qi@linux.alibaba.com
    Fixes: b1529a41f777 ("ocfs2: should reclaim the inode if '__ocfs2_mknod_locked' returns an error")
    Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Reported-by: Yan Wang <wangyan122@huawei.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcca3c1a72b82c8f1c3f0cb0273d3508cb8714dc
Author: Joseph Qi <joseph.qi@linux.alibaba.com>
Date:   Mon Oct 17 21:02:27 2022 +0800

    ocfs2: clear dinode links count in case of error
    
    commit 28f4821b1b53e0649706912e810c6c232fc506f9 upstream.
    
    In ocfs2_mknod(), if error occurs after dinode successfully allocated,
    ocfs2 i_links_count will not be 0.
    
    So even though we clear inode i_nlink before iput in error handling, it
    still won't wipe inode since we'll refresh inode from dinode during inode
    lock.  So just like clear inode i_nlink, we clear ocfs2 i_links_count as
    well.  Also do the same change for ocfs2_symlink().
    
    Link: https://lkml.kernel.org/r/20221017130227.234480-2-joseph.qi@linux.alibaba.com
    Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Reported-by: Yan Wang <wangyan122@huawei.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25a6688f27ff54f97adf7cce1d7e18c38bf51eb4
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Wed Oct 26 16:44:48 2022 +0200

    video/aperture: Call sysfb_disable() before removing PCI devices
    
    Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
    before removing PCI devices. Without, simpledrm can still bind to
    simple-framebuffer devices after the hardware driver has taken over
    the hardware. Both drivers interfere with each other and results are
    undefined.
    
    Reported modesetting errors [1] are shown below.
    
    ---- snap ----
    rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.
    rcu: blocking rcu_node structures (internal RCU debug):
    Task dump for CPU 13:
    task:X               state:R  running task     stack:    0 pid: 4242 ppid:  4228 flags:0x00000008
    Call Trace:
     <TASK>
     ? commit_tail+0xd7/0x130
     ? drm_atomic_helper_commit+0x126/0x150
     ? drm_atomic_commit+0xa4/0xe0
     ? drm_plane_get_damage_clips.cold+0x1c/0x1c
     ? drm_atomic_helper_dirtyfb+0x19e/0x280
     ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
     ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
     ? drm_ioctl_kernel+0xc4/0x150
     ? drm_ioctl+0x246/0x3f0
     ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
     ? __x64_sys_ioctl+0x91/0xd0
     ? do_syscall_64+0x60/0xd0
     ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
     </TASK>
    ...
    rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/.
    rcu: blocking rcu_node structures (internal RCU debug):
    Task dump for CPU 13:
    task:X               state:R  running task     stack:    0 pid: 4242 ppid:  4228 flags:0x0000400e
    Call Trace:
     <TASK>
     ? memcpy_toio+0x76/0xc0
     ? memcpy_toio+0x1b/0xc0
     ? drm_fb_memcpy_toio+0x76/0xb0
     ? drm_fb_blit_toio+0x75/0x2b0
     ? simpledrm_simple_display_pipe_update+0x132/0x150
     ? drm_atomic_helper_commit_planes+0xb6/0x230
     ? drm_atomic_helper_commit_tail+0x44/0x80
     ? commit_tail+0xd7/0x130
     ? drm_atomic_helper_commit+0x126/0x150
     ? drm_atomic_commit+0xa4/0xe0
     ? drm_plane_get_damage_clips.cold+0x1c/0x1c
     ? drm_atomic_helper_dirtyfb+0x19e/0x280
     ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
     ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
     ? drm_ioctl_kernel+0xc4/0x150
     ? drm_ioctl+0x246/0x3f0
     ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
     ? __x64_sys_ioctl+0x91/0xd0
     ? do_syscall_64+0x60/0xd0
     ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
     </TASK>
    
    The problem was added by commit 5e0137612430 ("video/aperture: Disable
    and unregister sysfb devices via aperture helpers") to v6.0.3 and does
    not exist in the mainline branch.
    
    The mainline commit 5e0137612430 ("video/aperture: Disable and
    unregister sysfb devices via aperture helpers") has been backported
    from v6.0-rc1 to stable v6.0.3 from a larger patch series [2] that
    reworks fbdev framebuffer ownership. The backport misses a change to
    aperture_remove_conflicting_pci_devices(). Mainline itself is fine,
    because the function does not exist there as a result of the patch
    series.
    
    Instead of backporting the whole series, fix the additional function.
    
    Reported-by: Andreas Thalhammer <andreas.thalhammer-linux@gmx.net>
    Reported-by: Thorsten Leemhuis <regressions@leemhuis.info>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Tested-by: Andreas Thalhammer <andreas.thalhammer-linux@gmx.net>
    Fixes: cfecfc98a78d ("video/aperture: Disable and unregister sysfb devices via aperture helpers")
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Javier Martinez Canillas <javierm@redhat.com>
    Cc: Zack Rusin <zackr@vmware.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: Zhen Lei <thunder.leizhen@huawei.com>
    Cc: Changcheng Deng <deng.changcheng@zte.com.cn>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: dri-devel@lists.freedesktop.org
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: linux-fbdev@vger.kernel.org
    Cc: <stable@vger.kernel.org> # v6.0.3+
    Link: https://lore.kernel.org/dri-devel/d6afe54b-f8d7-beb2-3609-186e566cbfac@gmx.net/T/#t # [1]
    Link: https://patchwork.freedesktop.org/series/106040/ # [2]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>