commit e0ee50101346ca9cef52da75e3fb4380c27c042a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 20 12:37:00 2023 +0200

    Linux 6.2.12
    
    Link: https://lore.kernel.org/r/20230418120313.725598495@linuxfoundation.org
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/r/20230419093655.693770727@linuxfoundation.org
    Link: https://lore.kernel.org/r/20230419132054.228391649@linuxfoundation.org
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8260f9a083c1c99e155b2787e2742e2cb692b61d
Author: Duy Truong <dory@dory.moe>
Date:   Thu Apr 13 17:55:48 2023 -0700

    nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD
    
    [ Upstream commit 74391b3e69855e7dd65a9cef36baf5fc1345affd ]
    
    Added a quirk to fix the TeamGroup T-Force Cardea Zero Z330 SSDs reporting
    duplicate NGUIDs.
    
    Signed-off-by: Duy Truong <dory@dory.moe>
    Cc: stable@vger.kernel.org
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d0d418bb2b4bd7e179069fcb2a36d32f0d44007
Author: Juraj Pecigos <kernel@juraj.dev>
Date:   Sun Mar 26 11:29:49 2023 +0200

    nvme-pci: mark Lexar NM760 as IGNORE_DEV_SUBNQN
    
    [ Upstream commit 1231363aec86704a6b0467a12e3ca7bdf890e01d ]
    
    A system with more than one of these SSDs will only have one usable.
    The kernel fails to detect more than one nvme device due to duplicate
    cntlids.
    
    before:
    [    9.395229] nvme 0000:01:00.0: platform quirk: setting simple suspend
    [    9.395262] nvme nvme0: pci function 0000:01:00.0
    [    9.395282] nvme 0000:03:00.0: platform quirk: setting simple suspend
    [    9.395305] nvme nvme1: pci function 0000:03:00.0
    [    9.409873] nvme nvme0: Duplicate cntlid 1 with nvme1, subsys nqn.2022-07.com.siliconmotion:nvm-subsystem-sn-                    , rejecting
    [    9.409982] nvme nvme0: Removing after probe failure status: -22
    [    9.427487] nvme nvme1: allocated 64 MiB host memory buffer.
    [    9.445088] nvme nvme1: 16/0/0 default/read/poll queues
    [    9.449898] nvme nvme1: Ignoring bogus Namespace Identifiers
    
    after:
    [    1.161890] nvme 0000:01:00.0: platform quirk: setting simple suspend
    [    1.162660] nvme nvme0: pci function 0000:01:00.0
    [    1.162684] nvme 0000:03:00.0: platform quirk: setting simple suspend
    [    1.162707] nvme nvme1: pci function 0000:03:00.0
    [    1.191354] nvme nvme0: allocated 64 MiB host memory buffer.
    [    1.193378] nvme nvme1: allocated 64 MiB host memory buffer.
    [    1.211044] nvme nvme1: 16/0/0 default/read/poll queues
    [    1.211080] nvme nvme0: 16/0/0 default/read/poll queues
    [    1.216145] nvme nvme0: Ignoring bogus Namespace Identifiers
    [    1.216261] nvme nvme1: Ignoring bogus Namespace Identifiers
    
    Adding the NVME_QUIRK_IGNORE_DEV_SUBNQN quirk to resolves the issue.
    
    Signed-off-by: Juraj Pecigos <kernel@juraj.dev>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Stable-dep-of: 74391b3e6985 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0536e50b35c6b015bf6e66ace2e9fc69596dd702
Author: David Disseldorp <ddiss@suse.de>
Date:   Fri Apr 7 00:34:11 2023 +0200

    cifs: fix negotiate context parsing
    
    [ Upstream commit 5105a7ffce19160e7062aee67fb6b3b8a1b56d78 ]
    
    smb311_decode_neg_context() doesn't properly check against SMB packet
    boundaries prior to accessing individual negotiate context entries. This
    is due to the length check omitting the eight byte smb2_neg_context
    header, as well as incorrect decrementing of len_of_ctxts.
    
    Fixes: 5100d8a3fe03 ("SMB311: Improve checking of negotiate security contexts")
    Reported-by: Volker Lendecke <vl@samba.org>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8848804f2d5cffcf0c8685fa5b455ae47e231ec9
Author: Gregor Herburger <gregor.herburger@tq-group.com>
Date:   Thu Apr 13 11:37:37 2023 +0200

    i2c: ocores: generate stop condition after timeout in polling mode
    
    [ Upstream commit f8160d3b35fc94491bb0cb974dbda310ef96c0e2 ]
    
    In polling mode, no stop condition is generated after a timeout. This
    causes SCL to remain low and thereby block the bus. If this happens
    during a transfer it can cause slaves to misinterpret the subsequent
    transfer and return wrong values.
    
    To solve this, pass the ETIMEDOUT error up from ocores_process_polling()
    instead of setting STATE_ERROR directly. The caller is adjusted to call
    ocores_process_timeout() on error both in polling and in IRQ mode, which
    will set STATE_ERROR and generate a stop condition.
    
    Fixes: 69c8c0c0efa8 ("i2c: ocores: add polling interface")
    Signed-off-by: Gregor Herburger <gregor.herburger@tq-group.com>
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Acked-by: Peter Korsgaard <peter@korsgaard.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Federico Vaga <federico.vaga@cern.ch>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40359713eb36d224fed3ca0191cb42b12f17e539
Author: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
Date:   Thu Apr 6 08:26:52 2023 +0200

    x86/rtc: Remove __init for runtime functions
    
    [ Upstream commit 775d3c514c5b2763a50ab7839026d7561795924d ]
    
    set_rtc_noop(), get_rtc_noop() are after booting, therefore their __init
    annotation is wrong.
    
    A crash was observed on an x86 platform where CMOS RTC is unused and
    disabled via device tree. set_rtc_noop() was invoked from ntp:
    sync_hw_clock(), although CONFIG_RTC_SYSTOHC=n, however sync_cmos_clock()
    doesn't honour that.
    
      Workqueue: events_power_efficient sync_hw_clock
      RIP: 0010:set_rtc_noop
      Call Trace:
       update_persistent_clock64
       sync_hw_clock
    
    Fix this by dropping the __init annotation from set/get_rtc_noop().
    
    Fixes: c311ed6183f4 ("x86/init: Allow DT configured systems to disable RTC at boot time")
    Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/59f7ceb1-446b-1d3d-0bc8-1f0ee94b1e18@nokia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 273727f22f62d77e930f5fd069db48c7198b8f6c
Author: Vincent Guittot <vincent.guittot@linaro.org>
Date:   Tue Apr 11 11:06:11 2023 +0200

    sched/fair: Fix imbalance overflow
    
    [ Upstream commit 91dcf1e8068e9a8823e419a7a34ff4341275fb70 ]
    
    When local group is fully busy but its average load is above system load,
    computing the imbalance will overflow and local group is not the best
    target for pulling this load.
    
    Fixes: 0b0695f2b34a ("sched/fair: Rework load_balance()")
    Reported-by: Tingjia Cao <tjcao980311@gmail.com>
    Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Tingjia Cao <tjcao980311@gmail.com>
    Link: https://lore.kernel.org/lkml/CABcWv9_DAhVBOq2=W=2ypKE9dKM5s2DvoV8-U0+GDwwuKZ89jQ@mail.gmail.com/T/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e75afc2d1d47b59c2f6e6fd8733ba7fcf6efebc
Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Date:   Tue Apr 4 09:44:33 2023 +0530

    powerpc/papr_scm: Update the NUMA distance table for the target node
    
    [ Upstream commit b277fc793daf258877b4c0744b52f69d6e6ba22e ]
    
    Platform device helper routines won't update the NUMA distance table
    while creating a platform device, even if the device is present on a
    NUMA node that doesn't have memory or CPU. This is especially true for
    pmem devices. If the target node of the pmem device is not online, we
    find the nearest online node to the device and associate the pmem device
    with that online node. To find the nearest online node, we should have
    the numa distance table updated correctly. Update the distance
    information during the device probe.
    
    For a papr scm device on NUMA node 3 distance_lookup_table value for
    distance_ref_points_depth = 2 before and after fix is below:
    
    Before fix:
      node 3 distance depth 0  - 0
      node 3 distance depth 1  - 0
      node 4 distance depth 0  - 4
      node 4 distance depth 1  - 2
      node 5 distance depth 0  - 5
      node 5 distance depth 1  - 1
    
    After fix
      node 3 distance depth 0  - 3
      node 3 distance depth 1  - 1
      node 4 distance depth 0  - 4
      node 4 distance depth 1  - 2
      node 5 distance depth 0  - 5
      node 5 distance depth 1  - 1
    
    Without the fix, the nearest numa node to the pmem device (NUMA node 3)
    will be picked as 4. After the fix, we get the correct numa node which
    is 5.
    
    Fixes: da1115fdbd6e ("powerpc/nvdimm: Pick nearby online node if the device node is not online")
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230404041433.1781804-1-aneesh.kumar@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 239decac2778645153bc2723cf6d194a083ae106
Author: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>
Date:   Mon Mar 20 19:52:37 2023 +0530

    i2c: mchp-pci1xxxx: Update Timing registers
    
    [ Upstream commit aa874cdfec07d4dd9c6f0c356d65c609ba31a26f ]
    
    Update I2C timing registers based on latest hardware design.
    This fix does not break functionality of chips with older design and
    existing users will not be affected.
    
    Fixes: 361693697249 ("i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch")
    Signed-off-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2354efa80ef1aadefc4cabc63272a122402f7b9
Author: ZhaoLong Wang <wangzhaolong1@huawei.com>
Date:   Sat Mar 4 09:41:41 2023 +0800

    ubi: Fix deadlock caused by recursively holding work_sem
    
    [ Upstream commit f773f0a331d6c41733b17bebbc1b6cae12e016f5 ]
    
    During the processing of the bgt, if the sync_erase() return -EBUSY
    or some other error code in __erase_worker(),schedule_erase() called
    again lead to the down_read(ubi->work_sem) hold twice and may get
    block by down_write(ubi->work_sem) in ubi_update_fastmap(),
    which cause deadlock.
    
              ubi bgt                        other task
     do_work
      down_read(&ubi->work_sem)          ubi_update_fastmap
      erase_worker                         # Blocked by down_read
       __erase_worker                      down_write(&ubi->work_sem)
        schedule_erase
         schedule_ubi_work
          down_read(&ubi->work_sem)
    
    Fix this by changing input parameter @nested of the schedule_erase() to
    'true' to avoid recursively acquiring the down_read(&ubi->work_sem).
    
    Also, fix the incorrect comment about @nested parameter of the
    schedule_erase() because when down_write(ubi->work_sem) is held, the
    @nested is also need be true.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217093
    Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()")
    Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69f65bb91d7470af6273e54436efd0bec1ff88a5
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Mon Mar 6 09:33:08 2023 +0800

    ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size
    
    commit 1e020e1b96afdecd20680b5b5be2a6ffc3d27628 upstream.
    
    Following process will make ubi attaching failed since commit
    1b42b1a36fc946 ("ubi: ensure that VID header offset ... size"):
    
    ID="0xec,0xa1,0x00,0x15" # 128M 128KB 2KB
    modprobe nandsim id_bytes=$ID
    flash_eraseall /dev/mtd0
    modprobe ubi mtd="0,2048"  # set vid_hdr offset as 2048 (one page)
    (dmesg):
      ubi0 error: ubi_attach_mtd_dev [ubi]: VID header offset 2048 too large.
      UBI error: cannot attach mtd0
      UBI error: cannot initialize UBI, error -22
    
    Rework original solution, the key point is making sure
    'vid_hdr_shift + UBI_VID_HDR_SIZE < ubi->vid_hdr_alsize',
    so we should check vid_hdr_shift rather not vid_hdr_offset.
    Then, ubi still support (sub)page aligined VID header offset.
    
    Fixes: 1b42b1a36fc946 ("ubi: ensure that VID header offset ... size")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Tested-by: Nicolas Schichan <nschichan@freebox.fr>
    Tested-by: Miquel Raynal <miquel.raynal@bootlin.com> # v5.10, v4.19
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a096a78d70a012b47d0ab50cfd26905a39506bf8
Author: Matthieu Baerts <matthieu.baerts@tessares.net>
Date:   Tue Apr 11 22:42:12 2023 +0200

    selftests: mptcp: userspace pm: uniform verify events
    
    commit 711ae788cbbb82818531b55e32b09518ee09a11a upstream.
    
    Simply adding a "sleep" before checking something is usually not a good
    idea because the time that has been picked can not be enough or too
    much. The best is to wait for events with a timeout.
    
    In this selftest, 'sleep 0.5' is used more than 40 times. It is always
    used before calling a 'verify_*' function except for this
    verify_listener_events which has been added later.
    
    At the end, using all these 'sleep 0.5' seems to work: the slow CIs
    don't complain so far. Also because it doesn't take too much time, we
    can just add two more 'sleep 0.5' to uniform what is done before calling
    a 'verify_*' function. For the same reasons, we can also delay a bigger
    refactoring to replace all these 'sleep 0.5' by functions waiting for
    events instead of waiting for a fix time and hope for the best.
    
    Fixes: 6c73008aa301 ("selftests: mptcp: listener test for userspace PM")
    Cc: stable@vger.kernel.org
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95135835519b0ab931c39908b2c99e9fb3c9068b
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Apr 11 22:42:11 2023 +0200

    mptcp: fix NULL pointer dereference on fastopen early fallback
    
    commit c0ff6f6da66a7791a32c0234388b1bdc00244917 upstream.
    
    In case of early fallback to TCP, subflow_syn_recv_sock() deletes
    the subflow context before returning the newly allocated sock to
    the caller.
    
    The fastopen path does not cope with the above unconditionally
    dereferencing the subflow context.
    
    Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19ea79e87af32c2b3c6fc49bd84efeb35ca57678
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Apr 11 22:42:10 2023 +0200

    mptcp: stricter state check in mptcp_worker
    
    commit d6a0443733434408f2cbd4c53fea6910599bab9e upstream.
    
    As reported by Christoph, the mptcp protocol can run the
    worker when the relevant msk socket is in an unexpected state:
    
    connect()
    // incoming reset + fastclose
    // the mptcp worker is scheduled
    mptcp_disconnect()
    // msk is now CLOSED
    listen()
    mptcp_worker()
    
    Leading to the following splat:
    
    divide error: 0000 [#1] PREEMPT SMP
    CPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
    Workqueue: events mptcp_worker
    RIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018
    RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293
    RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004
    RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000
    R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     tcp_select_window net/ipv4/tcp_output.c:262 [inline]
     __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345
     tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline]
     tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459
     mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline]
     mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705
     process_one_work+0x3bd/0x950 kernel/workqueue.c:2390
     worker_thread+0x5b/0x610 kernel/workqueue.c:2537
     kthread+0x138/0x170 kernel/kthread.c:376
     ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308
     </TASK>
    
    This change addresses the issue explicitly checking for bad states
    before running the mptcp worker.
    
    Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Link: https://github.com/multipath-tcp/mptcp_net-next/issues/374
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Tested-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1afbb34456062561672f7a6e999ca63e16a9ff6a
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Apr 11 22:42:09 2023 +0200

    mptcp: use mptcp_schedule_work instead of open-coding it
    
    commit a5cb752b125766524c921faab1a45cc96065b0a7 upstream.
    
    Beyond reducing code duplication this also avoids scheduling
    the mptcp_worker on a closed socket on some edge scenarios.
    
    The addressed issue is actually older than the blamed commit
    below, but this fix needs it as a pre-requisite.
    
    Fixes: ba8f48f7a4d7 ("mptcp: introduce mptcp_schedule_work")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9ebb8ed5569fe85a30a795e967cf4595a503040
Author: Horatio Zhang <Hongkun.Zhang@amd.com>
Date:   Thu Apr 6 13:32:14 2023 +0800

    drm/amd/pm: correct SMU13.0.7 max shader clock reporting
    
    commit 85e0689eb6b10cd3b2fb455d1b3f4d4d0b13ff78 upstream.
    
    Correct the max shader clock reporting on SMU
    13.0.7.
    
    Signed-off-by: Horatio Zhang <Hongkun.Zhang@amd.com>
    Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6007b9890ec88afe72a7a6e4ec24c923b745d305
Author: Horatio Zhang <Hongkun.Zhang@amd.com>
Date:   Thu Apr 6 11:17:38 2023 +0800

    drm/amd/pm: correct SMU13.0.7 pstate profiling clock settings
    
    commit f06b8887e3ef4f50098d3a949aef392c529c831a upstream.
    
    Correct the pstate standard/peak profiling mode clock
    settings for SMU13.0.7.
    
    Signed-off-by: Horatio Zhang <Hongkun.Zhang@amd.com>
    Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89c98802f0b754f3ee130480509f088be1daf81c
Author: Waiman Long <longman@redhat.com>
Date:   Tue Apr 11 09:35:59 2023 -0400

    cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods
    
    commit eee87853794187f6adbe19533ed79c8b44b36a91 upstream.
    
    In the case of CLONE_INTO_CGROUP, not all cpusets are ready to accept
    new tasks. It is too late to check that in cpuset_fork(). So we need
    to add the cpuset_can_fork() and cpuset_cancel_fork() methods to
    pre-check it before we can allow attachment to a different cpuset.
    
    We also need to set the attach_in_progress flag to alert other code
    that a new task is going to be added to the cpuset.
    
    Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups")
    Suggested-by: Michal Koutný <mkoutny@suse.com>
    Signed-off-by: Waiman Long <longman@redhat.com>
    Cc: stable@vger.kernel.org # v5.7+
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1eeb31c3ac1a79eae566c763bd21237bc5d39198
Author: Waiman Long <longman@redhat.com>
Date:   Tue Apr 11 09:35:58 2023 -0400

    cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly
    
    commit 42a11bf5c5436e91b040aeb04063be1710bb9f9c upstream.
    
    By default, the clone(2) syscall spawn a child process into the same
    cgroup as its parent. With the use of the CLONE_INTO_CGROUP flag
    introduced by commit ef2c41cf38a7 ("clone3: allow spawning processes
    into cgroups"), the child will be spawned into a different cgroup which
    is somewhat similar to writing the child's tid into "cgroup.threads".
    
    The current cpuset_fork() method does not properly handle the
    CLONE_INTO_CGROUP case where the cpuset of the child may be different
    from that of its parent.  Update the cpuset_fork() method to treat the
    CLONE_INTO_CGROUP case similar to cpuset_attach().
    
    Since the newly cloned task has not been running yet, its actual
    memory usage isn't known. So it is not necessary to make change to mm
    in cpuset_fork().
    
    Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups")
    Reported-by: Giuseppe Scrivano <gscrivan@redhat.com>
    Signed-off-by: Waiman Long <longman@redhat.com>
    Cc: stable@vger.kernel.org # v5.7+
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aa942500458a39afb02d10d20d2ed59349ab2a4
Author: Waiman Long <longman@redhat.com>
Date:   Tue Apr 11 09:35:57 2023 -0400

    cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach()
    
    commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream.
    
    After a successful cpuset_can_attach() call which increments the
    attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach()
    will be called later. In cpuset_attach(), tasks in cpuset_attach_wq,
    if present, will be woken up at the end. That is not the case in
    cpuset_cancel_attach(). So missed wakeup is possible if the attach
    operation is somehow cancelled. Fix that by doing the wakeup in
    cpuset_cancel_attach() as well.
    
    Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    Cc: stable@vger.kernel.org # v3.11+
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37d82023df0464e46a73d92ce5dc6fdf09b9313d
Author: Waiman Long <longman@redhat.com>
Date:   Fri Mar 17 11:15:05 2023 -0400

    cgroup/cpuset: Fix partition root's cpuset.cpus update bug
    
    commit 292fd843de26c551856e66faf134512c52dd78b4 upstream.
    
    It was found that commit 7a2127e66a00 ("cpuset: Call
    set_cpus_allowed_ptr() with appropriate mask for task") introduced a bug
    that corrupted "cpuset.cpus" of a partition root when it was updated.
    
    It is because the tmp->new_cpus field of the passed tmp parameter
    of update_parent_subparts_cpumask() should not be used at all as
    it contains important cpumask data that should not be overwritten.
    Fix it by using tmp->addmask instead.
    
    Also update update_cpumask() to make sure that trialcs->cpu_allowed
    will not be corrupted until it is no longer needed.
    
    Fixes: 7a2127e66a00 ("cpuset: Call set_cpus_allowed_ptr() with appropriate mask for task")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Cc: stable@vger.kernel.org # v6.2+
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daea92f089485d04e6a2fe35e2f89e4369232039
Author: Josh Don <joshdon@google.com>
Date:   Wed Mar 15 14:40:29 2023 -0700

    cgroup: fix display of forceidle time at root
    
    commit fcdb1eda5302599045bb366e679cccb4216f3873 upstream.
    
    We need to reset forceidle_sum to 0 when reading from root, since the
    bstat we accumulate into is stack allocated.
    
    To make this more robust, just replace the existing cputime reset with a
    memset of the overall bstat.
    
    Signed-off-by: Josh Don <joshdon@google.com>
    Fixes: 1fcf54deb767 ("sched/core: add forced idle accounting for cgroups")
    Cc: stable@vger.kernel.org # v6.0+
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fdbf3f618fe9c411dad36d0ba2132beb20a2a5e
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Wed Mar 29 22:58:59 2023 +0530

    x86/PCI: Add quirk for AMD XHCI controller that loses MSI-X state in D3hot
    
    commit f195fc1e9715ba826c3b62d58038f760f66a4fe9 upstream.
    
    The AMD [1022:15b8] USB controller loses some internal functional MSI-X
    context when transitioning from D0 to D3hot. BIOS normally traps D0->D3hot
    and D3hot->D0 transitions so it can save and restore that internal context,
    but some firmware in the field can't do this because it fails to clear the
    AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit.
    
    Clear AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit before USB controller
    initialization during boot.
    
    Link: https://lore.kernel.org/linux-usb/Y%2Fz9GdHjPyF2rNG3@glanzmann.de/T/#u
    Link: https://lore.kernel.org/r/20230329172859.699743-1-Basavaraj.Natikar@amd.com
    Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
    Tested-by: Thomas Glanzmann <thomas@glanzmann.de>
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 536ec28220832e84cb2c7c7b92dc14fa2381e01e
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Wed Mar 29 13:13:11 2023 -0700

    PCI/MSI: Provide missing stub for pci_msix_can_alloc_dyn()
    
    commit 195d8e5da3acb17c5357526494f818a21e97cd10 upstream.
    
    pci_msix_can_alloc_dyn() is not declared when CONFIG_PCI_MSI is disabled.
    
    There is no existing user of pci_msix_can_alloc_dyn() but work is in
    progress to change this. This work encounters the following error when
    CONFIG_PCI_MSI is disabled:
    
      drivers/vfio/pci/vfio_pci_intrs.c:427:21: error: implicit declaration of function 'pci_msix_can_alloc_dyn' [-Werror=implicit-function-declaration]
    
    Provide definition for pci_msix_can_alloc_dyn() in preparation for users
    that need to compile when CONFIG_PCI_MSI is disabled.
    
    [bhelgaas: Also reported by Arnd Bergmann <arnd@kernel.org> in
    drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c; added his Fixes: line]
    
    Fixes: fb0a6a268dcd ("net/mlx5: Provide external API for allocating vectors")
    Fixes: 34026364df8e ("PCI/MSI: Provide post-enable dynamic allocation interfaces for MSI-X")
    Link: https://lore.kernel.org/oe-kbuild-all/202303291000.PWFqGCxH-lkp@intel.com/
    Link: https://lore.kernel.org/r/310ecc4815dae4174031062f525245f0755c70e2.1680119924.git.reinette.chatre@intel.com
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Cc: stable@vger.kernel.org      # v6.2+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07a75c0050e59c50f038cc5f4e2a3258c8f8c9d0
Author: Rob Herring <robh@kernel.org>
Date:   Wed Mar 29 07:38:35 2023 -0500

    PCI: Fix use-after-free in pci_bus_release_domain_nr()
    
    commit 30ba2d09edb5ea857a1473ae3d820911347ada62 upstream.
    
    Commit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")
    introduced a use-after-free bug in the bus removal cleanup. The issue was
    found with kfence:
    
      [   19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70
    
      [   19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115):
      [   19.309677]  pci_bus_release_domain_nr+0x10/0x70
      [   19.309691]  dw_pcie_host_deinit+0x28/0x78
      [   19.309702]  tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]
      [   19.309734]  tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]
      [   19.309752]  platform_probe+0x90/0xd8
      ...
    
      [   19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k
    
      [   19.311469] allocated by task 96 on cpu 10 at 19.279323s:
      [   19.311562]  __kmem_cache_alloc_node+0x260/0x278
      [   19.311571]  kmalloc_trace+0x24/0x30
      [   19.311580]  pci_alloc_bus+0x24/0xa0
      [   19.311590]  pci_register_host_bridge+0x48/0x4b8
      [   19.311601]  pci_scan_root_bus_bridge+0xc0/0xe8
      [   19.311613]  pci_host_probe+0x18/0xc0
      [   19.311623]  dw_pcie_host_init+0x2c0/0x568
      [   19.311630]  tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194]
      [   19.311647]  platform_probe+0x90/0xd8
      ...
    
      [   19.311782] freed by task 96 on cpu 10 at 19.285833s:
      [   19.311799]  release_pcibus_dev+0x30/0x40
      [   19.311808]  device_release+0x30/0x90
      [   19.311814]  kobject_put+0xa8/0x120
      [   19.311832]  device_unregister+0x20/0x30
      [   19.311839]  pci_remove_bus+0x78/0x88
      [   19.311850]  pci_remove_root_bus+0x5c/0x98
      [   19.311860]  dw_pcie_host_deinit+0x28/0x78
      [   19.311866]  tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]
      [   19.311883]  tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]
      [   19.311900]  platform_probe+0x90/0xd8
      ...
    
      [   19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4
      [   19.320171] Hardware name:  /, BIOS 1.0-d7fb19b 08/10/2022
      [   19.325852] Workqueue: events_unbound deferred_probe_work_func
    
    The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't
    directly call pci_bus_release_domain_nr(). The issue turns out to be in
    pci_remove_root_bus() which first calls pci_remove_bus() which frees the
    struct pci_bus when its struct device is released. Then
    pci_bus_release_domain_nr() is called and accesses the freed struct
    pci_bus. Reordering these fixes the issue.
    
    Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")
    Link: https://lore.kernel.org/r/20230329123835.2724518-1-robh@kernel.org
    Link: https://lore.kernel.org/r/b529cb69-0602-9eed-fc02-2f068707a006@nvidia.com
    Reported-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Cc: stable@vger.kernel.org      # v6.2+
    Cc: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73e4995ea2719b1819c85c6c463246d7b34a4fa3
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Apr 7 17:12:15 2023 +0800

    drm/amd/pm: correct the pcie link state check for SMU13
    
    commit b9a24d8bd51e2db425602fa82d7f4c06aa3db852 upstream.
    
    Update the driver implementations to fit those data exposed
    by PMFW.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ed054d277b56e0b2d63557598eb1a7642488214
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Mon Apr 10 10:35:01 2023 -0700

    thermal: intel: Avoid updating unsupported THERM_STATUS_CLEAR mask bits
    
    commit 117e4e5bd9d47b89777dbf6b37a709dcfe59520f upstream.
    
    Some older processors don't allow BIT(13) and BIT(15) in the current
    mask set by "THERM_STATUS_CLEAR_CORE_MASK". This results in:
    
    unchecked MSR access error: WRMSR to 0x19c (tried to
    write 0x000000000000aaa8) at rIP: 0xffffffff816f66a6
    (throttle_active_work+0xa6/0x1d0)
    
    To avoid unchecked MSR issues, check CPUID for each relevant feature and
    use that information to set the supported feature bits only in the
    "clear" mask for cores. Do the same for the analogous package mask set
    by "THERM_STATUS_CLEAR_PKG_MASK".
    
    Introduce functions thermal_intr_init_core_clear_mask() and
    thermal_intr_init_pkg_clear_mask() to set core and package mask bits,
    respectively. These functions are called during initialization.
    
    Fixes: 6fe1e64b6026 ("thermal: intel: Prevent accidental clearing of HFI status")
    Reported-by: Rui Salvaterra <rsalvaterra@gmail.com>
    Link: https://lore.kernel.org/lkml/cdf43fb423368ee3994124a9e8c9b4f8d00712c6.camel@linux.intel.com/T/
    Tested-by: Rui Salvaterra <rsalvaterra@gmail.com>
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: 6.2+ <stable@kernel.org> # 6.2+
    [ rjw: Renamed 2 funtions and 2 static variables, edited subject and
      changelog ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eabc4872f172ecb8dd8536bc366a51868154a450
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Apr 4 21:23:42 2023 +0200

    scsi: ses: Handle enclosure with just a primary component gracefully
    
    commit c8e22b7a1694bb8d025ea636816472739d859145 upstream.
    
    This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure
    has no components") and introduces proper handling of case where there are
    no detected secondary components, but primary component (enumerated in
    num_enclosures) does exist. That fix was originally proposed by Ding Hui
    <dinghui@sangfor.com.cn>.
    
    Completely ignoring devices that have one primary enclosure and no
    secondary one results in ses_intf_add() bailing completely
    
            scsi 2:0:0:254: enclosure has no enumerated components
            scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such
    
    even on valid configurations with 1 primary and 0 secondary enclosures as
    below:
    
            # sg_ses /dev/sg0
              3PARdata  SES               3321
            Supported diagnostic pages:
              Supported Diagnostic Pages [sdp] [0x0]
              Configuration (SES) [cf] [0x1]
              Short Enclosure Status (SES) [ses] [0x8]
            # sg_ses -p cf /dev/sg0
              3PARdata  SES               3321
            Configuration diagnostic page:
              number of secondary subenclosures: 0
              generation code: 0x0
              enclosure descriptor list
                Subenclosure identifier: 0 [primary]
                  relative ES process id: 0, number of ES processes: 1
                  number of type descriptor headers: 1
                  enclosure logical identifier (hex): 20000002ac02068d
                  enclosure vendor: 3PARdata  product: VV                rev: 3321
              type descriptor header and text list
                Element type: Unspecified, subenclosure id: 0
                  number of possible elements: 1
    
    The changelog for the original fix follows
    
    =====
    We can get a crash when disconnecting the iSCSI session,
    the call trace like this:
    
      [ffff00002a00fb70] kfree at ffff00000830e224
      [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4
      [ffff00002a00fbd0] device_del at ffff0000086b6a98
      [ffff00002a00fc50] device_unregister at ffff0000086b6d58
      [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c
      [ffff00002a00fca0] scsi_remove_device at ffff000008706134
      [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4
      [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0
      [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4
      [ffff00002a00fdb0] process_one_work at ffff00000810f35c
      [ffff00002a00fe00] worker_thread at ffff00000810f648
      [ffff00002a00fe70] kthread at ffff000008116e98
    
    In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,
    but not saved in edev->component[i].scratch
    
    In this situation, edev->component[0].scratch is an invalid pointer,
    when kfree it in ses_intf_remove_enclosure, a crash like above would happen
    The call trace also could be other random cases when kfree cannot catch
    the invalid pointer
    
    We should not use edev->component[] array when the components count is 0
    We also need check index when use edev->component[] array in
    ses_enclosure_data_process
    =====
    
    Reported-by: Michal Kolar <mich.k@seznam.cz>
    Originally-by: Ding Hui <dinghui@sangfor.com.cn>
    Cc: stable@vger.kernel.org
    Fixes: 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components")
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2304042122270.29760@cbobk.fhfr.pm
    Tested-by: Michal Kolar <mich.k@seznam.cz>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 281b194b488154e51ee569509bc47a62dcc6a63b
Author: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com>
Date:   Thu Apr 6 12:59:53 2023 +0300

    net: phy: nxp-c45-tja11xx: fix unsigned long multiplication overflow
    
    commit bdaaecc127d471c422ee9e994978617c8aa79e1e upstream.
    
    Any multiplication between GENMASK(31, 0) and a number bigger than 1
    will be truncated because of the overflow, if the size of unsigned long
    is 32 bits.
    
    Replaced GENMASK with GENMASK_ULL to make sure that multiplication will
    be between 64 bits values.
    
    Cc: <stable@vger.kernel.org> # 5.15+
    Fixes: 514def5dd339 ("phy: nxp-c45-tja11xx: add timestamping support")
    Signed-off-by: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20230406095953.75622-1-radu-nicolae.pirea@oss.nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a614f988f48edd4939e0c9c65a10959159d93772
Author: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com>
Date:   Thu Apr 6 12:59:04 2023 +0300

    net: phy: nxp-c45-tja11xx: add remove callback
    
    commit a4506722dc39ca840593f14e3faa4c9ba9408211 upstream.
    
    Unregister PTP clock when the driver is removed.
    Purge the RX and TX skb queues.
    
    Fixes: 514def5dd339 ("phy: nxp-c45-tja11xx: add timestamping support")
    CC: stable@vger.kernel.org # 5.15+
    Signed-off-by: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20230406095904.75456-1-radu-nicolae.pirea@oss.nxp.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 837a5780580796a0d3868de99e0485b12d3c478a
Author: Ivan Bornyakov <i.bornyakov@metrotek.ru>
Date:   Thu Apr 6 16:08:32 2023 +0300

    net: sfp: initialize sfp->i2c_block_size at sfp allocation
    
    commit 813c2dd78618f108fdcf9cd726ea90f081ee2881 upstream.
    
    sfp->i2c_block_size is initialized at SFP module insertion in
    sfp_sm_mod_probe(). Because of that, if SFP module was never inserted
    since boot, sfp_read() call will lead to zero-length I2C read attempt,
    and not all I2C controllers are happy with zero-length reads.
    
    One way to issue sfp_read() on empty SFP cage is to execute ethtool -m.
    If SFP module was never plugged since boot, there will be a zero-length
    I2C read attempt.
    
      # ethtool -m xge0
      i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read)
      Cannot get Module EEPROM data: Operation not supported
    
    If SFP module was plugged then removed at least once,
    sfp->i2c_block_size will be initialized and ethtool -m will fail with
    different exit code and without I2C error
    
      # ethtool -m xge0
      Cannot get Module EEPROM data: Remote I/O error
    
    Fix this by initializing sfp->i2_block_size at struct sfp allocation
    stage so no wild sfp_read() could issue zero-length I2C read.
    
    Signed-off-by: Ivan Bornyakov <i.bornyakov@metrotek.ru>
    Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround")
    Cc: stable@vger.kernel.org
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45b9055a3a3ff6e8c08faad82ea36a8644a81587
Author: Tanu Malhotra <tanu.malhotra@intel.com>
Date:   Mon Mar 27 11:58:38 2023 -0700

    HID: intel-ish-hid: Fix kernel panic during warm reset
    
    commit 38518593ec55e897abda4b4be77b2ec8ec4447d1 upstream.
    
    During warm reset device->fw_client is set to NULL. If a bus driver is
    registered after this NULL setting and before new firmware clients are
    enumerated by ISHTP, kernel panic will result in the function
    ishtp_cl_bus_match(). This is because of reference to
    device->fw_client->props.protocol_name.
    
    ISH firmware after getting successfully loaded, sends a warm reset
    notification to remove all clients from the bus and sets
    device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel
    module drivers were loaded right after any of the first ISHTP device was
    registered, regardless of whether it was a matched or an unmatched
    device. This resulted in all drivers getting registered much before the
    warm reset notification from ISH.
    
    Starting kernel v5.16, this issue got exposed after the change was
    introduced to load only bus drivers for the respective matching devices.
    In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are
    registered after the warm reset device fw_client NULL setting.
    cros_ec_ishtp driver_register() triggers the callback to
    ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel
    panic in guid_equal() when dereferencing fw_client NULL pointer to get
    protocol_name.
    
    Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices")
    Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices")
    Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices")
    Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices")
    Cc: <stable@vger.kernel.org> # 5.16+
    Signed-off-by: Tanu Malhotra <tanu.malhotra@intel.com>
    Tested-by: Shaunak Saha <shaunak.saha@intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ab83ce0a0f95c612f3f6d81c1c7d725e938c4e2
Author: Mathis Salmen <mathis.salmen@matsal.de>
Date:   Thu Apr 6 12:11:31 2023 +0200

    riscv: add icache flush for nommu sigreturn trampoline
    
    commit 8d736482749f6d350892ef83a7a11d43cd49981e upstream.
    
    In a NOMMU kernel, sigreturn trampolines are generated on the user
    stack by setup_rt_frame. Currently, these trampolines are not instruction
    fenced, thus their visibility to ifetch is not guaranteed.
    
    This patch adds a flush_icache_range in setup_rt_frame to fix this
    problem.
    
    Signed-off-by: Mathis Salmen <mathis.salmen@matsal.de>
    Fixes: 6bd33e1ece52 ("riscv: add nommu support")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230406101130.82304-1-mathis.salmen@matsal.de
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f02edb9debbd36f44efa7567031485892c7df60d
Author: David Disseldorp <ddiss@suse.de>
Date:   Thu Apr 13 23:49:57 2023 +0900

    ksmbd: avoid out of bounds access in decode_preauth_ctxt()
    
    commit e7067a446264a7514fa1cfaa4052cdb6803bc6a2 upstream.
    
    Confirm that the accessed pneg_ctxt->HashAlgorithms address sits within
    the SMB request boundary; deassemble_neg_contexts() only checks that the
    eight byte smb2_neg_context header + (client controlled) DataLength are
    within the packet boundary, which is insufficient.
    
    Checking for sizeof(struct smb2_preauth_neg_context) is overkill given
    that the type currently assumes SMB311_SALT_SIZE bytes of trailing Salt.
    
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2780b421b8da4b2032b0769636851d608ac72125
Author: Liam R. Howlett <Liam.Howlett@oracle.com>
Date:   Mon Feb 27 09:36:04 2023 -0800

    maple_tree: fix write memory barrier of nodes once dead for RCU mode
    
    [ Upstream commit c13af03de46ba27674dd9fb31a17c0d480081139 ]
    
    During the development of the maple tree, the strategy of freeing multiple
    nodes changed and, in the process, the pivots were reused to store
    pointers to dead nodes.  To ensure the readers see accurate pivots, the
    writers need to mark the nodes as dead and call smp_wmb() to ensure any
    readers can identify the node as dead before using the pivot values.
    
    There were two places where the old method of marking the node as dead
    without smp_wmb() were being used, which resulted in RCU readers seeing
    the wrong pivot value before seeing the node was dead.  Fix this race
    condition by using mte_set_node_dead() which has the smp_wmb() call to
    ensure the race is closed.
    
    Add a WARN_ON() to the ma_free_rcu() call to ensure all nodes being freed
    are marked as dead to ensure there are no other call paths besides the two
    updated paths.
    
    This is necessary for the RCU mode of the maple tree.
    
    Link: https://lkml.kernel.org/r/20230227173632.3292573-6-surenb@google.com
    Fixes: 54a611b60590 ("Maple Tree: add new data structure")
    Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Signed-off-by: Suren Baghdasaryan <surenb@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75f95216cfadb0fb6796b90cf42b9ea076fa0723
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Apr 4 22:21:14 2023 -0400

    tracing: Have tracing_snapshot_instance_cond() write errors to the appropriate instance
    
    [ Upstream commit 9d52727f8043cfda241ae96896628d92fa9c50bb ]
    
    If a trace instance has a failure with its snapshot code, the error
    message is to be written to that instance's buffer. But currently, the
    message is written to the top level buffer. Worse yet, it may also disable
    the top level buffer and not the instance that had the issue.
    
    Link: https://lkml.kernel.org/r/20230405022341.688730321@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Ross Zwisler <zwisler@google.com>
    Fixes: 2824f50332486 ("tracing: Make the snapshot trigger work with instances")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c55902442e9f65a21d7636ff00939349e42f9fe7
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Feb 7 12:28:52 2023 -0500

    tracing: Add trace_array_puts() to write into instance
    
    [ Upstream commit d503b8f7474fe7ac616518f7fc49773cbab49f36 ]
    
    Add a generic trace_array_puts() that can be used to "trace_puts()" into
    an allocated trace_array instance. This is just another variant of
    trace_array_printk().
    
    Link: https://lkml.kernel.org/r/20230207173026.584717290@goodmis.org
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Ross Zwisler <zwisler@google.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Stable-dep-of: 9d52727f8043 ("tracing: Have tracing_snapshot_instance_cond() write errors to the appropriate instance")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9bef87b35f9ee964a7cd5439f3a6be28343d882
Author: Aymeric Wibo <obiwac@gmail.com>
Date:   Sun Mar 19 03:12:05 2023 +0100

    ACPI: resource: Add Medion S17413 to IRQ override quirk
    
    [ Upstream commit 2d0ab14634a26e54f8d6d231b47b7ef233e84599 ]
    
    Add DMI info of the Medion S17413 (board M1xA) to the IRQ override
    quirk table. This fixes the keyboard not working on these laptops.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=213031
    Signed-off-by: Aymeric Wibo <obiwac@gmail.com>
    [ rjw: Fixed up white space ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b934a3752fbcc7c7791e504f9d8df787b37678e6
Author: Jane Jian <Jane.Jian@amd.com>
Date:   Wed Mar 15 18:59:59 2023 +0800

    drm/amdgpu/gfx: set cg flags to enter/exit safe mode
    
    [ Upstream commit e06bfcc1a1c41bcb8c31470d437e147ce9f0acfd ]
    
    sriov needs to enter/exit safe mode in update umd p state
    add the cg flag to let it enter or exit while needed
    
    Signed-off-by: Jane Jian <Jane.Jian@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d711999534c40d9d7501cf4d9a94d6256e521d37
Author: YuBiao Wang <YuBiao.Wang@amd.com>
Date:   Thu Mar 16 11:30:32 2023 +0800

    drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobs
    
    [ Upstream commit 033c56474acf567a450f8bafca50e0b610f2b716 ]
    
    [Why]
    For engines not supporting soft reset, i.e. VCN, there will be a failed
    ib test before mode 1 reset during asic reset. The fences in this case
    are never signaled and next time when we try to free the sa_bo, kernel
    will hang.
    
    [How]
    During pre_asic_reset, driver will clear job fences and afterwards the
    fences' refcount will be reduced to 1. For drm_sched_jobs it will be
    released in job_free_cb, and for non-sched jobs like ib_test, it's meant
    to be released in sa_bo_free but only when the fences are signaled. So
    we have to force signal the non_sched bad job's fence during
    pre_asic_reset or the clear is not complete.
    
    Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com>
    Acked-by: Luben Tuikov <luben.tuikov@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3283aaa2f16960c707141f27d80827842f933fe4
Author: Tong Liu01 <Tong.Liu01@amd.com>
Date:   Wed Mar 15 15:24:22 2023 +0800

    drm/amdgpu: add mes resume when do gfx post soft reset
    
    [ Upstream commit 4eb0b49a0ad3e004a6a65b84efe37bc7e66d560f ]
    
    [why]
    when gfx do soft reset, mes will also do reset, if mes is not
    resumed when do recover from soft reset, mes is unable to respond
    in later sequence
    
    [how]
    resume mes when do gfx post soft reset
    
    Signed-off-by: Tong Liu01 <Tong.Liu01@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b887692194d9f20695a11be44565aaefd4a9ca3
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Mar 17 10:53:25 2023 +0100

    wifi: iwlwifi: mvm: protect TXQ list manipulation
    
    [ Upstream commit 923bf981eb6ecc027227716e30701bdcc1845fbf ]
    
    Some recent upstream debugging uncovered the fact that in
    iwlwifi, the TXQ list manipulation is racy.
    
    Introduce a new state bit for when the TXQ is completely
    ready and can be used without locking, and if that's not
    set yet acquire the lock to check everything correctly.
    
    Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
    Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ce198c6d2b65f94b7ea605c660db3a363771c45
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Mar 17 10:53:24 2023 +0100

    wifi: iwlwifi: mvm: fix mvmtxq->stopped handling
    
    [ Upstream commit b58e3d4311b54b6dd0e37165277965da0c9eb21d ]
    
    This could race if the queue is redirected while full, then
    the flushing internally would start it while it's not yet
    usable again. Fix it by using two state bits instead of just
    one.
    
    Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
    Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df7f6ad627e74d4ef183039d0b4ca36d40123bb3
Author: Martin George <martinus.gpy@gmail.com>
Date:   Thu Mar 16 17:20:09 2023 +0530

    nvme: send Identify with CNS 06h only to I/O controllers
    
    [ Upstream commit def84ab600b71ea3fcc422a876d5d0d0daa7d4f3 ]
    
    Identify CNS 06h (I/O Command Set Specific Identify Controller data
    structure) is supported only on i/o controllers.
    
    But nvme_init_non_mdts_limits() currently invokes this on all
    controllers.  Correct this by ensuring this is sent to I/O
    controllers only.
    
    Signed-off-by: Martin George <marting@netapp.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eafbf572be0bad7dc863e7b97eff10dd32227637
Author: Robbie Harwood <rharwood@redhat.com>
Date:   Mon Feb 20 12:12:54 2023 -0500

    asymmetric_keys: log on fatal failures in PE/pkcs7
    
    [ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]
    
    These particular errors can be encountered while trying to kexec when
    secureboot lockdown is in place.  Without this change, even with a
    signed debug build, one still needs to reboot the machine to add the
    appropriate dyndbg parameters (since lockdown blocks debugfs).
    
    Accordingly, upgrade all pr_debug() before fatal error into pr_warn().
    
    Signed-off-by: Robbie Harwood <rharwood@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Jarkko Sakkinen <jarkko@kernel.org>
    cc: Eric Biederman <ebiederm@xmission.com>
    cc: Herbert Xu <herbert@gondor.apana.org.au>
    cc: keyrings@vger.kernel.org
    cc: linux-crypto@vger.kernel.org
    cc: kexec@lists.infradead.org
    Link: https://lore.kernel.org/r/20230220171254.592347-3-rharwood@redhat.com/ # v2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb4cb0b3898eefed656903da14815e697ac1e819
Author: Robbie Harwood <rharwood@redhat.com>
Date:   Mon Feb 20 12:12:53 2023 -0500

    verify_pefile: relax wrapper length check
    
    [ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
    
    The PE Format Specification (section "The Attribute Certificate Table
    (Image Only)") states that `dwLength` is to be rounded up to 8-byte
    alignment when used for traversal.  Therefore, the field is not required
    to be an 8-byte multiple in the first place.
    
    Accordingly, pesign has not performed this alignment since version
    0.110.  This causes kexec failure on pesign'd binaries with "PEFILE:
    Signature wrapper len wrong".  Update the comment and relax the check.
    
    Signed-off-by: Robbie Harwood <rharwood@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Jarkko Sakkinen <jarkko@kernel.org>
    cc: Eric Biederman <ebiederm@xmission.com>
    cc: Herbert Xu <herbert@gondor.apana.org.au>
    cc: keyrings@vger.kernel.org
    cc: linux-crypto@vger.kernel.org
    cc: kexec@lists.infradead.org
    Link: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-attribute-certificate-table-image-only
    Link: https://github.com/rhboot/pesign
    Link: https://lore.kernel.org/r/20230220171254.592347-2-rharwood@redhat.com/ # v2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1773185a0a87006c1be78a978d9dd61aa7a33db8
Author: Tianyi Jing <jingfelix@hust.edu.cn>
Date:   Sat Mar 18 22:38:51 2023 +0800

    hwmon: (xgene) Fix ioremap and memremap leak
    
    [ Upstream commit 813cc94c7847ae4a17e9f744fb4dbdf7df6bd732 ]
    
    Smatch reports:
    
    drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:
    'ctx->pcc_comm_addr' from ioremap() not released on line: 757.
    
    This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),
    ioremap and memremap is not released, which may cause a leak.
    
    To fix this, ioremap and memremap is modified to devm_ioremap and
    devm_memremap.
    
    Signed-off-by: Tianyi Jing <jingfelix@hust.edu.cn>
    Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
    Link: https://lore.kernel.org/r/20230318143851.2191625-1-jingfelix@hust.edu.cn
    [groeck: Fixed formatting and subject]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a5054535d7b67fc2e397645ba97cd1b9364d467
Author: Iwona Winiarska <iwona.winiarska@intel.com>
Date:   Tue Mar 21 10:04:10 2023 +0100

    hwmon: (peci/cputemp) Fix miscalculated DTS for SKX
    
    [ Upstream commit 2b91c4a870c9830eaf95e744454c9c218cccb736 ]
    
    For Skylake, DTS temperature of the CPU is reported in S10.6 format
    instead of S8.8.
    
    Reported-by: Paul Fertser <fercerpav@gmail.com>
    Link: https://lore.kernel.org/lkml/ZBhHS7v+98NK56is@home.paul.comp/
    Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
    Link: https://lore.kernel.org/r/20230321090410.866766-1-iwona.winiarska@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 412343a15f75092c017d2e853733ca251efadefb
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Mar 1 10:52:18 2023 +0100

    drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F
    
    [ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ]
    
    Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
    X90F/L has a portrait 1200x1920 screen used in landscape mode,
    add a quirk for this.
    
    When the quirk for the X91F/L was initially added it was written to
    also apply to the X90F/L but this does not work because the Android
    version of the Yoga Book uses completely different DMI strings.
    Also adjust the X91F/L quirk to reflect that it only applies to
    the X91F/L models.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3ffa6723766c87c1a8b87bc61eee89245341892
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Mar 20 16:59:46 2023 +0100

    ACPI: video: Add backlight=native DMI quirk for Acer Aspire 3830TG
    
    [ Upstream commit 5e7a3bf65db57461d0f47955248fcadf37321a74 ]
    
    The Acer Aspire 3830TG predates Windows 8, so it defaults to using
    acpi_video# for backlight control, but this is non functional on
    this model.
    
    Add a DMI quirk to use the native backlight interface which does
    work properly.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 184cfeeb8e881220e0f18cacbb006bde53e050c2
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Mar 18 22:12:31 2023 +0800

    block: ublk_drv: mark device as LIVE before adding disk
    
    [ Upstream commit 4985e7b2c002eb4c5c794a1d3acd91b82c89a0fd ]
    
    IO can be started before add_disk() returns, such as reading parititon table,
    then the monitor work should work for making forward progress.
    
    So mark device as LIVE before adding disk, meantime change to
    DEAD if add_disk() fails.
    
    Fixed: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
    Reviewed-by: Ziyang Zhang <ZiyangZhang@linux.alibaba.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20230318141231.55562-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b716dc52bf022e43c5ecb257c7c0edeb72d3ed9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Mar 14 13:31:03 2023 +0100

    efi: sysfb_efi: Add quirk for Lenovo Yoga Book X91F/L
    
    [ Upstream commit 5ed213dd64681f84a01ceaa82fb336cf7d59ddcf ]
    
    Another Lenovo convertable which reports a landscape resolution of
    1920x1200 with a pitch of (1920 * 4) bytes, while the actual framebuffer
    has a resolution of 1200x1920 with a pitch of (1200 * 4) bytes.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b025e0fd487ae9accd44113334b8ae077ef791bb
Author: Yicong Yang <yangyicong@hisilicon.com>
Date:   Mon Mar 13 15:45:51 2023 +0800

    i2c: hisi: Avoid redundant interrupts
    
    [ Upstream commit cc9812a3096d1986caca9a23bee99effc45c08df ]
    
    After issuing all the messages we can disable the TX_EMPTY interrupts
    to avoid handling redundant interrupts. For doing a sinlge bus
    detection (i2cdetect -y -r 0) we can reduce ~97% interrupts (before
    ~12000 after ~400).
    
    Signed-off-by: Sheng Feng <fengsheng5@huawei.com>
    Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2fcd6923a3345f74156cba73806e304d35bea41
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jan 30 16:32:46 2023 +0100

    i2c: imx-lpi2c: clean rx/tx buffers upon new message
    
    [ Upstream commit 987dd36c0141f6ab9f0fbf14d6b2ec3342dedb2f ]
    
    When start sending a new message clear the Rx & Tx buffer pointers in
    order to avoid using stale pointers.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e80b541d9682192c92630f7bd6424fec828070d
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Mar 12 14:25:23 2023 +0100

    wifi: mwifiex: mark OF related data as maybe unused
    
    [ Upstream commit 139f6973bf140c65d4d1d4bde5485badb4454d7a ]
    
    The driver can be compile tested with !CONFIG_OF making certain data
    unused:
    
      drivers/net/wireless/marvell/mwifiex/sdio.c:498:34: error: ‘mwifiex_sdio_of_match_table’ defined but not used [-Werror=unused-const-variable=]
      drivers/net/wireless/marvell/mwifiex/pcie.c:175:34: error: ‘mwifiex_pcie_of_match_table’ defined but not used [-Werror=unused-const-variable=]
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230312132523.352182-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb484ba17bf9db34ea4f5a3c2157865b45c258f9
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Fri Mar 10 12:41:18 2023 -0800

    selftests/bpf: Fix progs/find_vma_fail1.c build error.
    
    [ Upstream commit 32513d40d908b267508d37994753d9bd1600914b ]
    
    The commit 11e456cae91e ("selftests/bpf: Fix compilation errors: Assign a value to a constant")
    fixed the issue cleanly in bpf-next.
    This is an alternative fix in bpf tree to avoid merge conflict between bpf and bpf-next.
    
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dfda8e24c52b6d2a54b50b35af0cda0dca55081
Author: Denis Arefev <arefev@swemel.ru>
Date:   Tue Dec 6 12:17:23 2022 +0300

    power: supply: axp288_fuel_gauge: Added check for negative values
    
    [ Upstream commit bf6c880d5d1448489ebf92e2d13d5713ff644930 ]
    
    Variable 'pirq', which may receive negative value
    in platform_get_irq().
    Used as an index in a function regmap_irq_get_virq().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Denis Arefev <arefev@swemel.ru>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 339638dccde5f524ede19d956e292e47f856aa27
Author: Grant Grundler <grundler@chromium.org>
Date:   Mon Dec 12 13:38:57 2022 -0800

    power: supply: cros_usbpd: reclassify "default case!" as debug
    
    [ Upstream commit 14c76b2e75bca4d96e2b85a0c12aa43e84fe3f74 ]
    
    This doesn't need to be printed every second as an error:
    ...
    <3>[17438.628385] cros-usbpd-charger cros-usbpd-charger.3.auto: Port 1: default case!
    <3>[17439.634176] cros-usbpd-charger cros-usbpd-charger.3.auto: Port 1: default case!
    <3>[17440.640298] cros-usbpd-charger cros-usbpd-charger.3.auto: Port 1: default case!
    ...
    
    Reduce priority from ERROR to DEBUG.
    
    Signed-off-by: Grant Grundler <grundler@chromium.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c453cc38d1ef81c624babe5ff1565f1f0963fd9a
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Wed Dec 14 11:23:16 2022 +0800

    power: supply: rk817: Fix unsigned comparison with less than zero
    
    [ Upstream commit 3268a4d9b0b85a4382e93bdf7be5400a73db74c5 ]
    
    The tmp is defined as u32 type, which results in invalid processing of
    tmp<0 in function rk817_read_or_set_full_charge_on_boot(). Therefore,
    drop the comparison.
    
    drivers/power/supply/rk817_charger.c:828 rk817_read_or_set_full_charge_on_boot() warn: unsigned 'tmp' is never less than zero.
    drivers/power/supply/rk817_charger.c:788 rk817_read_or_set_full_charge_on_boot() warn: unsigned 'tmp' is never less than zero.
    
    Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3444
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Tested-by: Chris Morgan <macromorgan@hotmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3c18eee53694994b1811d8ddc1559cbe753c49d
Author: Brian Masney <bmasney@redhat.com>
Date:   Tue Mar 7 18:23:40 2023 -0500

    arm64: dts: qcom: sa8540p-ride: correct name of remoteproc_nsp0 firmware
    
    [ Upstream commit b891251b40d4dc4cfd28341f62f6784c02ad3a78 ]
    
    The cdsp.mbn firmware that's referenced in sa8540p-ride.dts is actually
    named cdsp0.mbn in the deliverables from Qualcomm. Let's go ahead and
    correct the name to match what's in Qualcomm's deliverable.
    
    Signed-off-by: Brian Masney <bmasney@redhat.com>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230307232340.2370476-1-bmasney@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc6e7d364cc37b677c8e4477ce2c1e2a3005ec92
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Wed Mar 8 22:06:03 2023 +0100

    ARM: dts: qcom: apq8026-lg-lenok: add missing reserved memory
    
    [ Upstream commit ecd240875e877d78fd03efbc62292f550872df3f ]
    
    Turns out these two memory regions also need to be avoided, otherwise
    weird things will happen when Linux tries to use this memory.
    
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230308-lenok-reserved-memory-v1-1-b8bf6ff01207@z3ntu.xyz
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe9c782f2852a4cb8c879e1c08f3d7f7901beba2
Author: Andrew Jeffery <andrew@aj.id.au>
Date:   Wed Feb 22 00:10:14 2023 +0100

    ARM: 9290/1: uaccess: Fix KASAN false-positives
    
    [ Upstream commit ceac10c83b330680cc01ceaaab86cd49f4f30d81 ]
    
    __copy_to_user_memcpy() and __clear_user_memset() had been calling
    memcpy() and memset() respectively, leading to false-positive KASAN
    reports when starting userspace:
    
        [   10.707901] Run /init as init process
        [   10.731892] process '/bin/busybox' started with executable stack
        [   10.745234] ==================================================================
        [   10.745796] BUG: KASAN: user-memory-access in __clear_user_memset+0x258/0x3ac
        [   10.747260] Write of size 2687 at addr 000de581 by task init/1
    
    Use __memcpy() and __memset() instead to allow userspace access, which
    is of course the intent of these functions.
    
    Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f692c992a3bb9a8018e3488098b401a4229e7ec
Author: Liang Chen <liangchen.linux@gmail.com>
Date:   Thu Apr 13 17:03:53 2023 +0800

    skbuff: Fix a race between coalescing and releasing SKBs
    
    [ Upstream commit 0646dc31ca886693274df5749cd0c8c1eaaeb5ca ]
    
    Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment
    recycling") allowed coalescing to proceed with non page pool page and page
    pool page when @from is cloned, i.e.
    
    to->pp_recycle    --> false
    from->pp_recycle  --> true
    skb_cloned(from)  --> true
    
    However, it actually requires skb_cloned(@from) to hold true until
    coalescing finishes in this situation. If the other cloned SKB is
    released while the merging is in process, from_shinfo->nr_frags will be
    set to 0 toward the end of the function, causing the increment of frag
    page _refcount to be unexpectedly skipped resulting in inconsistent
    reference counts. Later when SKB(@to) is released, it frees the page
    directly even though the page pool page is still in use, leading to
    use-after-free or double-free errors. So it should be prohibited.
    
    The double-free error message below prompted us to investigate:
    BUG: Bad page state in process swapper/1  pfn:0e0d1
    page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000
    index:0x2 pfn:0xe0d1
    flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
    raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000
    raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000
    page dumped because: nonzero _refcount
    
    CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E      6.2.0+
    Call Trace:
     <IRQ>
    dump_stack_lvl+0x32/0x50
    bad_page+0x69/0xf0
    free_pcp_prepare+0x260/0x2f0
    free_unref_page+0x20/0x1c0
    skb_release_data+0x10b/0x1a0
    napi_consume_skb+0x56/0x150
    net_rx_action+0xf0/0x350
    ? __napi_schedule+0x79/0x90
    __do_softirq+0xc8/0x2b1
    __irq_exit_rcu+0xb9/0xf0
    common_interrupt+0x82/0xa0
    </IRQ>
    <TASK>
    asm_common_interrupt+0x22/0x40
    RIP: 0010:default_idle+0xb/0x20
    
    Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool")
    Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230413090353.14448-1-liangchen.linux@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5dcf3a6843d0d7cc76960fbe8511d425f217744c
Author: Roman Gushchin <roman.gushchin@linux.dev>
Date:   Wed Apr 12 16:21:44 2023 -0700

    net: macb: fix a memory corruption in extended buffer descriptor mode
    
    [ Upstream commit e8b74453555872851bdd7ea43a7c0ec39659834f ]
    
    For quite some time we were chasing a bug which looked like a sudden
    permanent failure of networking and mmc on some of our devices.
    The bug was very sensitive to any software changes and even more to
    any kernel debug options.
    
    Finally we got a setup where the problem was reproducible with
    CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:
    
    [   16.992082] ------------[ cut here ]------------
    [   16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes]
    [   17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900
    [   17.018977] Modules linked in: xxxxx
    [   17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28
    [   17.045345] Hardware name: xxxxx
    [   17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)
    [   17.054322] pc : check_unmap+0x6a0/0x900
    [   17.058243] lr : check_unmap+0x6a0/0x900
    [   17.062163] sp : ffffffc010003c40
    [   17.065470] x29: ffffffc010003c40 x28: 000000004000c03c
    [   17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800
    [   17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8
    [   17.081407] x23: 0000000000000000 x22: ffffffc010a08750
    [   17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000
    [   17.092032] x19: 0000000875e3e244 x18: 0000000000000010
    [   17.097343] x17: 0000000000000000 x16: 0000000000000000
    [   17.102647] x15: ffffff8879e4a988 x14: 0720072007200720
    [   17.107959] x13: 0720072007200720 x12: 0720072007200720
    [   17.113261] x11: 0720072007200720 x10: 0720072007200720
    [   17.118565] x9 : 0720072007200720 x8 : 000000000000022d
    [   17.123869] x7 : 0000000000000015 x6 : 0000000000000098
    [   17.129173] x5 : 0000000000000000 x4 : 0000000000000000
    [   17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370
    [   17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000
    [   17.145082] Call trace:
    [   17.147524]  check_unmap+0x6a0/0x900
    [   17.151091]  debug_dma_unmap_page+0x88/0x90
    [   17.155266]  gem_rx+0x114/0x2f0
    [   17.158396]  macb_poll+0x58/0x100
    [   17.161705]  net_rx_action+0x118/0x400
    [   17.165445]  __do_softirq+0x138/0x36c
    [   17.169100]  irq_exit+0x98/0xc0
    [   17.172234]  __handle_domain_irq+0x64/0xc0
    [   17.176320]  gic_handle_irq+0x5c/0xc0
    [   17.179974]  el1_irq+0xb8/0x140
    [   17.183109]  xiic_process+0x5c/0xe30
    [   17.186677]  irq_thread_fn+0x28/0x90
    [   17.190244]  irq_thread+0x208/0x2a0
    [   17.193724]  kthread+0x130/0x140
    [   17.196945]  ret_from_fork+0x10/0x20
    [   17.200510] ---[ end trace 7240980785f81d6f ]---
    
    [  237.021490] ------------[ cut here ]------------
    [  237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b
    [  237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240
    [  237.041802] Modules linked in: xxxxx
    [  237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         5.4.0 #28
    [  237.068941] Hardware name: xxxxx
    [  237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)
    [  237.077900] pc : add_dma_entry+0x214/0x240
    [  237.081986] lr : add_dma_entry+0x214/0x240
    [  237.086072] sp : ffffffc010003c30
    [  237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00
    [  237.094683] x27: 0000000000000180 x26: ffffff8878e387c0
    [  237.099987] x25: 0000000000000002 x24: 0000000000000000
    [  237.105290] x23: 000000000000003b x22: ffffffc010a0fa00
    [  237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600
    [  237.115897] x19: 00000000ffffffef x18: 0000000000000010
    [  237.121201] x17: 0000000000000000 x16: 0000000000000000
    [  237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720
    [  237.131807] x13: 0720072007200720 x12: 0720072007200720
    [  237.137111] x11: 0720072007200720 x10: 0720072007200720
    [  237.142415] x9 : 0720072007200720 x8 : 0000000000000259
    [  237.147718] x7 : 0000000000000001 x6 : 0000000000000000
    [  237.153022] x5 : ffffffc010003a20 x4 : 0000000000000001
    [  237.158325] x3 : 0000000000000006 x2 : 0000000000000007
    [  237.163628] x1 : 8ac721b3a7dc1c00 x0 : 0000000000000000
    [  237.168932] Call trace:
    [  237.171373]  add_dma_entry+0x214/0x240
    [  237.175115]  debug_dma_map_page+0xf8/0x120
    [  237.179203]  gem_rx_refill+0x190/0x280
    [  237.182942]  gem_rx+0x224/0x2f0
    [  237.186075]  macb_poll+0x58/0x100
    [  237.189384]  net_rx_action+0x118/0x400
    [  237.193125]  __do_softirq+0x138/0x36c
    [  237.196780]  irq_exit+0x98/0xc0
    [  237.199914]  __handle_domain_irq+0x64/0xc0
    [  237.204000]  gic_handle_irq+0x5c/0xc0
    [  237.207654]  el1_irq+0xb8/0x140
    [  237.210789]  arch_cpu_idle+0x40/0x200
    [  237.214444]  default_idle_call+0x18/0x30
    [  237.218359]  do_idle+0x200/0x280
    [  237.221578]  cpu_startup_entry+0x20/0x30
    [  237.225493]  rest_init+0xe4/0xf0
    [  237.228713]  arch_call_rest_init+0xc/0x14
    [  237.232714]  start_kernel+0x47c/0x4a8
    [  237.236367] ---[ end trace 7240980785f81d70 ]---
    
    Lars was fast to find an explanation: according to the datasheet
    bit 2 of the rx buffer descriptor entry has a different meaning in the
    extended mode:
      Address [2] of beginning of buffer, or
      in extended buffer descriptor mode (DMA configuration register [28] = 1),
      indicates a valid timestamp in the buffer descriptor entry.
    
    The macb driver didn't mask this bit while getting an address and it
    eventually caused a memory corruption and a dma failure.
    
    The problem is resolved by explicitly clearing the problematic bit
    if hw timestamping is used.
    
    Fixes: 7b4296148066 ("net: macb: Add support for PTP timestamps in DMA descriptors")
    Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
    Co-developed-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://lore.kernel.org/r/20230412232144.770336-1-roman.gushchin@linux.dev
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ac56e2d45af612f89c36508536b5aa3692c3592
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Apr 12 11:13:06 2023 -0400

    selftests: add the missing CONFIG_IP_SCTP in net config
    
    [ Upstream commit 3a0385be133e7091cc9a9a998c7ec712bb9585db ]
    
    The selftest sctp_vrf needs CONFIG_IP_SCTP set in config
    when building the kernel, so add it.
    
    Fixes: a61bd7b9fef3 ("selftests: add a selftest for sctp vrf")
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
    Link: https://lore.kernel.org/r/61dddebc4d2dd98fe7fb145e24d4b2430e42b572.1681312386.git.lucien.xin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4588ac7f498a6b1e2cf9e30106b8a92a7c6a002
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Apr 12 13:03:08 2023 +0000

    udp6: fix potential access to stale information
    
    [ Upstream commit 1c5950fc6fe996235f1d18539b9c6b64b597f50f ]
    
    lena wang reported an issue caused by udpv6_sendmsg()
    mangling msg->msg_name and msg->msg_namelen, which
    are later read from ____sys_sendmsg() :
    
            /*
             * If this is sendmmsg() and sending to current destination address was
             * successful, remember it.
             */
            if (used_address && err >= 0) {
                    used_address->name_len = msg_sys->msg_namelen;
                    if (msg_sys->msg_name)
                            memcpy(&used_address->name, msg_sys->msg_name,
                                   used_address->name_len);
            }
    
    udpv6_sendmsg() wants to pretend the remote address family
    is AF_INET in order to call udp_sendmsg().
    
    A fix would be to modify the address in-place, instead
    of using a local variable, but this could have other side effects.
    
    Instead, restore initial values before we return from udpv6_sendmsg().
    
    Fixes: c71d8ebe7a44 ("net: Fix security_socket_sendmsg() bypass problem.")
    Reported-by: lena wang <lena.wang@mediatek.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Link: https://lore.kernel.org/r/20230412130308.1202254-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 506c9d946a12e3e19a1de2a813c6e6c57acbae57
Author: Aaron Conole <aconole@redhat.com>
Date:   Wed Apr 12 07:58:28 2023 -0400

    selftests: openvswitch: adjust datapath NL message declaration
    
    [ Upstream commit 306dc21361993f4fe50a15d4db6b1a4de5d0adb0 ]
    
    The netlink message for creating a new datapath takes an array
    of ports for the PID creation.  This shouldn't cause much issue
    but correct it for future cases where we need to do decode of
    datapath information that could include the per-cpu PID map.
    
    Fixes: 25f16c873fb1 ("selftests: add openvswitch selftest suite")
    Signed-off-by: Aaron Conole <aconole@redhat.com>
    Link: https://lore.kernel.org/r/20230412115828.3991806-1-aconole@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 632d6baf8884d803e598bf5164008d23fd9b736c
Author: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
Date:   Fri Mar 31 23:34:24 2023 -0700

    RDMA/core: Fix GID entry ref leak when create_ah fails
    
    [ Upstream commit aca3b0fa3d04b40c96934d86cc224cccfa7ea8e0 ]
    
    If AH create request fails, release sgid_attr to avoid GID entry
    referrence leak reported while releasing GID table
    
    Fixes: 1a1f460ff151 ("RDMA: Hold the sgid_attr inside the struct ib_ah/qp")
    Link: https://lore.kernel.org/r/20230401063424.342204-1-saravanan.vajravel@broadcom.com
    Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad988e9b5ff04607e624a459209e8c2d0c15fc73
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Apr 10 15:43:30 2023 -0400

    sctp: fix a potential overflow in sctp_ifwdtsn_skip
    
    [ Upstream commit 32832a2caf82663870126c5186cf8f86c8b2a649 ]
    
    Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only
    checks the pos against the end of the chunk. However, the data left for
    the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference
    it as struct sctp_ifwdtsn_skip may cause coverflow.
    
    This patch fixes it by checking the pos against "the end of the chunk -
    sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar to
    sctp_fwdtsn_skip.
    
    Fixes: 0fc2ea922c8a ("sctp: implement validate_ftsn for sctp_stream_interleave")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/2a71bffcd80b4f2c61fac6d344bb2f11c8fd74f7.1681155810.git.lucien.xin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c9ce34a6ff2c544f96ce0b088e8fd3c1b9698c4
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Mon Apr 10 09:23:52 2023 +0800

    net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()
    
    [ Upstream commit 6417070918de3bcdbe0646e7256dae58fd8083ba ]
    
    Syzbot reported a bug as following:
    
    =====================================================
    BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230
     qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230
     qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519
     qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108
     call_write_iter include/linux/fs.h:2189 [inline]
     aio_write+0x63a/0x950 fs/aio.c:1600
     io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
     __do_sys_io_submit fs/aio.c:2078 [inline]
     __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
     __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Uninit was created at:
     slab_post_alloc_hook mm/slab.h:766 [inline]
     slab_alloc_node mm/slub.c:3452 [inline]
     __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
     __do_kmalloc_node mm/slab_common.c:967 [inline]
     __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988
     kmalloc_reserve net/core/skbuff.c:492 [inline]
     __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565
     __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630
     qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446
     qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108
     call_write_iter include/linux/fs.h:2189 [inline]
     aio_write+0x63a/0x950 fs/aio.c:1600
     io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
     __do_sys_io_submit fs/aio.c:2078 [inline]
     __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
     __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)
    in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().
    But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type
    equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot
    scenario. This triggers the uninit variable access bug.
    
    Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in
    qrtr_endpoint_post() to fix the bug.
    
    Fixes: 5fdeb0d372ab ("net: qrtr: Implement outgoing flow control")
    Reported-by: syzbot+4436c9630a45820fda76@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=c14607f0963d27d5a3d5f4c8639b500909e43540
    Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230410012352.3997823-1-william.xuanziyang@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea63dd60823c227d3498f50b053332a9fe9a7120
Author: Martin Willi <martin@strongswan.org>
Date:   Tue Apr 11 09:43:19 2023 +0200

    rtnetlink: Restore RTM_NEW/DELLINK notification behavior
    
    [ Upstream commit 59d3efd27c11c59b32291e5ebc307bed2edb65ee ]
    
    The commits referenced below allows userspace to use the NLM_F_ECHO flag
    for RTM_NEW/DELLINK operations to receive unicast notifications for the
    affected link. Prior to these changes, applications may have relied on
    multicast notifications to learn the same information without specifying
    the NLM_F_ECHO flag.
    
    For such applications, the mentioned commits changed the behavior for
    requests not using NLM_F_ECHO. Multicast notifications are still received,
    but now use the portid of the requester and the sequence number of the
    request instead of zero values used previously. For the application, this
    message may be unexpected and likely handled as a response to the
    NLM_F_ACKed request, especially if it uses the same socket to handle
    requests and notifications.
    
    To fix existing applications relying on the old notification behavior,
    set the portid and sequence number in the notification only if the
    request included the NLM_F_ECHO flag. This restores the old behavior
    for applications not using it, but allows unicasted notifications for
    others.
    
    Fixes: f3a63cce1b4f ("rtnetlink: Honour NLM_F_ECHO flag in rtnl_delete_link")
    Fixes: d88e136cab37 ("rtnetlink: Honour NLM_F_ECHO flag in rtnl_newlink_create")
    Signed-off-by: Martin Willi <martin@strongswan.org>
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Acked-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://lore.kernel.org/r/20230411074319.24133-1-martin@strongswan.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34fbb7b45bae20b551dda24337c7761ca13ce69d
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Wed Apr 5 22:15:32 2023 +0900

    cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex
    
    [ Upstream commit 57dcd64c7e036299ef526b400a8d12b8a2352f26 ]
    
    syzbot is reporting circular locking dependency between cpu_hotplug_lock
    and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core
    freezer logic") replaced atomic_inc() in freezer_apply_state() with
    static_branch_inc() which holds cpu_hotplug_lock.
    
    cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex
    
      cgroup_file_write() {
        cgroup_procs_write() {
          __cgroup_procs_write() {
            cgroup_procs_write_start() {
              cgroup_attach_lock() {
                cpus_read_lock() {
                  percpu_down_read(&cpu_hotplug_lock);
                }
                percpu_down_write(&cgroup_threadgroup_rwsem);
              }
            }
            cgroup_attach_task() {
              cgroup_migrate() {
                cgroup_migrate_execute() {
                  freezer_attach() {
                    mutex_lock(&freezer_mutex);
                    (...snipped...)
                  }
                }
              }
            }
            (...snipped...)
          }
        }
      }
    
    freezer_mutex => cpu_hotplug_lock
    
      cgroup_file_write() {
        freezer_write() {
          freezer_change_state() {
            mutex_lock(&freezer_mutex);
            freezer_apply_state() {
              static_branch_inc(&freezer_active) {
                static_key_slow_inc() {
                  cpus_read_lock();
                  static_key_slow_inc_cpuslocked();
                  cpus_read_unlock();
                }
              }
            }
            mutex_unlock(&freezer_mutex);
          }
        }
      }
    
    Swap locking order by moving cpus_read_lock() in freezer_apply_state()
    to before mutex_lock(&freezer_mutex) in freezer_change_state().
    
    Reported-by: syzbot <syzbot+c39682e86c9d84152f93@syzkaller.appspotmail.com>
    Link: https://syzkaller.appspot.com/bug?extid=c39682e86c9d84152f93
    Suggested-by: Hillf Danton <hdanton@sina.com>
    Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3848e89087c483e08eedbd51dd363c3ce9d0c2c
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Sat Apr 8 12:43:21 2023 -0700

    net: wwan: iosm: Fix error handling path in ipc_pcie_probe()
    
    [ Upstream commit a56ef25619e079bd7d744636cf18d054d1e91982 ]
    
    Smatch reports:
            drivers/net/wwan/iosm/iosm_ipc_pcie.c:298 ipc_pcie_probe()
            warn: missing unwind goto?
    
    When dma_set_mask fails it directly returns without disabling pci
    device and freeing ipc_pcie. Fix this my calling a correct goto label
    
    As dma_set_mask returns either 0 or -EIO, we can use a goto label, as
    it finally returns -EIO.
    
    Add a set_mask_fail goto label which stands consistent with other goto
    labels in this function..
    
    Fixes: 035e3befc191 ("net: wwan: iosm: fix driver not working with INTEL_IOMMU disabled")
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1cc41c8acfc1ee30b4868559058db97fa44b0137
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sat Apr 8 11:49:43 2023 -0700

    smc: Fix use-after-free in tcp_write_timer_handler().
    
    [ Upstream commit 9744d2bf19762703704ecba885b7ac282c02eacf ]
    
    With Eric's ref tracker, syzbot finally found a repro for
    use-after-free in tcp_write_timer_handler() by kernel TCP
    sockets. [0]
    
    If SMC creates a kernel socket in __smc_create(), the kernel
    socket is supposed to be freed in smc_clcsock_release() by
    calling sock_release() when we close() the parent SMC socket.
    
    However, at the end of smc_clcsock_release(), the kernel
    socket's sk_state might not be TCP_CLOSE.  This means that
    we have not called inet_csk_destroy_sock() in __tcp_close()
    and have not stopped the TCP timers.
    
    The kernel socket's TCP timers can be fired later, so we
    need to hold a refcnt for net as we do for MPTCP subflows
    in mptcp_subflow_create_socket().
    
    [0]:
    leaked reference.
     sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)
     inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)
     __sock_create (net/socket.c:1546)
     smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)
     __sock_create (net/socket.c:1546)
     __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)
     __x64_sys_socket (net/socket.c:1672)
     do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    ==================================================================
    BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)
    Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091
    
    CPU: 0 PID: 18091 Comm: syzrepro Tainted: G        W          6.3.0-rc4-01174-gb5d54eb5899a #7
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014
    Call Trace:
     <IRQ>
     dump_stack_lvl (lib/dump_stack.c:107)
     print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)
     kasan_report (mm/kasan/report.c:538)
     tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)
     tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)
     call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
     __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)
     run_timer_softirq (kernel/time/timer.c:2037)
     __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)
     __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)
     irq_exit_rcu (kernel/softirq.c:664)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))
     </IRQ>
    
    Fixes: ac7138746e14 ("smc: establish new socket family")
    Reported-by: syzbot+7e1e1bdb852961150198@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/netdev/000000000000a3f51805f8bcc43a@google.com/
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bb5b0353adbcdd55b69037c25e21003cab62fa4
Author: Denis Plotnikov <den-plotnikov@yandex-team.ru>
Date:   Fri Apr 7 10:18:49 2023 +0300

    qlcnic: check pci_reset_function result
    
    [ Upstream commit 7573099e10ca69c3be33995c1fcd0d241226816d ]
    
    Static code analyzer complains to unchecked return value.
    The result of pci_reset_function() is unchecked.
    Despite, the issue is on the FLR supported code path and in that
    case reset can be done with pcie_flr(), the patch uses less invasive
    approach by adding the result check of pci_reset_function().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
    Signed-off-by: Denis Plotnikov <den-plotnikov@yandex-team.ru>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79f4e029d5f800653cfa4d92365275e16864a6d9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Dec 26 17:34:16 2021 +0100

    drm/armada: Fix a potential double free in an error handling path
    
    [ Upstream commit b89ce1177d42d5c124e83f3858818cd4e6a2c46f ]
    
    'priv' is a managed resource, so there is no need to free it explicitly or
    there will be a double free().
    
    Fixes: 90ad200b4cbc ("drm/armada: Use devm_drm_dev_alloc")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/c4f3c9207a9fce35cb6dd2cc60e755275961588a.1640536364.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49daa251504f817f8392481c168b8a8c0e888b1e
Author: Karol Herbst <kherbst@redhat.com>
Date:   Wed Apr 5 13:04:55 2023 +0200

    drm/nouveau/fb: add missing sysmen flush callbacks
    
    [ Upstream commit 86d8740dae5a397d8344ae75f8758103c1fcba97 ]
    
    Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
    Fixes: 5728d064190e1 ("drm/nouveau/fb: handle sysmem flush page from common code")
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230405110455.1368428-1-kherbst@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d60ba965d5be92ac31f6ad4f01d2b02b19c12eb3
Author: Claudia Draghicescu <claudia.rosu@nxp.com>
Date:   Wed Apr 5 14:19:18 2023 +0300

    Bluetooth: Set ISO Data Path on broadcast sink
    
    [ Upstream commit d2e4f1b1cba8742db66aaf77374cab7c0c7c8656 ]
    
    This patch enables ISO data rx on broadcast sink.
    
    Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections")
    Signed-off-by: Claudia Draghicescu <claudia.rosu@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b80f1809f7f612885ce8affa7e26b4f6a0f61aec
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Mar 30 14:45:03 2023 -0700

    Bluetooth: SCO: Fix possible circular locking dependency sco_sock_getsockopt
    
    [ Upstream commit 975abc0c90fc485ff9b4a6afa475c3b1398d5d47 ]
    
    This attempts to fix the following trace:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.3.0-rc2-g68fcb3a7bf97 #4706 Not tainted
    ------------------------------------------------------
    sco-tester/31 is trying to acquire lock:
    ffff8880025b8070 (&hdev->lock){+.+.}-{3:3}, at:
    sco_sock_getsockopt+0x1fc/0xa90
    
    but task is already holding lock:
    ffff888001eeb130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at:
    sco_sock_getsockopt+0x104/0xa90
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
           lock_sock_nested+0x32/0x80
           sco_connect_cfm+0x118/0x4a0
           hci_sync_conn_complete_evt+0x1e6/0x3d0
           hci_event_packet+0x55c/0x7c0
           hci_rx_work+0x34c/0xa00
           process_one_work+0x575/0x910
           worker_thread+0x89/0x6f0
           kthread+0x14e/0x180
           ret_from_fork+0x2b/0x50
    
    -> #1 (hci_cb_list_lock){+.+.}-{3:3}:
           __mutex_lock+0x13b/0xcc0
           hci_sync_conn_complete_evt+0x1ad/0x3d0
           hci_event_packet+0x55c/0x7c0
           hci_rx_work+0x34c/0xa00
           process_one_work+0x575/0x910
           worker_thread+0x89/0x6f0
           kthread+0x14e/0x180
           ret_from_fork+0x2b/0x50
    
    -> #0 (&hdev->lock){+.+.}-{3:3}:
           __lock_acquire+0x18cc/0x3740
           lock_acquire+0x151/0x3a0
           __mutex_lock+0x13b/0xcc0
           sco_sock_getsockopt+0x1fc/0xa90
           __sys_getsockopt+0xe9/0x190
           __x64_sys_getsockopt+0x5b/0x70
           do_syscall_64+0x42/0x90
           entry_SYSCALL_64_after_hwframe+0x70/0xda
    
    other info that might help us debug this:
    
    Chain exists of:
      &hdev->lock --> hci_cb_list_lock --> sk_lock-AF_BLUETOOTH-BTPROTO_SCO
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
                                   lock(hci_cb_list_lock);
                                   lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
      lock(&hdev->lock);
    
     *** DEADLOCK ***
    
    1 lock held by sco-tester/31:
     #0: ffff888001eeb130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0},
     at: sco_sock_getsockopt+0x104/0xa90
    
    Fixes: 248733e87d50 ("Bluetooth: Allow querying of supported offload codecs over SCO socket")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a893ad144aba8f17c9d520f9cdf44cdc626fb6a
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Mar 24 13:18:20 2023 -0700

    Bluetooth: Fix printing errors if LE Connection times out
    
    [ Upstream commit b62e72200eaad523f08d8319bba50fc652e032a8 ]
    
    This fixes errors like bellow when LE Connection times out since that
    is actually not a controller error:
    
     Bluetooth: hci0: Opcode 0x200d failed: -110
     Bluetooth: hci0: request failed to create LE connection: err -110
    
    Instead the code shall properly detect if -ETIMEDOUT is returned and
    send HCI_OP_LE_CREATE_CONN_CANCEL to give up on the connection.
    
    Link: https://github.com/bluez/bluez/issues/340
    Fixes: 8e8b92ee60de ("Bluetooth: hci_sync: Add hci_le_create_conn_sync")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0424c2e3944061b43aac6fd95f671989c611140e
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Mar 24 10:57:55 2023 -0700

    Bluetooth: hci_conn: Fix not cleaning up on LE Connection failure
    
    [ Upstream commit 19cf60bf63cbaf5262eac400c707966e19999b83 ]
    
    hci_connect_le_scan_cleanup shall always be invoked to cleanup the
    states and re-enable passive scanning if necessary, otherwise it may
    cause the pending action to stay active causing multiple attempts to
    connect.
    
    Fixes: 9b3628d79b46 ("Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56252da41426f3d01957456f13caf46ce670ea29
Author: Felix Huettner <felix.huettner@mail.schwarz>
Date:   Wed Apr 5 07:53:41 2023 +0000

    net: openvswitch: fix race on port output
    
    [ Upstream commit 066b86787fa3d97b7aefb5ac0a99a22dad2d15f8 ]
    
    assume the following setup on a single machine:
    1. An openvswitch instance with one bridge and default flows
    2. two network namespaces "server" and "client"
    3. two ovs interfaces "server" and "client" on the bridge
    4. for each ovs interface a veth pair with a matching name and 32 rx and
       tx queues
    5. move the ends of the veth pairs to the respective network namespaces
    6. assign ip addresses to each of the veth ends in the namespaces (needs
       to be the same subnet)
    7. start some http server on the server network namespace
    8. test if a client in the client namespace can reach the http server
    
    when following the actions below the host has a chance of getting a cpu
    stuck in a infinite loop:
    1. send a large amount of parallel requests to the http server (around
       3000 curls should work)
    2. in parallel delete the network namespace (do not delete interfaces or
       stop the server, just kill the namespace)
    
    there is a low chance that this will cause the below kernel cpu stuck
    message. If this does not happen just retry.
    Below there is also the output of bpftrace for the functions mentioned
    in the output.
    
    The series of events happening here is:
    1. the network namespace is deleted calling
       `unregister_netdevice_many_notify` somewhere in the process
    2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and
       then runs `synchronize_net`
    3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`
    4. this is then handled by `dp_device_event` which calls
       `ovs_netdev_detach_dev` (if a vport is found, which is the case for
       the veth interface attached to ovs)
    5. this removes the rx_handlers of the device but does not prevent
       packages to be sent to the device
    6. `dp_device_event` then queues the vport deletion to work in
       background as a ovs_lock is needed that we do not hold in the
       unregistration path
    7. `unregister_netdevice_many_notify` continues to call
       `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0
    8. port deletion continues (but details are not relevant for this issue)
    9. at some future point the background task deletes the vport
    
    If after 7. but before 9. a packet is send to the ovs vport (which is
    not deleted at this point in time) which forwards it to the
    `dev_queue_xmit` flow even though the device is unregistering.
    In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is
    a while loop (if the packet has a rx_queue recorded) that is infinite if
    `dev->real_num_tx_queues` is zero.
    
    To prevent this from happening we update `do_output` to handle devices
    without carrier the same as if the device is not found (which would
    be the code path after 9. is done).
    
    Additionally we now produce a warning in `skb_tx_hash` if we will hit
    the infinite loop.
    
    bpftrace (first word is function name):
    
    __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1
    netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1
    dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1
    synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
    synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
    synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
    synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
    dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2
    ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2
    netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2
    synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
    netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2
    dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 27, reg_state: 2
    dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 22, reg_state: 2
    dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 18, reg_state: 2
    netdev_unregister_kobject: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024
    synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
    ovs_vport_send server: real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 2
    __dev_queue_xmit server: real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 2
    netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 2
    broken device server: real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024
    ovs_dp_detach_port server: real_num_tx_queues: 0 cpu 9, pid: 9124, tid: 9124, reg_state: 2
    synchronize_rcu_expedited: cpu 9, pid: 33604, tid: 33604
    
    stuck message:
    
    watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [curl:1929279]
    Modules linked in: veth pktgen bridge stp llc ip_set_hash_net nft_counter xt_set nft_compat nf_tables ip_set_hash_ip ip_set nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 tls binfmt_misc nls_iso8859_1 input_leds joydev serio_raw dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua sch_fq_codel drm efi_pstore virtio_rng ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel virtio_net ahci net_failover crypto_simd cryptd psmouse libahci virtio_blk failover
    CPU: 5 PID: 1929279 Comm: curl Not tainted 5.15.0-67-generic #74-Ubuntu
    Hardware name: OpenStack Foundation OpenStack Nova, BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:netdev_pick_tx+0xf1/0x320
    Code: 00 00 8d 48 ff 0f b7 c1 66 39 ca 0f 86 e9 01 00 00 45 0f b7 ff 41 39 c7 0f 87 5b 01 00 00 44 29 f8 41 39 c7 0f 87 4f 01 00 00 <eb> f2 0f 1f 44 00 00 49 8b 94 24 28 04 00 00 48 85 d2 0f 84 53 01
    RSP: 0018:ffffb78b40298820 EFLAGS: 00000246
    RAX: 0000000000000000 RBX: ffff9c8773adc2e0 RCX: 000000000000083f
    RDX: 0000000000000000 RSI: ffff9c8773adc2e0 RDI: ffff9c870a25e000
    RBP: ffffb78b40298858 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff9c870a25e000
    R13: ffff9c870a25e000 R14: ffff9c87fe043480 R15: 0000000000000000
    FS:  00007f7b80008f00(0000) GS:ffff9c8e5f740000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f7b80f6a0b0 CR3: 0000000329d66000 CR4: 0000000000350ee0
    Call Trace:
     <IRQ>
     netdev_core_pick_tx+0xa4/0xb0
     __dev_queue_xmit+0xf8/0x510
     ? __bpf_prog_exit+0x1e/0x30
     dev_queue_xmit+0x10/0x20
     ovs_vport_send+0xad/0x170 [openvswitch]
     do_output+0x59/0x180 [openvswitch]
     do_execute_actions+0xa80/0xaa0 [openvswitch]
     ? kfree+0x1/0x250
     ? kfree+0x1/0x250
     ? kprobe_perf_func+0x4f/0x2b0
     ? flow_lookup.constprop.0+0x5c/0x110 [openvswitch]
     ovs_execute_actions+0x4c/0x120 [openvswitch]
     ovs_dp_process_packet+0xa1/0x200 [openvswitch]
     ? ovs_ct_update_key.isra.0+0xa8/0x120 [openvswitch]
     ? ovs_ct_fill_key+0x1d/0x30 [openvswitch]
     ? ovs_flow_key_extract+0x2db/0x350 [openvswitch]
     ovs_vport_receive+0x77/0xd0 [openvswitch]
     ? __htab_map_lookup_elem+0x4e/0x60
     ? bpf_prog_680e8aff8547aec1_kfree+0x3b/0x714
     ? trace_call_bpf+0xc8/0x150
     ? kfree+0x1/0x250
     ? kfree+0x1/0x250
     ? kprobe_perf_func+0x4f/0x2b0
     ? kprobe_perf_func+0x4f/0x2b0
     ? __mod_memcg_lruvec_state+0x63/0xe0
     netdev_port_receive+0xc4/0x180 [openvswitch]
     ? netdev_port_receive+0x180/0x180 [openvswitch]
     netdev_frame_hook+0x1f/0x40 [openvswitch]
     __netif_receive_skb_core.constprop.0+0x23d/0xf00
     __netif_receive_skb_one_core+0x3f/0xa0
     __netif_receive_skb+0x15/0x60
     process_backlog+0x9e/0x170
     __napi_poll+0x33/0x180
     net_rx_action+0x126/0x280
     ? ttwu_do_activate+0x72/0xf0
     __do_softirq+0xd9/0x2e7
     ? rcu_report_exp_cpu_mult+0x1b0/0x1b0
     do_softirq+0x7d/0xb0
     </IRQ>
     <TASK>
     __local_bh_enable_ip+0x54/0x60
     ip_finish_output2+0x191/0x460
     __ip_finish_output+0xb7/0x180
     ip_finish_output+0x2e/0xc0
     ip_output+0x78/0x100
     ? __ip_finish_output+0x180/0x180
     ip_local_out+0x5e/0x70
     __ip_queue_xmit+0x184/0x440
     ? tcp_syn_options+0x1f9/0x300
     ip_queue_xmit+0x15/0x20
     __tcp_transmit_skb+0x910/0x9c0
     ? __mod_memcg_state+0x44/0xa0
     tcp_connect+0x437/0x4e0
     ? ktime_get_with_offset+0x60/0xf0
     tcp_v4_connect+0x436/0x530
     __inet_stream_connect+0xd4/0x3a0
     ? kprobe_perf_func+0x4f/0x2b0
     ? aa_sk_perm+0x43/0x1c0
     inet_stream_connect+0x3b/0x60
     __sys_connect_file+0x63/0x70
     __sys_connect+0xa6/0xd0
     ? setfl+0x108/0x170
     ? do_fcntl+0xe8/0x5a0
     __x64_sys_connect+0x18/0x20
     do_syscall_64+0x5c/0xc0
     ? __x64_sys_fcntl+0xa9/0xd0
     ? exit_to_user_mode_prepare+0x37/0xb0
     ? syscall_exit_to_user_mode+0x27/0x50
     ? do_syscall_64+0x69/0xc0
     ? __sys_setsockopt+0xea/0x1e0
     ? exit_to_user_mode_prepare+0x37/0xb0
     ? syscall_exit_to_user_mode+0x27/0x50
     ? __x64_sys_setsockopt+0x1f/0x30
     ? do_syscall_64+0x69/0xc0
     ? irqentry_exit+0x1d/0x30
     ? exc_page_fault+0x89/0x170
     entry_SYSCALL_64_after_hwframe+0x61/0xcb
    RIP: 0033:0x7f7b8101c6a7
    Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 18 89 54 24 0c 48 89 34 24 89
    RSP: 002b:00007ffffd6b2198 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7b8101c6a7
    RDX: 0000000000000010 RSI: 00007ffffd6b2360 RDI: 0000000000000005
    RBP: 0000561f1370d560 R08: 00002795ad21d1ac R09: 0030312e302e302e
    R10: 00007ffffd73f080 R11: 0000000000000246 R12: 0000561f1370c410
    R13: 0000000000000000 R14: 0000000000000005 R15: 0000000000000000
     </TASK>
    
    Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
    Co-developed-by: Luca Czesla <luca.czesla@mail.schwarz>
    Signed-off-by: Luca Czesla <luca.czesla@mail.schwarz>
    Signed-off-by: Felix Huettner <felix.huettner@mail.schwarz>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/ZC0pBXBAgh7c76CA@kernel-bug-kernel-bug
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4aec9d6aff1c71e072b10ef74a73a11f28f77ca
Author: Ahmed Zaki <ahmed.zaki@intel.com>
Date:   Thu Apr 6 15:35:28 2023 -0600

    iavf: remove active_cvlans and active_svlans bitmaps
    
    [ Upstream commit 9c85b7fa12ef2e4fc11a4e31ac595fb5f9d0ddf9 ]
    
    The VLAN filters info is currently being held in a list and 2 bitmaps
    (active_cvlans and active_svlans). We are experiencing some racing where
    data is not in sync in the list and bitmaps. For example, the VLAN is
    initially added to the list but only when the PF replies, it is added to
    the bitmap. If a user adds many V2 VLANS before the PF responds:
    
        while [ $((i++)) ]
            ip l add l eth0 name eth0.$i type vlan id $i
    
    we might end up with more VLAN list entries than the designated limit.
    Also, The "ip link show" will show more links added than the PF limit.
    
    On the other and, the bitmaps are only used to check the number of VLAN
    filters and to re-enable the filters when the interface goes from DOWN to
    UP.
    
    This patch gets rid of the bitmaps and uses the list only. To do that,
    the states of the VLAN filter are modified:
    1 - IAVF_VLAN_REMOVE: the entry needs to be totally removed after informing
      the PF. This is the "ip link del eth0.$i" path.
    2 - IAVF_VLAN_DISABLE: (new) the netdev went down. The filter needs to be
      removed from the PF and then marked INACTIVE.
    3 - IAVF_VLAN_INACTIVE: (new) no PF filter exists, but the user did not
      delete the VLAN.
    
    Fixes: 48ccc43ecf10 ("iavf: Add support VIRTCHNL_VF_OFFLOAD_VLAN_V2 during netdev config")
    Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5596bba06e3ad4edf3ab03bf72557ff893a8136
Author: Ahmed Zaki <ahmed.zaki@intel.com>
Date:   Thu Apr 6 15:35:27 2023 -0600

    iavf: refactor VLAN filter states
    
    [ Upstream commit 0c0da0e951053fda20412cd284e2714bbbb31bff ]
    
    The VLAN filter states are currently being saved as individual bits.
    This is error prone as multiple bits might be mistakenly set.
    
    Fix by replacing the bits with a single state enum. Also, add an
    "ACTIVE" state for filters that are accepted by the PF.
    
    Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Stable-dep-of: 9c85b7fa12ef ("iavf: remove active_cvlans and active_svlans bitmaps")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9dcf3d36f0312414f003f381f41867359a04cc10
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Apr 6 16:23:50 2023 +0800

    bonding: fix ns validation on backup slaves
    
    [ Upstream commit 4598380f9c548aa161eb4e990a1583f0a7d1e0d7 ]
    
    When arp_validate is set to 2, 3, or 6, validation is performed for
    backup slaves as well. As stated in the bond documentation, validation
    involves checking the broadcast ARP request sent out via the active
    slave. This helps determine which slaves are more likely to function in
    the event of an active slave failure.
    
    However, when the target is an IPv6 address, the NS message sent from
    the active interface is not checked on backup slaves. Additionally,
    based on the bond_arp_rcv() rule b, we must reverse the saddr and daddr
    when checking the NS message.
    
    Note that when checking the NS message, the destination address is a
    multicast address. Therefore, we must convert the target address to
    solicited multicast in the bond_get_targets_ip6() function.
    
    Prior to the fix, the backup slaves had a mii status of "down", but
    after the fix, all of the slaves' mii status was updated to "UP".
    
    Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
    Reviewed-by: Jonathan Toppins <jtoppins@redhat.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ec0541b1c1707160036b3103df7ffb9d52262cf
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Apr 6 14:34:50 2023 +0800

    tcp: restrict net.ipv4.tcp_app_win
    
    [ Upstream commit dc5110c2d959c1707e12df5f792f41d90614adaa ]
    
    UBSAN: shift-out-of-bounds in net/ipv4/tcp_input.c:555:23
    shift exponent 255 is too large for 32-bit type 'int'
    CPU: 1 PID: 7907 Comm: ssh Not tainted 6.3.0-rc4-00161-g62bad54b26db-dirty #206
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x136/0x150
     __ubsan_handle_shift_out_of_bounds+0x21f/0x5a0
     tcp_init_transfer.cold+0x3a/0xb9
     tcp_finish_connect+0x1d0/0x620
     tcp_rcv_state_process+0xd78/0x4d60
     tcp_v4_do_rcv+0x33d/0x9d0
     __release_sock+0x133/0x3b0
     release_sock+0x58/0x1b0
    
    'maxwin' is int, shifting int for 32 or more bits is undefined behaviour.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32622ba23c6acf9a405937e3e3af2bf755fa39e2
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Wed Apr 5 23:31:18 2023 -0700

    niu: Fix missing unwind goto in niu_alloc_channels()
    
    [ Upstream commit 8ce07be703456acb00e83d99f3b8036252c33b02 ]
    
    Smatch reports: drivers/net/ethernet/sun/niu.c:4525
            niu_alloc_channels() warn: missing unwind goto?
    
    If niu_rbr_fill() fails, then we are directly returning 'err' without
    freeing the channels.
    
    Fix this by changing direct return to a goto 'out_err'.
    
    Fixes: a3138df9f20e ("[NIU]: Add Sun Neptune ethernet driver.")
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e83bde56955511c168e6a7bc05efac832de2e1c
Author: Fuad Tabba <tabba@google.com>
Date:   Tue Apr 4 16:23:21 2023 +0100

    KVM: arm64: Advertise ID_AA64PFR0_EL1.CSV2/3 to protected VMs
    
    [ Upstream commit e81625218bf7986ba1351a98c43d346b15601d26 ]
    
    The existing pKVM code attempts to advertise CSV2/3 using values
    initialized to 0, but never set. To advertise CSV2/3 to protected
    guests, pass the CSV2/3 values to hyp when initializing hyp's
    view of guests' ID_AA64PFR0_EL1.
    
    Similar to non-protected KVM, these are system-wide, rather than
    per cpu, for simplicity.
    
    Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers")
    Signed-off-by: Fuad Tabba <tabba@google.com>
    Link: https://lore.kernel.org/r/20230404152321.413064-1-tabba@google.com
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eabc166919d169e105263974991f52b0351e431a
Author: Xu Kuohai <xukuohai@huawei.com>
Date:   Sat Apr 1 19:41:44 2023 -0400

    bpf, arm64: Fixed a BTI error on returning to patched function
    
    [ Upstream commit 738a96c4a8c36950803fdd27e7c30aca92dccefd ]
    
    When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump
    back to the instruction next to call site to call the patched function.
    For BTI-enabled kernel, the instruction next to call site is usually
    PACIASP, in this case, it's safe to jump back with BLR. But when
    the call site is not followed by a PACIASP or bti, a BTI exception
    is triggered.
    
    Here is a fault log:
    
     Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI
     CPU: 0 PID: 263 Comm: test_progs Tainted: GF
     Hardware name: linux,dummy-virt (DT)
     pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)
     pc : bpf_fentry_test1+0xc/0x30
     lr : bpf_trampoline_6442573892_0+0x48/0x1000
     sp : ffff80000c0c3a50
     x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000
     x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050
     x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a
     x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000
     x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0
     x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
     x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528
     x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101
     x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001
     x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001
     Kernel panic - not syncing: Unhandled exception
     CPU: 0 PID: 263 Comm: test_progs Tainted: GF
     Hardware name: linux,dummy-virt (DT)
     Call trace:
      dump_backtrace+0xec/0x144
      show_stack+0x24/0x7c
      dump_stack_lvl+0x8c/0xb8
      dump_stack+0x18/0x34
      panic+0x1cc/0x3ec
      __el0_error_handler_common+0x0/0x130
      el1h_64_sync_handler+0x60/0xd0
      el1h_64_sync+0x78/0x7c
      bpf_fentry_test1+0xc/0x30
      bpf_fentry_test1+0xc/0x30
      bpf_prog_test_run_tracing+0xdc/0x2a0
      __sys_bpf+0x438/0x22a0
      __arm64_sys_bpf+0x30/0x54
      invoke_syscall+0x78/0x110
      el0_svc_common.constprop.0+0x6c/0x1d0
      do_el0_svc+0x38/0xe0
      el0_svc+0x30/0xd0
      el0t_64_sync_handler+0x1ac/0x1b0
      el0t_64_sync+0x1a0/0x1a4
     Kernel Offset: disabled
     CPU features: 0x0000,00034c24,f994fdab
     Memory Limit: none
    
    And the instruction next to call site of bpf_fentry_test1 is ADD,
    not PACIASP:
    
    <bpf_fentry_test1>:
            bti     c
            nop
            nop
            add     w0, w0, #0x1
            paciasp
    
    For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled
    kernel, so there is no problem. To fix it, replace BLR with RET to bypass
    the branch target check.
    
    Fixes: efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64")
    Reported-by: Florent Revest <revest@chromium.org>
    Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Florent Revest <revest@chromium.org>
    Acked-by: Florent Revest <revest@chromium.org>
    Link: https://lore.kernel.org/bpf/20230401234144.3719742-1-xukuohai@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7dcd834af53c79418ca3cd1c42749a314b9f7dc
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Mon Mar 13 22:43:25 2023 +0800

    9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition
    
    [ Upstream commit ea4f1009408efb4989a0f139b70fb338e7f687d0 ]
    
    In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring
    to init priv->rings and bound &ring->work with p9_xen_response.
    
    When it calls xen_9pfs_front_event_handler to handle IRQ requests,
    it will finally call schedule_work to start the work.
    
    When we call xen_9pfs_front_remove to remove the driver, there
    may be a sequence as follows:
    
    Fix it by finishing the work before cleanup in xen_9pfs_front_free.
    
    Note that, this bug is found by static analysis, which might be
    false positive.
    
    CPU0                  CPU1
    
                         |p9_xen_response
    xen_9pfs_front_remove|
      xen_9pfs_front_free|
    kfree(priv)          |
    //free priv          |
                         |p9_tag_lookup
                         |//use priv->client
    
    Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd4d88e68c75caf5c6f8293a36bc3ae289e0369e
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Fri Feb 24 16:22:21 2023 +0100

    dmaengine: apple-admac: Fix 'current_tx' not getting freed
    
    [ Upstream commit d9503be5a100c553731c0e8a82c7b4201e8a970c ]
    
    In terminate_all we should queue up all submitted descriptors to be
    freed. We do that for the content of the 'issued' and 'submitted' lists,
    but the 'current_tx' descriptor falls through the cracks as it's
    removed from the 'issued' list once it gets assigned to be the current
    descriptor. Explicitly queue up freeing of the 'current_tx' descriptor
    to address a memory leak that is otherwise present.
    
    Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20230224152222.26732-2-povik+lin@cutebit.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1755eb628b2d4d6eae2399363e9fdd9e52ec2108
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Fri Feb 24 16:22:22 2023 +0100

    dmaengine: apple-admac: Set src_addr_widths capability
    
    [ Upstream commit 6e96adcaa7a29827ac8ee8df290a44957a4823ec ]
    
    Add missing setting of 'src_addr_widths', which is the same as for the
    other direction.
    
    Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20230224152222.26732-3-povik+lin@cutebit.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6ff55786e472aa291ec44c192688ea80d2564eb
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Fri Feb 24 16:22:20 2023 +0100

    dmaengine: apple-admac: Handle 'global' interrupt flags
    
    [ Upstream commit a288fd158fbf85c06a9ac01cecabf97ac5d962e7 ]
    
    In addition to TX channel and RX channel interrupt flags there's
    another class of 'global' interrupt flags with unknown semantics. Those
    weren't being handled up to now, and they are the suspected cause of
    stuck IRQ states that have been sporadically occurring. Check the global
    flags and clear them if raised.
    
    Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20230224152222.26732-1-povik+lin@cutebit.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9263793f77e3ac366164d4f316c440c69c5b629
Author: George Guo <guodongtai@kylinos.cn>
Date:   Tue Mar 28 15:13:35 2023 +0800

    LoongArch, bpf: Fix jit to skip speculation barrier opcode
    
    [ Upstream commit a6f6a95f25803500079513780d11a911ce551d76 ]
    
    Just skip the opcode(BPF_ST | BPF_NOSPEC) in the BPF JIT instead of
    failing to JIT the entire program, given LoongArch currently has no
    couterpart of a speculation barrier instruction. To verify the issue,
    use the ltp testcase as shown below.
    
    Also, Wang says:
    
      I can confirm there's currently no speculation barrier equivalent
      on LonogArch. (Loongson says there are builtin mitigations for
      Spectre-V1 and V2 on their chips, and AFAIK efforts to port the
      exploits to mips/LoongArch have all failed a few years ago.)
    
    Without this patch:
    
      $ ./bpf_prog02
      [...]
      bpf_common.c:123: TBROK: Failed verification: ??? (524)
      [...]
      Summary:
      passed   0
      failed   0
      broken   1
      skipped  0
      warnings 0
    
    With this patch:
    
      $ ./bpf_prog02
      [...]
      Summary:
      passed   0
      failed   0
      broken   0
      skipped  0
      warnings 0
    
    Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
    Signed-off-by: George Guo <guodongtai@kylinos.cn>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: WANG Xuerui <git@xen0n.name>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Link: https://lore.kernel.org/bpf/20230328071335.2664966-1-guodongtai@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b4468f3341586a9a930d25abf3bd4596570f088
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Mon Mar 27 17:42:32 2023 -0700

    bpf: tcp: Use sock_gen_put instead of sock_put in bpf_iter_tcp
    
    [ Upstream commit 580031ff9952b7dbf48dedba6b56a100ae002bef ]
    
    While reviewing the udp-iter batching patches, noticed the bpf_iter_tcp
    calling sock_put() is incorrect. It should call sock_gen_put instead
    because bpf_iter_tcp is iterating the ehash table which has the req sk
    and tw sk. This patch replaces all sock_put with sock_gen_put in the
    bpf_iter_tcp codepath.
    
    Fixes: 04c7820b776f ("bpf: tcp: Bpf iter batching and lock_sock")
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20230328004232.2134233-1-martin.lau@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb18b9dbac2bbdf7695e0bfaac4bf944ff7b207d
Author: Mark Zhang <markzhang@nvidia.com>
Date:   Mon Mar 20 12:59:55 2023 +0200

    RDMA/cma: Allow UD qp_type to join multicast only
    
    [ Upstream commit 58e84f6b3e84e46524b7e5a916b53c1ad798bc8f ]
    
    As for multicast:
    - The SIDR is the only mode that makes sense;
    - Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is
      UD compatible. In this case qkey also needs to be set [1].
    
    This patch allows only UD qp_type to join multicast, and set qkey to
    default if it's not set, to fix an uninit-value error: the ib->rec.qkey
    field is accessed without being initialized.
    
    =====================================================
    BUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]
    BUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570
     cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]
     cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570
     cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline]
     rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814
     ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479
     ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546
     ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732
     vfs_write+0x8ce/0x2030 fs/read_write.c:588
     ksys_write+0x28c/0x520 fs/read_write.c:643
     __do_sys_write fs/read_write.c:655 [inline]
     __se_sys_write fs/read_write.c:652 [inline]
     __ia32_sys_write+0xdb/0x120 fs/read_write.c:652
     do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]
     __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180
     do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205
     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248
     entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
    
    Local variable ib.i created at:
    cma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline]
    rdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814
    ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479
    
    CPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    =====================================================
    
    [1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/
    
    Fixes: b5de0c60cc30 ("RDMA/cma: Fix use after free race in roce multicast join")
    Reported-by: syzbot+8fcbb77276d43cc8b693@syzkaller.appspotmail.com
    Signed-off-by: Mark Zhang <markzhang@nvidia.com>
    Link: https://lore.kernel.org/r/58a4a98323b5e6b1282e83f6b76960d06e43b9fa.1679309909.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a983967602675880d6160a17ace2c0f48717ff33
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Mar 10 08:49:40 2023 +0100

    clk: rs9: Fix suspend/resume
    
    [ Upstream commit 632e04739c8f45c2d9ca4d4c5bd18d80c2ac9296 ]
    
    Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors")
    without removing cache synchronization in resume path results in a
    kernel panic as map->cache_ops is unset, due to REGCACHE_NONE.
    Enable flat cache again to support resume again. num_reg_defaults_raw
    is necessary to read the cache defaults from hardware. Some registers
    are strapped in hardware and cannot be provided in software.
    
    Fixes: 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors")
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20230310074940.3475703-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c18dbfa017cd5a9e0214dd4f006ca1037073655
Author: Cheng Xu <chengyou@linux.alibaba.com>
Date:   Mon Mar 20 16:46:52 2023 +0800

    RDMA/erdma: Defer probing if netdevice can not be found
    
    [ Upstream commit 6bd1bca858f1734a75572a788213d1e1143f2f0a ]
    
    ERDMA device may be probed before its associated netdevice, returning
    -EPROBE_DEFER allows OS try to probe erdma device later.
    
    Fixes: d55e6fb4803c ("RDMA/erdma: Add the erdma module")
    Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230320084652.16807-5-chengyou@linux.alibaba.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d78e502d855830e392f2279e1697ca527eedfe0
Author: Cheng Xu <chengyou@linux.alibaba.com>
Date:   Mon Mar 20 16:46:51 2023 +0800

    RDMA/erdma: Inline mtt entries into WQE if supported
    
    [ Upstream commit 0dd83a4d7756713f81990d6c5547500f212a1190 ]
    
    The max inline mtt count supported is ERDMA_MAX_INLINE_MTT_ENTRIES.
    When mr->mem.mtt_nents == ERDMA_MAX_INLINE_MTT_ENTRIES, inline mtt
    is also supported, fix it.
    
    Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation")
    Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230320084652.16807-4-chengyou@linux.alibaba.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55ce6da17f80b95314a002ccaf48026c6ee2369f
Author: Cheng Xu <chengyou@linux.alibaba.com>
Date:   Mon Mar 20 16:46:50 2023 +0800

    RDMA/erdma: Update default EQ depth to 4096 and max_send_wr to 8192
    
    [ Upstream commit 6256aa9ae955d10ec73a434533ca62034eff1b76 ]
    
    Max EQ depth of hardware is 32K, the current default EQ depth is too small
    for some applications, so change the default depth to 4096.
    Max send WRs the hardware can support is 8K, but the driver limits the
    value to 4K. Remove this limitation.
    
    Fixes: be3cff0f242d ("RDMA/erdma: Add the hardware related definitions")
    Fixes: db23ae64caac ("RDMA/erdma: Add verbs header file")
    Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230320084652.16807-3-chengyou@linux.alibaba.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 194f3aa560cb47163d6be9a9d1a61a9e8fa669c5
Author: Cheng Xu <chengyou@linux.alibaba.com>
Date:   Mon Mar 20 16:46:49 2023 +0800

    RDMA/erdma: Fix some typos
    
    [ Upstream commit 3fe26c0493e4c2da4b7d8ba8c975a6f48fb75ec2 ]
    
    FAA is short for atomic fetch and add, not FAD. Fix this.
    
    Fixes: 0ca9c2e2844a ("RDMA/erdma: Implement atomic operations support")
    Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230320084652.16807-2-chengyou@linux.alibaba.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d0cd97f61fca40809d7fc81a4468dbad80b6f05
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Thu Mar 16 15:40:49 2023 +0200

    IB/mlx5: Add support for 400G_8X lane speed
    
    [ Upstream commit 88c9483faf15ada14eca82714114656893063458 ]
    
    Currently, when driver queries PTYS to report which link speed is being
    used on its RoCE ports, it does not check the case of having 400Gbps
    transmitted over 8 lanes. Thus it fails to report the said speed and
    instead it defaults to report 10G over 4 lanes.
    
    Add a check for the said speed when querying PTYS and report it back
    correctly when needed.
    
    Fixes: 08e8676f1607 ("IB/mlx5: Add support for 50Gbps per lane link modes")
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Reviewed-by: Aya Levin <ayal@nvidia.com>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Link: https://lore.kernel.org/r/ec9040548d119d22557d6a4b4070d6f421701fd4.1678973994.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f6b91993090262c8fdbfa3c7fb7d3acdc3ba86b
Author: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Date:   Wed Mar 15 09:52:31 2023 -0500

    RDMA/irdma: Add ipv4 check to irdma_find_listener()
    
    [ Upstream commit e4522c097ec10f23ea0933e9e69d4fa9d8ae9441 ]
    
    Add ipv4 check to irdma_find_listener(). Otherwise the function
    incorrectly finds and returns a listener with a different addr family for
    the zero IP addr, if a listener with a zero IP addr and the same port as
    the one searched for has already been created.
    
    Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager")
    Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Link: https://lore.kernel.org/r/20230315145231.931-5-shiraz.saleem@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 270f3530f7dec1b3b18fdcf3db7be30ade25b0d9
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Mar 15 09:52:30 2023 -0500

    RDMA/irdma: Increase iWARP CM default rexmit count
    
    [ Upstream commit 8385a875c9eecc429b2f72970efcbb0e5cb5b547 ]
    
    When running perftest with large number of connections in iWARP mode, the
    passive side could be slow to respond. Increase the rexmit counter default
    to allow scaling connections.
    
    Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Link: https://lore.kernel.org/r/20230315145231.931-4-shiraz.saleem@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adf58bd4018fbcd990c62e840afd2f178eefad60
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Mar 15 09:52:29 2023 -0500

    RDMA/irdma: Fix memory leak of PBLE objects
    
    [ Upstream commit b69a6979dbaa2453675fe9c71bdc2497fedb11f9 ]
    
    On rmmod of irdma, the PBLE object memory is not being freed. PBLE object
    memory are not statically pre-allocated at function initialization time
    unlike other HMC objects. PBLEs objects and the Segment Descriptors (SD)
    for it can be dynamically allocated during scale up and SD's remain
    allocated till function deinitialization.
    
    Fix this leak by adding IRDMA_HMC_IW_PBLE to the iw_hmc_obj_types[] table
    and skip pbles in irdma_create_hmc_obj but not in irdma_del_hmc_objects().
    
    Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Link: https://lore.kernel.org/r/20230315145231.931-3-shiraz.saleem@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4e7f76dafd885a4cd0c0e06bfae6db3c3a58324
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Mar 15 09:52:28 2023 -0500

    RDMA/irdma: Do not generate SW completions for NOPs
    
    [ Upstream commit 30ed9ee9a10a90ae719dcfcacead1d0506fa45ed ]
    
    Currently, artificial SW completions are generated for NOP wqes which can
    generate unexpected completions with wr_id = 0. Skip the generation of
    artificial completions for NOPs.
    
    Fixes: 81091d7696ae ("RDMA/irdma: Add SW mechanism to generate completions on error")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Link: https://lore.kernel.org/r/20230315145231.931-2-shiraz.saleem@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a19b58887040bb3ee1594217946a59f2e8535002
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Thu Mar 16 10:36:24 2023 +0800

    clk: sprd: set max_register according to mapping range
    
    [ Upstream commit 47d43086531f10539470a63e8ad92803e686a3dd ]
    
    In sprd clock driver, regmap_config.max_register was set to a fixed value
    which is likely larger than the address range configured in device tree,
    when reading registers through debugfs it would cause access violation.
    
    Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure")
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Link: https://lore.kernel.org/r/20230316023624.758204-1-chunyan.zhang@unisoc.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fda4233d2425dc19349954c20eae2c46c87b4a14
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Apr 14 15:53:13 2023 +0800

    io_uring: complete request via task work in case of DEFER_TASKRUN
    
    commit 860e1c7f8b0b43fbf91b4d689adfaa13adb89452 upstream.
    
    So far io_req_complete_post() only covers DEFER_TASKRUN by completing
    request via task work when the request is completed from IOWQ.
    
    However, uring command could be completed from any context, and if io
    uring is setup with DEFER_TASKRUN, the command is required to be
    completed from current context, otherwise wait on IORING_ENTER_GETEVENTS
    can't be wakeup, and may hang forever.
    
    The issue can be observed on removing ublk device, but turns out it is
    one generic issue for uring command & DEFER_TASKRUN, so solve it in
    io_uring core code.
    
    Fixes: e6aeb2721d3b ("io_uring: complete all requests in task context")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/linux-block/b3fc9991-4c53-9218-a8cc-5b4dd3952108@kernel.dk/
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Cc: Kanchan Joshi <joshi.k@samsung.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0610761d3e8c05038aaf7e9e739440303b11b33c
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Mar 1 17:14:09 2023 +0200

    drm/i915/dsi: fix DSS CTL register offsets for TGL+
    
    commit 6b8446859c971a5783a2cdc90adf32e64de3bd23 upstream.
    
    On TGL+ the DSS control registers are at different offsets, and there's
    one per pipe. Fix the offsets to fix dual link DSI for TGL+.
    
    There would be helpers for this in the DSC code, but just do the quick
    fix now for DSI. Long term, we should probably move all the DSS handling
    into intel_vdsc.c, so exporting the helpers seems counter-productive.
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8232
    Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230301151409.1581574-1-jani.nikula@intel.com
    (cherry picked from commit 1a62dd9895dca78bee28bba3a36f08836fdd143d)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62055fa6fbf8f1f1457f5d6a7d17ce1a45972613
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 12 17:31:46 2023 +0200

    fbcon: set_con2fb_map needs to set con2fb_map!
    
    commit fffb0b52d5258554c645c966c6cbef7de50b851d upstream.
    
    I got really badly confused in d443d9386472 ("fbcon: move more common
    code into fb_open()") because we set the con2fb_map before the failure
    points, which didn't look good.
    
    But in trying to fix that I moved the assignment into the wrong path -
    we need to do it for _all_ vc we take over, not just the first one
    (which additionally requires the call to con2fb_acquire_newinfo).
    
    I've figured this out because of a KASAN bug report, where the
    fbcon_registered_fb and fbcon_display arrays went out of sync in
    fbcon_mode_deleted() because the con2fb_map pointed at the old
    fb_info, but the modes and everything was updated for the new one.
    
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Acked-by: Helge Deller <deller@gmx.de>
    Tested-by: Xingyuan Mo <hdthky0@gmail.com>
    Fixes: d443d9386472 ("fbcon: move more common code into fb_open()")
    Reported-by: Xingyuan Mo <hdthky0@gmail.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Xingyuan Mo <hdthky0@gmail.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v5.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1e757d75471ab4765fc7b60f0cb8ae8f046dd30
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 12 17:23:49 2023 +0200

    fbcon: Fix error paths in set_con2fb_map
    
    commit edf79dd2172233452ff142dcc98b19d955fc8974 upstream.
    
    This is a regressoin introduced in b07db3958485 ("fbcon: Ditch error
    handling for con2fb_release_oldinfo"). I failed to realize what the if
    (!err) checks. The mentioned commit was dropping the
    con2fb_release_oldinfo() return value but the if (!err) was also
    checking whether the con2fb_acquire_newinfo() function call above
    failed or not.
    
    Fix this with an early return statement.
    
    Note that there's still a difference compared to the orginal state of
    the code, the below lines are now also skipped on error:
    
            if (!search_fb_in_map(info_idx))
                    info_idx = newidx;
    
    These are only needed when we've actually thrown out an old fb_info
    from the console mappings, which only happens later on.
    
    Also move the fbcon_add_cursor_work() call into the same if block,
    it's all protected by console_lock so doesn't matter when we set up
    the blinking cursor delayed work anyway. This further simplifies the
    control flow and allows us to ditch the found local variable.
    
    v2: Clarify commit message (Javier)
    
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Acked-by: Helge Deller <deller@gmx.de>
    Tested-by: Xingyuan Mo <hdthky0@gmail.com>
    Fixes: b07db3958485 ("fbcon: Ditch error handling for con2fb_release_oldinfo")
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Xingyuan Mo <hdthky0@gmail.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v5.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cc6fdf79bb0ad15e3f9e4a08db0ba200da04dee
Author: Reiji Watanabe <reijiw@google.com>
Date:   Tue Mar 28 19:39:44 2023 -0700

    KVM: arm64: PMU: Restore the guest's EL0 event counting after migration
    
    commit f9ea835e99bc8d049bf2a3ec8fa5a7cb4fcade23 upstream.
    
    Currently, with VHE, KVM enables the EL0 event counting for the
    guest on vcpu_load() or KVM enables it as a part of the PMU
    register emulation process, when needed.  However, in the migration
    case (with VHE), the same handling is lacking, as vPMU register
    values that were restored by userspace haven't been propagated yet
    (the PMU events haven't been created) at the vcpu load-time on the
    first KVM_RUN (kvm_vcpu_pmu_restore_guest() called from vcpu_load()
    on the first KVM_RUN won't do anything as events_{guest,host} of
    kvm_pmu_events are still zero).
    
    So, with VHE, enable the guest's EL0 event counting on the first
    KVM_RUN (after the migration) when needed.  More specifically,
    have kvm_pmu_handle_pmcr() call kvm_vcpu_pmu_restore_guest()
    so that kvm_pmu_handle_pmcr() on the first KVM_RUN can take
    care of it.
    
    Fixes: d0c94c49792c ("KVM: arm64: Restore PMU configuration on first run")
    Cc: stable@vger.kernel.org
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Reiji Watanabe <reijiw@google.com>
    Link: https://lore.kernel.org/r/20230329023944.2488484-1-reijiw@google.com
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e7d87616bda31ca4e6304bdebb6ca1beebf22d9
Author: Christophe Kerello <christophe.kerello@foss.st.com>
Date:   Tue Mar 28 17:58:19 2023 +0200

    mtd: rawnand: stm32_fmc2: use timings.mode instead of checking tRC_min
    
    commit ddbb664b6ab8de7dffa388ae0c88cd18616494e5 upstream.
    
    Use timings.mode value instead of checking tRC_min timing
    for EDO mode support.
    
    Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
    Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver")
    Cc: stable@vger.kernel.org #v5.10+
    Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230328155819.225521-3-christophe.kerello@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit caad39579010d17a78f8d68cd8f7c631acabfc35
Author: Christophe Kerello <christophe.kerello@foss.st.com>
Date:   Tue Mar 28 17:58:18 2023 +0200

    mtd: rawnand: stm32_fmc2: remove unsupported EDO mode
    
    commit f71e0e329c152c7f11ddfd97ffc62aba152fad3f upstream.
    
    Remove the EDO mode support from as the FMC2 controller does not
    support the feature.
    
    Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
    Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver")
    Cc: stable@vger.kernel.org #v5.4+
    Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230328155819.225521-2-christophe.kerello@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adcb8f32b244afc9890e73df6e9d9059e7e99dc2
Author: Arseniy Krasnov <avkrasnov@sberdevices.ru>
Date:   Wed Mar 29 10:47:26 2023 +0300

    mtd: rawnand: meson: fix bitmask for length in command word
    
    commit 93942b70461574ca7fc3d91494ca89b16a4c64c7 upstream.
    
    Valid mask is 0x3FFF, without this patch the following problems were
    found:
    
    1) [    0.938914] Could not find a valid ONFI parameter page, trying
                      bit-wise majority to recover it
       [    0.947384] ONFI parameter recovery failed, aborting
    
    2) Read with disabled ECC mode was broken.
    
    Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/3794ffbf-dfea-e96f-1f97-fe235b005e19@sberdevices.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 928cdec4944071764a198f2b1284d58b2ed23ad0
Author: Bang Li <libang.linuxer@gmail.com>
Date:   Wed Mar 29 00:30:12 2023 +0800

    mtdblock: tolerate corrected bit-flips
    
    commit 0c3089601f064d80b3838eceb711fcac04bceaad upstream.
    
    mtd_read() may return -EUCLEAN in case of corrected bit-flips.This
    particular condition should not be treated like an error.
    
    Signed-off-by: Bang Li <libang.linuxer@gmail.com>
    Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
    Cc: <stable@vger.kernel.org> # v3.7
    Acked-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230328163012.4264-1-libang.linuxer@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8afd5221f5de3f0dac2a6f0f625cda9da8f1ae8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 4 21:39:34 2023 +0200

    fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
    
    commit 6fd33a3333c7916689b8f051a185defe4dd515b0 upstream.
    
    This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
    restore") - I failed to realize that nasty userspace could set this.
    
    It's not pretty to mix up kernel-internal and userspace uapi flags
    like this, but since the entire fb_var_screeninfo structure is uapi
    we'd need to either add a new parameter to the ->fb_set_par callback
    and fb_set_par() function, which has a _lot_ of users. Or some other
    fairly ugly side-channel int fb_info. Neither is a pretty prospect.
    
    Instead just correct the issue at hand by filtering out this
    kernel-internal flag in the ioctl handling code.
    
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: shlomo@fastmail.com
    Cc: Michel Dänzer <michel@daenzer.net>
    Cc: Noralf Trønnes <noralf@tronnes.org>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Daniel Vetter <daniel.vetter@intel.com>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v5.7+
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Nathan Chancellor <natechancellor@gmail.com>
    Cc: Qiujun Huang <hqjagain@gmail.com>
    Cc: Peter Rosin <peda@axentia.se>
    Cc: linux-fbdev@vger.kernel.org
    Cc: Helge Deller <deller@gmx.de>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Shigeru Yoshida <syoshida@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230404193934.472457-1-daniel.vetter@ffwll.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60a17be360a55afcc5f0da577a6c25fac5233448
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Mar 29 09:13:05 2023 +0900

    btrfs: fix fast csum implementation detection
    
    commit 68d99ab0e9221ef54506f827576c5a914680eeaf upstream.
    
    The BTRFS_FS_CSUM_IMPL_FAST flag is currently set whenever a non-generic
    crc32c is detected, which is the incorrect check if the file system uses
    a different checksumming algorithm.  Refactor the code to only check
    this if crc32c is actually used.  Note that in an ideal world the
    information if an algorithm is hardware accelerated or not should be
    provided by the crypto API instead, but that's left for another day.
    
    CC: stable@vger.kernel.org # 5.4.x: c8a5f8ca9a9c: btrfs: print checksum type and implementation at mount time
    CC: stable@vger.kernel.org # 5.4.x
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cee77e41c6ad3c788325eee9590730cbd7e7bbd9
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Mar 28 12:56:13 2023 +0900

    btrfs: restore the thread_pool= behavior in remount for the end I/O workqueues
    
    commit 40fac6472f22a59f5694496e179988ab4a1dfe07 upstream.
    
    Commit d7b9416fe5c5 ("btrfs: remove btrfs_end_io_wq") converted the read
    and I/O handling from btrfs_workqueues to Linux workqueues, and as part
    of that lost the code to apply the thread_pool= based max_active limit
    on remount.  Restore it.
    
    Fixes: d7b9416fe5c5 ("btrfs: remove btrfs_end_io_wq")
    CC: stable@vger.kernel.org # 6.0+
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dba0f922d57408fdbd32b9964fcca1d3f1acc9c2
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Apr 3 14:19:14 2023 -0700

    Bluetooth: hci_conn: Fix possible UAF
    
    commit 5dc7d23e167e2882ef118456ceccd57873e876d8 upstream.
    
    This fixes the following trace:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in hci_conn_del+0xba/0x3a0
    Write of size 8 at addr ffff88800208e9c8 by task iso-tester/31
    
    CPU: 0 PID: 31 Comm: iso-tester Not tainted 6.3.0-rc2-g991aa4a69a47
     #4716
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc36
    04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x1d/0x70
     print_report+0xce/0x610
     ? __virt_addr_valid+0xd4/0x150
     ? hci_conn_del+0xba/0x3a0
     kasan_report+0xdd/0x110
     ? hci_conn_del+0xba/0x3a0
     hci_conn_del+0xba/0x3a0
     hci_conn_hash_flush+0xf2/0x120
     hci_dev_close_sync+0x388/0x920
     hci_unregister_dev+0x122/0x260
     vhci_release+0x4f/0x90
     __fput+0x102/0x430
     task_work_run+0xf1/0x160
     ? __pfx_task_work_run+0x10/0x10
     ? mark_held_locks+0x24/0x90
     exit_to_user_mode_prepare+0x170/0x180
     syscall_exit_to_user_mode+0x19/0x50
     do_syscall_64+0x4e/0x90
     entry_SYSCALL_64_after_hwframe+0x70/0xda
    
    Fixes: 0f00cd322d22 ("Bluetooth: Free potentially unfreed SCO connection")
    Link: https://syzkaller.appspot.com/bug?extid=8bb72f86fc823817bc5d
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac9f4bac140f89e996bc97c8989dd1ba324ea39b
Author: Archie Pusaka <apusaka@chromium.org>
Date:   Fri Feb 3 17:30:55 2023 +0800

    Bluetooth: Free potentially unfreed SCO connection
    
    commit 0f00cd322d22d4441de51aa80bcce5bb6a8cbb44 upstream.
    
    It is possible to initiate a SCO connection while deleting the
    corresponding ACL connection, e.g. in below scenario:
    
    (1) < hci setup sync connect command
    (2) > hci disconn complete event (for the acl connection)
    (3) > hci command complete event (for(1), failure)
    
    When it happens, hci_cs_setup_sync_conn won't be able to obtain the
    reference to the SCO connection, so it will be stuck and potentially
    hinder subsequent connections to the same device.
    
    This patch prevents that by also deleting the SCO connection if it is
    still not established when the corresponding ACL connection is deleted.
    
    Signed-off-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Ying Hsu <yinghsu@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89395943819935875bc225f77264627ce3dd34d8
Author: Sasha Finkelstein <fnkl.kernel@gmail.com>
Date:   Fri Mar 10 11:28:42 2023 +0100

    bluetooth: btbcm: Fix logic error in forming the board name.
    
    commit b76abe4648c1acc791a207e7c08d1719eb9f4ea8 upstream.
    
    This patch fixes an incorrect loop exit condition in code that replaces
    '/' symbols in the board name. There might also be a memory corruption
    issue here, but it is unlikely to be a real problem.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 248af9feca062a4ca9c3f2ccf67056c8a5eb817f
Author: Min Li <lm0963hack@gmail.com>
Date:   Sat Mar 4 22:23:30 2023 +0800

    Bluetooth: Fix race condition in hidp_session_thread
    
    commit c95930abd687fcd1aa040dc4fe90dff947916460 upstream.
    
    There is a potential race condition in hidp_session_thread that may
    lead to use-after-free. For instance, the timer is active while
    hidp_del_timer is called in hidp_session_thread(). After hidp_session_put,
    then 'session' will be freed, causing kernel panic when hidp_idle_timeout
    is running.
    
    The solution is to use del_timer_sync instead of del_timer.
    
    Here is the call trace:
    
    ? hidp_session_probe+0x780/0x780
    call_timer_fn+0x2d/0x1e0
    __run_timers.part.0+0x569/0x940
    hidp_session_probe+0x780/0x780
    call_timer_fn+0x1e0/0x1e0
    ktime_get+0x5c/0xf0
    lapic_next_deadline+0x2c/0x40
    clockevents_program_event+0x205/0x320
    run_timer_softirq+0xa9/0x1b0
    __do_softirq+0x1b9/0x641
    __irq_exit_rcu+0xdc/0x190
    irq_exit_rcu+0xe/0x20
    sysvec_apic_timer_interrupt+0xa1/0xc0
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Min Li <lm0963hack@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d82a439c3cfdb28aa7e82e2e849c5c4dd9fca284
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Apr 6 09:33:09 2023 -0700

    Bluetooth: L2CAP: Fix use-after-free in l2cap_disconnect_{req,rsp}
    
    commit a2a9339e1c9deb7e1e079e12e27a0265aea8421a upstream.
    
    Similar to commit d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free
    caused by l2cap_chan_put"), just use l2cap_chan_hold_unless_zero to
    prevent referencing a channel that is about to be destroyed.
    
    Cc: stable@kernel.org
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Min Li <lm0963hack@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f09c9049b7cdd6b4da37b8809ad011f2fdc5fb2
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Thu Apr 13 22:11:53 2023 +0300

    ALSA: hda/hdmi: disable KAE for Intel DG2
    
    commit 6ab6f98fcdc9d4fbe245aa67de03542deea65322 upstream.
    
    Use of keep-alive (KAE) has resulted in loss of audio on some A750/770
    cards as the transition from keep-alive to stream playback is not
    working as expected. As there is limited benefit of the new KAE mode
    on discrete cards, revert back to older silent-stream implementation
    on these systems.
    
    Cc: stable@vger.kernel.org
    Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2")
    Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8307
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20230413191153.3692049-1-kai.vehmanen@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae1eaba8369561ac29320e0f4c331ec8701e81e8
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Wed Apr 5 22:12:20 2023 +0200

    ALSA: hda/sigmatel: fix S/PDIF out on Intel D*45* motherboards
    
    commit f342ac00da1064eb4f94b1f4bcacbdfea955797a upstream.
    
    The BIOS botches this one completely - it says the 2nd S/PDIF output is
    used, while in fact it's the 1st one. This is tested on DP45SG, but I'm
    assuming it's valid for the other boards in the series as well.
    
    Also add some comments regarding the pins.
    FWIW, the codec is apparently still sold by Tempo Semiconductor, Inc.,
    where one can download the documentation.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230405201220.2197826-2-oswald.buddenhagen@gmx.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4b56afa299f63c56b8c0cdb4f50aa33634dc277
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Wed Apr 5 22:12:20 2023 +0200

    ALSA: emu10k1: don't create old pass-through playback device on Audigy
    
    commit 8dd13214a810c695044aa168c0ddba1a9c433e4f upstream.
    
    It could have never worked, as snd_emu10k1_fx8010_playback_prepare() and
    snd_emu10k1_fx8010_playback_hw_free() assume the emu10k1 offset for the
    ETRAM, and the default DSP code includes no handler for it. It also
    wouldn't make a lot of sense to make it work, as Audigy has an own, much
    simpler, pass-through mechanism. So just skip creation of the device.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230405201220.2197938-1-oswald.buddenhagen@gmx.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60abed5d86c589404b1c493256e7112cf6c2fd25
Author: Xu Biang <xubiang@hust.edu.cn>
Date:   Thu Apr 6 06:28:01 2023 -0700

    ALSA: firewire-tascam: add missing unwind goto in snd_tscm_stream_start_duplex()
    
    commit fb4a624f88f658c7b7ae124452bd42eaa8ac7168 upstream.
    
    Smatch Warns:
    sound/firewire/tascam/tascam-stream.c:493 snd_tscm_stream_start_duplex()
    warn: missing unwind goto?
    
    The direct return will cause the stream list of "&tscm->domain" unemptied
    and the session in "tscm" unfinished if amdtp_domain_start() returns with
    an error.
    
    Fix this by changing the direct return to a goto which will empty the
    stream list of "&tscm->domain" and finish the session in "tscm".
    
    The snd_tscm_stream_start_duplex() function is called in the prepare
    callback of PCM. According to "ALSA Kernel API Documentation", the prepare
    callback of PCM will be called many times at each setup. So, if the
    "&d->streams" list is not emptied, when the prepare callback is called
    next time, snd_tscm_stream_start_duplex() will receive -EBUSY from
    amdtp_domain_add_stream() that tries to add an existing stream to the
    domain. The error handling code after the "error" label will be executed
    in this case, and the "&d->streams" list will be emptied. So not emptying
    the "&d->streams" list will not cause an issue. But it is more efficient
    and readable to empty it on the first error by changing the direct return
    to a goto statement.
    
    The session in "tscm" has been begun before amdtp_domain_start(), so it
    needs to be finished when amdtp_domain_start() fails.
    
    Fixes: c281d46a51e3 ("ALSA: firewire-tascam: support AMDTP domain")
    Signed-off-by: Xu Biang <xubiang@hust.edu.cn>
    Reviewed-by: Dan Carpenter <error27@gmail.com>
    Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230406132801.105108-1-xubiang@hust.edu.cn
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 886f7b69e59cf46e43c388abece0174463a0229c
Author: Stefan Binding <sbinding@opensource.cirrus.com>
Date:   Wed Apr 12 17:05:31 2023 +0100

    ALSA: hda/realtek: Add quirks for Lenovo Z13/Z16 Gen2
    
    commit 8eda19cd59cedbfe4ec11aea4bcecabe4c98e9e4 upstream.
    
    These Lenovo laptops use Realtek HDA codec combined with
    2xCS35L41 Amplifiers using I2C with External Boost.
    
    Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230412160531.182007-1-sbinding@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b683905134ad05e2f4a7adfa20ae7248883e775
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Apr 6 10:27:25 2023 -0500

    ALSA: hda: patch_realtek: add quirk for Asus N7601ZM
    
    commit e959f2beec8e655dba79c5a7111beedae5e757e0 upstream.
    
    Add pins and verbs needed to enable speakers and jack.
    
    The pins and verbs configurations were identified by snooping the
    Windows driver commands, with a nice write-up here:
    https://brakkee.org/site/2023/02/07/fixing-sound-on-the-asus-n7601zm/
    
    Reported-by: Erik Brakkee <erik@brakkee.org>
    Link: https://github.com/thesofproject/linux/issues/4176
    Tested-by: Erik Brakkee <erik@brakkee.org>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230406152725.15191-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81b1feaf1bcedac225d8756775500d3da3d4f02a
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Wed Apr 5 22:12:19 2023 +0200

    ALSA: i2c/cs8427: fix iec958 mixer control deactivation
    
    commit e98e7a82bca2b6dce3e03719cff800ec913f9af7 upstream.
    
    snd_cs8427_iec958_active() would always delete
    SNDRV_CTL_ELEM_ACCESS_INACTIVE, even though the function has an
    argument `active`.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230405201219.2197811-1-oswald.buddenhagen@gmx.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9496a3c14f4e61d2962f82f97870118bc3f5276
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Wed Apr 5 22:12:19 2023 +0200

    ALSA: hda/sigmatel: add pin overrides for Intel DP45SG motherboard
    
    commit c17f8fd31700392b1bb9e7b66924333568cb3700 upstream.
    
    Like the other boards from the D*45* series, this one sets up the
    outputs not quite correctly.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230405201220.2197826-1-oswald.buddenhagen@gmx.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85f211f797a89fee40a3ae345b699cae9f0f7f32
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Wed Apr 5 22:12:20 2023 +0200

    ALSA: emu10k1: fix capture interrupt handler unlinking
    
    commit b09c551c77c7e01dc6e4f3c8bf06b5ffa7b06db5 upstream.
    
    Due to two copy/pastos, closing the MIC or EFX capture device would
    make a running ADC capture hang due to unsetting its interrupt handler.
    In principle, this would have also allowed dereferencing dangling
    pointers, but we're actually rather thorough at disabling and flushing
    the ints.
    
    While it may sound like one, this actually wasn't a hypothetical bug:
    PortAudio will open a capture stream at startup (and close it right
    away) even if not asked to. If the first device is busy, it will just
    proceed with the next one ... thus killing a concurrent capture.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230405201220.2197923-1-oswald.buddenhagen@gmx.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7ed73b767bcc27b39e79f6bcdb7bddd1f9a949a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Mar 20 11:54:36 2023 +0200

    drm/i915: Workaround ICL CSC_MODE sticky arming
    
    commit 4d4e766f8b7dbdefa7a78e91eb9c7a29d0d818b8 upstream.
    
    Unlike SKL/GLK the ICL CSC unit suffers from a new issue where
    CSC_MODE arming is sticky. That is, once armed it remains armed
    causing the CSC coeff/offset registers to become effectively
    self-arming.
    
    CSC coeff/offset registers writes no longer disarm the CSC,
    but fortunately register read still do. So we can use that
    to disarm the CSC unit once the registers for the current
    frame have been latched. This avoid s the self-arming behaviour
    from persisting into the next frame's .color_commit_noarm()
    call.
    
    Cc: <stable@vger.kernel.org> #v5.19+
    Cc: Manasi Navare <navaremanasi@google.com>
    Cc: Drew Davenport <ddavenport@chromium.org>
    Cc: Imre Deak <imre.deak@intel.com>
    Cc: Jouni Högander <jouni.hogander@intel.com>
    Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-5-ville.syrjala@linux.intel.com
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    (cherry picked from commit 92736f1b452bbb8a66bdb5b1d263ad00e04dd3b8)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3715df26444e9c3ba922d347e87c7caec422a6f2
Author: Wayne Lin <Wayne.Lin@amd.com>
Date:   Fri Feb 17 13:26:56 2023 +0800

    drm/amd/display: Pass the right info to drm_dp_remove_payload
    
    commit b8ca445f550a9a079134f836466ddda3bfad6108 upstream.
    
    [Why & How]
    drm_dp_remove_payload() interface was changed. Correct amdgpu dm code
    to pass the right parameter to the drm helper function.
    
    Reviewed-by: Jerry Zuo <Jerry.Zuo@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry-picked from b8ca445f550a9a079134f836466ddda3bfad6108)
    [Hand modified due to missing f0127cb11299df80df45583b216e13f27c408545 which
     failed to apply due to missing 94dfeaa46925bb6b4d43645bbb6234e846dec257]
    Reported-and-tested-by: Veronika Schwan <veronika@pisquaredover6.de>
    Fixes: d7b5638bd337 ("drm/amd/display: Take FEC Overhead into Timeslot Calculation")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75facd07cc0c41ca0c8de649c7bcf439e1de2e1b
Author: Kornel Dulęba <korneld@chromium.org>
Date:   Tue Apr 11 13:49:32 2023 +0000

    Revert "pinctrl: amd: Disable and mask interrupts on resume"
    
    commit 534e465845ebfb4a97eb5459d3931a0b35e3b9a5 upstream.
    
    This reverts commit b26cd9325be4c1fcd331b77f10acb627c560d4d7.
    
    This patch introduces a regression on Lenovo Z13, which can't wake
    from the lid with it applied; and some unspecified AMD based Dell
    platforms are unable to wake from hitting the power button
    
    Signed-off-by: Kornel Dulęba <korneld@chromium.org>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20230411134932.292287-1-korneld@chromium.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>