Linux 6.1.8

 
ACPI: PRM: Check whether EFI runtime is available [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Jan 12 14:33:19 2023 +0100

    ACPI: PRM: Check whether EFI runtime is available
    
    commit 182da6f2b81a78709c58021542fb694f8ed80774 upstream.
    
    The ACPI PRM address space handler calls efi_call_virt_pointer() to
    execute PRM firmware code, but doing so is only permitted when the EFI
    runtime environment is available. Otherwise, such calls are guaranteed
    to result in a crash, and must therefore be avoided.
    
    Given that the EFI runtime services may become unavailable after a crash
    occurring in the firmware, we need to check this each time the PRM
    address space handler is invoked. If the EFI runtime services were not
    available at registration time to being with, don't install the address
    space handler at all.
    
    Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Add exception protection processing for vd in axi_chan_handle_err function [+ + +]
Author: Shawn.Shao <shawn.shao@jaguarmicro.com>
Date:   Thu Jan 12 13:58:02 2023 +0800

    Add exception protection processing for vd in axi_chan_handle_err function
    
    commit 57054fe516d59d03a7bcf1888e82479ccc244f87 upstream.
    
    Since there is no protection for vd, a kernel panic will be
    triggered here in exceptional cases.
    
    You can refer to the processing of axi_chan_block_xfer_complete function
    
    The triggered kernel panic is as follows:
    
    [   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
    [   67.848447] Mem abort info:
    [   67.848449]   ESR = 0x96000004
    [   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   67.848454]   SET = 0, FnV = 0
    [   67.848456]   EA = 0, S1PTW = 0
    [   67.848458] Data abort info:
    [   67.848460]   ISV = 0, ISS = 0x00000004
    [   67.848462]   CM = 0, WnR = 0
    [   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000
    [   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000
    [   67.848472] Internal error: Oops: 96000004 [#1] SMP
    [   67.848475] Modules linked in: dmatest
    [   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11
    [   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)
    [   67.848487] pc : axi_chan_handle_err+0xc4/0x230
    [   67.848491] lr : axi_chan_handle_err+0x30/0x230
    [   67.848493] sp : ffff0803fe55ae50
    [   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200
    [   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080
    [   67.848504] x25: ffff800010d33880 x24: ffff80001139d850
    [   67.848508] x23: ffff0800c097c168 x22: 0000000000000000
    [   67.848512] x21: 0000000000000080 x20: 0000000000002000
    [   67.848517] x19: ffff0800c097c080 x18: 0000000000000000
    [   67.848521] x17: 0000000000000000 x16: 0000000000000000
    [   67.848525] x15: 0000000000000000 x14: 0000000000000000
    [   67.848529] x13: 0000000000000000 x12: 0000000000000040
    [   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a
    [   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270
    [   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0
    [   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480
    [   67.848550] x3 : dead000000000100 x2 : dead000000000122
    [   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168
    [   67.848559] Call trace:
    [   67.848562]  axi_chan_handle_err+0xc4/0x230
    [   67.848566]  dw_axi_dma_interrupt+0xf4/0x590
    [   67.848569]  __handle_irq_event_percpu+0x60/0x220
    [   67.848573]  handle_irq_event+0x64/0x120
    [   67.848576]  handle_fasteoi_irq+0xc4/0x220
    [   67.848580]  __handle_domain_irq+0x80/0xe0
    [   67.848583]  gic_handle_irq+0xc0/0x138
    [   67.848585]  el1_irq+0xc8/0x180
    [   67.848588]  arch_cpu_idle+0x14/0x2c
    [   67.848591]  default_idle_call+0x40/0x16c
    [   67.848594]  do_idle+0x1f0/0x250
    [   67.848597]  cpu_startup_entry+0x2c/0x60
    [   67.848600]  rest_init+0xc0/0xcc
    [   67.848603]  arch_call_rest_init+0x14/0x1c
    [   67.848606]  start_kernel+0x4cc/0x500
    [   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)
    [   67.848613] ---[ end trace 585a97036f88203a ]---
    
    Signed-off-by: Shawn.Shao <shawn.shao@jaguarmicro.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230112055802.1764-1-shawn.shao@jaguarmicro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: dts: imx8mp: correct usb clocks [+ + +]
Author: Li Jun <jun.li@nxp.com>
Date:   Fri Sep 30 22:54:23 2022 +0800

    arm64: dts: imx8mp: correct usb clocks
    
    commit 8a1ed98fe0f2e7669f0409de0f46f317b275f8be upstream.
    
    After commit cf7f3f4fa9e5 ("clk: imx8mp: fix usb_root_clk parent"),
    usb_root_clk is no longer for suspend clock so update dts accordingly
    to use right bus clock and suspend clock.
    
    Fixes: fb8587a2c165 ("arm64: dtsi: imx8mp: add usb nodes")
    Cc: stable@vger.kernel.org # ed1f4ccfe947: clk: imx: imx8mp: add shared clk gate for usb suspend clk
    Cc: stable@vger.kernel.org # v5.19+
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: efi: Execute runtime services from a dedicated stack [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Dec 5 11:31:25 2022 +0100

    arm64: efi: Execute runtime services from a dedicated stack
    
    commit ff7a167961d1b97e0e205f245f806e564d3505e7 upstream.
    
    With the introduction of PRMT in the ACPI subsystem, the EFI rts
    workqueue is no longer the only caller of efi_call_virt_pointer() in the
    kernel. This means the EFI runtime services lock is no longer sufficient
    to manage concurrent calls into firmware, but also that firmware calls
    may occur that are not marshalled via the workqueue mechanism, but
    originate directly from the caller context.
    
    For added robustness, and to ensure that the runtime services have 8 KiB
    of stack space available as per the EFI spec, introduce a spinlock
    protected EFI runtime stack of 8 KiB, where the spinlock also ensures
    serialization between the EFI rts workqueue (which itself serializes EFI
    runtime calls) and other callers of efi_call_virt_pointer().
    
    While at it, use the stack pivot to avoid reloading the shadow call
    stack pointer from the ordinary stack, as doing so could produce a
    gadget to defeat it.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Lee Jones <lee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: dts: qcom: apq8084-ifc6540: fix overriding SDHCI [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Dec 4 09:46:14 2022 +0100

    ARM: dts: qcom: apq8084-ifc6540: fix overriding SDHCI
    
    commit 0154252a3b87f77db1e44516d1ed2e82e2d29c30 upstream.
    
    While changing node names of APQ8084 SDHCI, the ones in IFC6540 board
    were not updated leading to disabled and misconfigured SDHCI.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 2477d81901a2 ("ARM: dts: qcom: Fix sdhci node names - use 'mmc@'")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221204084614.12193-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: omap1: fix !ARCH_OMAP1_ANY link failures [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 4 09:35:09 2023 +0100

    ARM: omap1: fix !ARCH_OMAP1_ANY link failures
    
    commit 980a637d11fe8dfc734f508a422185c2de55e669 upstream.
    
    While compile-testing randconfig builds for the upcoming boardfile
    removal, I noticed that an earlier patch of mine was completely
    broken, and the introduction of CONFIG_ARCH_OMAP1_ANY only replaced
    one set of build failures with another one, now resulting in
    link failures like
    
    ld: drivers/video/fbdev/omap/omapfb_main.o: in function `omapfb_do_probe':
    drivers/video/fbdev/omap/omapfb_main.c:1703: undefined reference to `omap_set_dma_priority'
    ld: drivers/dma/ti/omap-dma.o: in function `omap_dma_free_chan_resources':
    drivers/dma/ti/omap-dma.c:777: undefined reference to `omap_free_dma'
    drivers/dma/ti/omap-dma.c:1685: undefined reference to `omap_get_plat_info'
    ld: drivers/usb/gadget/udc/omap_udc.o: in function `next_in_dma':
    drivers/usb/gadget/udc/omap_udc.c:820: undefined reference to `omap_get_dma_active_status'
    
    I tried reworking it, but the resulting patch ended up much bigger than
    simply avoiding the original problem of unused-function warnings like
    
    arch/arm/mach-omap1/mcbsp.c:76:30: error: unused variable 'omap1_mcbsp_ops' [-Werror,-Wunused-variable]
    
    As a result, revert the previous fix, and rearrange the code that
    produces warnings to hide them. For mcbsp, the #ifdef check can
    simply be removed as the cpu_is_omapxxx() checks already achieve
    the same result, while in the io.c the easiest solution appears to
    be to merge the common map bits into each soc specific portion.
    This gets cleaned in a nicer way after omap7xx support gets dropped,
    as the remaining SoCs all have the exact same I/O map.
    
    Fixes: 615dce5bf736 ("ARM: omap1: fix build with no SoC selected")
    Cc: stable@vger.kernel.org
    Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: mq-deadline: Rename deadline_is_seq_writes() [+ + +]
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Sat Nov 26 11:55:49 2022 +0900

    block: mq-deadline: Rename deadline_is_seq_writes()
    
    commit 3692fec8bb476e8583e559ff5783a6adef306cf2 upstream.
    
    Rename deadline_is_seq_writes() to deadline_is_seq_write() (remove the
    "s" plural) to more correctly reflect the fact that this function tests
    a single request, not multiple requests.
    
    Fixes: 015d02f48537 ("block: mq-deadline: Do not break sequential write streams to zoned HDDs")
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Link: https://lore.kernel.org/r/20221126025550.967914-2-damien.lemoal@opensource.wdc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: hci_qca: Fix driver shutdown on closed serdev [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Dec 29 11:28:29 2022 +0100

    Bluetooth: hci_qca: Fix driver shutdown on closed serdev
    
    commit 272970be3dabd24cbe50e393ffee8f04aec3b9a8 upstream.
    
    The driver shutdown callback (which sends EDL_SOC_RESET to the device
    over serdev) should not be invoked when HCI device is not open (e.g. if
    hci_dev_open_sync() failed), because the serdev and its TTY are not open
    either.  Also skip this step if device is powered off
    (qca_power_shutdown()).
    
    The shutdown callback causes use-after-free during system reboot with
    Qualcomm Atheros Bluetooth:
    
      Unable to handle kernel paging request at virtual address
      0072662f67726fd7
      ...
      CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G        W
      6.1.0-rt5-00325-g8a5f56bcfcca #8
      Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
      Call trace:
       tty_driver_flush_buffer+0x4/0x30
       serdev_device_write_flush+0x24/0x34
       qca_serdev_shutdown+0x80/0x130 [hci_uart]
       device_shutdown+0x15c/0x260
       kernel_restart+0x48/0xac
    
    KASAN report:
    
      BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50
      Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1
    
      CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted
      6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28
      Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
      Call trace:
       dump_backtrace.part.0+0xdc/0xf0
       show_stack+0x18/0x30
       dump_stack_lvl+0x68/0x84
       print_report+0x188/0x488
       kasan_report+0xa4/0xf0
       __asan_load8+0x80/0xac
       tty_driver_flush_buffer+0x1c/0x50
       ttyport_write_flush+0x34/0x44
       serdev_device_write_flush+0x48/0x60
       qca_serdev_shutdown+0x124/0x274
       device_shutdown+0x1e8/0x350
       kernel_restart+0x48/0xb0
       __do_sys_reboot+0x244/0x2d0
       __arm64_sys_reboot+0x54/0x70
       invoke_syscall+0x60/0x190
       el0_svc_common.constprop.0+0x7c/0x160
       do_el0_svc+0x44/0xf0
       el0_svc+0x2c/0x6c
       el0t_64_sync_handler+0xbc/0x140
       el0t_64_sync+0x190/0x194
    
    Fixes: 7e7bbddd029b ("Bluetooth: hci_qca: Fix qca6390 enable failure after warm reboot")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2 [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Dec 19 13:32:51 2022 -0800

    Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2
    
    commit 3a4d29b6d631bb00236a98887e1039bbfc1b6ab5 upstream.
    
    Don't try to use HCI_OP_LE_READ_BUFFER_SIZE_V2 if controller don't
    support ISO channels, but in order to check if ISO channels are
    supported HCI_OP_LE_READ_LOCAL_FEATURES needs to be done earlier so the
    features bits can be checked on hci_le_read_buffer_size_sync.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216817
    Fixes: c1631dbc00c1 ("Bluetooth: hci_sync: Fix hci_read_buffer_size_sync")
    Cc: stable@vger.kernel.org # 6.1
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bpf: keep a reference to the mm, in case the task is dead. [+ + +]
Author: Kui-Feng Lee <kuifeng@meta.com>
Date:   Fri Dec 16 14:18:54 2022 -0800

    bpf: keep a reference to the mm, in case the task is dead.
    
    [ Upstream commit 7ff94f276f8ea05df82eb115225e9b26f47a3347 ]
    
    Fix the system crash that happens when a task iterator travel through
    vma of tasks.
    
    In task iterators, we used to access mm by following the pointer on
    the task_struct; however, the death of a task will clear the pointer,
    even though we still hold the task_struct.  That can cause an
    unexpected crash for a null pointer when an iterator is visiting a
    task that dies during the visit.  Keeping a reference of mm on the
    iterator ensures we always have a valid pointer to mm.
    
    Co-developed-by: Song Liu <song@kernel.org>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Kui-Feng Lee <kuifeng@meta.com>
    Reported-by: Nathan Slingerland <slinger@meta.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20221216221855.4122288-2-kuifeng@meta.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD and PERF_BPF_EVENT_PROG_UNLOAD [+ + +]
Author: Paul Moore <paul@paul-moore.com>
Date:   Fri Jan 6 10:43:59 2023 -0500

    bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD and PERF_BPF_EVENT_PROG_UNLOAD
    
    commit ef01f4e25c1760920e2c94f1c232350277ace69b upstream.
    
    When changing the ebpf program put() routines to support being called
    from within IRQ context the program ID was reset to zero prior to
    calling the perf event and audit UNLOAD record generators, which
    resulted in problems as the ebpf program ID was bogus (always zero).
    This patch addresses this problem by removing an unnecessary call to
    bpf_prog_free_id() in __bpf_prog_offload_destroy() and adjusting
    __bpf_prog_put() to only call bpf_prog_free_id() after audit and perf
    have finished their bpf program unload tasks in
    bpf_prog_put_deferred().  For the record, no one can determine, or
    remember, why it was necessary to free the program ID, and remove it
    from the IDR, prior to executing bpf_prog_put_deferred();
    regardless, both Stanislav and Alexei agree that the approach in this
    patch should be safe.
    
    It is worth noting that when moving the bpf_prog_free_id() call, the
    do_idr_lock parameter was forced to true as the ebpf devs determined
    this was the correct as the do_idr_lock should always be true.  The
    do_idr_lock parameter will be removed in a follow-up patch, but it
    was kept here to keep the patch small in an effort to ease any stable
    backports.
    
    I also modified the bpf_audit_prog() logic used to associate the
    AUDIT_BPF record with other associated records, e.g. @ctx != NULL.
    Instead of keying off the operation, it now keys off the execution
    context, e.g. '!in_irg && !irqs_disabled()', which is much more
    appropriate and should help better connect the UNLOAD operations with
    the associated audit state (other audit records).
    
    Cc: stable@vger.kernel.org
    Fixes: d809e134be7a ("bpf: Prepare bpf_prog_put() to be called from irq context.")
    Reported-by: Burn Alting <burn.alting@iinet.net.au>
    Reported-by: Jiri Olsa <olsajiri@gmail.com>
    Suggested-by: Stanislav Fomichev <sdf@google.com>
    Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20230106154400.74211-1-paul@paul-moore.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: add extra error messages to cover non-ENOMEM errors from device_add_list() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Mon Dec 12 10:19:37 2022 +0800

    btrfs: add extra error messages to cover non-ENOMEM errors from device_add_list()
    
    commit ed02363fbbed52a3f5ea0d188edd09045a806eb5 upstream.
    
    [BUG]
    When test case btrfs/219 (aka, mount a registered device but with a lower
    generation) failed, there is not any useful information for the end user
    to find out what's going wrong.
    
    The mount failure just looks like this:
    
      #  mount -o loop /tmp/219.img2 /mnt/btrfs/
      mount: /mnt/btrfs: mount(2) system call failed: File exists.
             dmesg(1) may have more information after failed mount system call.
    
    While the dmesg contains nothing but the loop device change:
    
      loop1: detected capacity change from 0 to 524288
    
    [CAUSE]
    In device_list_add() we have a lot of extra checks to reject invalid
    cases.
    
    That function also contains the regular device scan result like the
    following prompt:
    
      BTRFS: device fsid 6222333e-f9f1-47e6-b306-55ddd4dcaef4 devid 1 transid 8 /dev/loop0 scanned by systemd-udevd (3027)
    
    But unfortunately not all errors have their own error messages, thus if
    we hit something wrong in device_add_list(), there may be no error
    messages at all.
    
    [FIX]
    Add errors message for all non-ENOMEM errors.
    
    For ENOMEM, I'd say we're in a much worse situation, and there should be
    some OOM messages way before our call sites.
    
    CC: stable@vger.kernel.org # 6.0+
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: add missing setup of log for full commit at add_conflicting_inode() [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jan 10 14:56:36 2023 +0000

    btrfs: add missing setup of log for full commit at add_conflicting_inode()
    
    commit 94cd63ae679973edeb5ea95ec25a54467c3e54c8 upstream.
    
    When logging conflicting inodes, if we reach the maximum limit of inodes,
    we return BTRFS_LOG_FORCE_COMMIT to force a transaction commit. However
    we don't mark the log for full commit (with btrfs_set_log_full_commit()),
    which means that once we leave the log transaction and before we commit
    the transaction, some other task may sync the log, which is incomplete
    as we have not logged all conflicting inodes, leading to some inconsistent
    in case that log ends up being replayed.
    
    So also call btrfs_set_log_full_commit() at add_conflicting_inode().
    
    Fixes: e09d94c9e448 ("btrfs: log conflicting inodes without holding log mutex of the initial inode")
    CC: stable@vger.kernel.org # 6.1
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: always report error in run_one_delayed_ref() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Mon Dec 26 09:00:40 2022 +0800

    btrfs: always report error in run_one_delayed_ref()
    
    [ Upstream commit 39f501d68ec1ed5cd5c66ac6ec2a7131c517bb92 ]
    
    Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but
    if end users hit such problem, there will be no chance that
    btrfs_debug() is enabled.  This can lead to very little useful info for
    debugging.
    
    This patch will:
    
    - Add extra info for error reporting
      Including:
      * logical bytenr
      * num_bytes
      * type
      * action
      * ref_mod
    
    - Replace the btrfs_debug() with btrfs_err()
    
    - Move the error reporting into run_one_delayed_ref()
      This is to avoid use-after-free, the @node can be freed in the caller.
    
    This error should only be triggered at most once.
    
    As if run_one_delayed_ref() failed, we trigger the error message, then
    causing the call chain to error out:
    
    btrfs_run_delayed_refs()
    `- btrfs_run_delayed_refs()
       `- btrfs_run_delayed_refs_for_head()
          `- run_one_delayed_ref()
    
    And we will abort the current transaction in btrfs_run_delayed_refs().
    If we have to run delayed refs for the abort transaction,
    run_one_delayed_ref() will just cleanup the refs and do nothing, thus no
    new error messages would be output.
    
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: do not abort transaction on failure to update log root [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jan 10 14:56:38 2023 +0000

    btrfs: do not abort transaction on failure to update log root
    
    commit 09e44868f1e03c7825ca4283256abedc95e249a3 upstream.
    
    When syncing a log, if we fail to update a log root in the log root tree,
    we are aborting the transaction if the failure was not -ENOSPC. This is
    excessive because there is a chance that a transaction commit can succeed,
    and therefore avoid to turn the filesystem into RO mode. All we need to be
    careful about is to mark the log for a full commit, which we already do,
    to make sure no one commits a super block pointing to an outdated log root
    tree.
    
    So don't abort the transaction if we fail to update a log root in the log
    root tree, and log an error if the failure is not -ENOSPC, so that it does
    not go completely unnoticed.
    
    CC: stable@vger.kernel.org # 6.0+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: do not abort transaction on failure to write log tree when syncing log [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jan 10 14:56:37 2023 +0000

    btrfs: do not abort transaction on failure to write log tree when syncing log
    
    commit 16199ad9eb6db60a6b10794a09fc1ac6d09312ff upstream.
    
    When syncing the log, if we fail to write log tree extent buffers, we mark
    the log for a full commit and abort the transaction. However we don't need
    to abort the transaction, all we really need to do is to make sure no one
    can commit a superblock pointing to new log tree roots. Just because we
    got a failure writing extent buffers for a log tree, it does not mean we
    will also fail to do a transaction commit.
    
    One particular case is if due to a bug somewhere, when writing log tree
    extent buffers, the tree checker detects some corruption and the writeout
    fails because of that. Aborting the transaction can be very disruptive for
    a user, specially if the issue happened on a root filesystem. One example
    is the scenario in the Link tag below, where an isolated corruption on log
    tree leaves was causing transaction aborts when syncing the log.
    
    Link: https://lore.kernel.org/linux-btrfs/ae169fc6-f504-28f0-a098-6fa6a4dfb612@leemhuis.info/
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix directory logging due to race with concurrent index key deletion [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jan 10 14:56:35 2023 +0000

    btrfs: fix directory logging due to race with concurrent index key deletion
    
    commit 8bb6898da6271d82d8e76d8088d66b971a7dcfa6 upstream.
    
    Sometimes we log a directory without holding its VFS lock, so while we
    logging it, dir index entries may be added or removed. This typically
    happens when logging a dentry from a parent directory that points to a
    new directory, through log_new_dir_dentries(), or when while logging
    some other inode we also need to log its parent directories (through
    btrfs_log_all_parents()).
    
    This means that while we are at log_dir_items(), we may not find a dir
    index key we found before, because it was deleted in the meanwhile, so
    a call to btrfs_search_slot() may return 1 (key not found). In that case
    we return from log_dir_items() with a success value (the variable 'err'
    has a value of 0). This can lead to a few problems, specially in the case
    where the variable 'last_offset' has a value of (u64)-1 (and it's
    initialized to that when it was declared):
    
    1) By returning from log_dir_items() with success (0) and a value of
       (u64)-1 for '*last_offset_ret', we end up not logging any other dir
       index keys that follow the missing, just deleted, index key. The
       (u64)-1 value makes log_directory_changes() not call log_dir_items()
       again;
    
    2) Before returning with success (0), log_dir_items(), will log a dir
       index range item covering a range from the last old dentry index
       (stored in the variable 'last_old_dentry_offset') to the value of
       'last_offset'. If 'last_offset' has a value of (u64)-1, then it means
       if the log is persisted and replayed after a power failure, it will
       cause deletion of all the directory entries that have an index number
       between last_old_dentry_offset + 1 and (u64)-1;
    
    3) We can end up returning from log_dir_items() with
       ctx->last_dir_item_offset having a lower value than
       inode->last_dir_index_offset, because the former is set to the current
       key we are processing at process_dir_items_leaf(), and at the end of
       log_directory_changes() we set inode->last_dir_index_offset to the
       current value of ctx->last_dir_item_offset. So if for example a
       deletion of a lower dir index key happened, we set
       ctx->last_dir_item_offset to that index value, then if we return from
       log_dir_items() because btrfs_search_slot() returned 1, we end up
       returning from log_dir_items() with success (0) and then
       log_directory_changes() sets inode->last_dir_index_offset to a lower
       value than it had before.
       This can result in unpredictable and unexpected behaviour when we
       need to log again the directory in the same transaction, and can result
       in ending up with a log tree leaf that has duplicated keys, as we do
       batch insertions of dir index keys into a log tree.
    
    So fix this by making log_dir_items() move on to the next dir index key
    if it does not find the one it was looking for.
    
    Reported-by: David Arendt <admin@prnet.org>
    Link: https://lore.kernel.org/linux-btrfs/ae169fc6-f504-28f0-a098-6fa6a4dfb612@leemhuis.info/
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix invalid leaf access due to inline extent during lseek [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 12 14:17:20 2023 +0000

    btrfs: fix invalid leaf access due to inline extent during lseek
    
    commit 1f55ee6d0901d915801618bda0af4e5b937e3db7 upstream.
    
    During lseek, for SEEK_DATA and SEEK_HOLE modes, we access the disk_bytenr
    of an extent without checking its type. However inline extents have their
    data starting the offset of the disk_bytenr field, so accessing that field
    when we have an inline extent can result in either of the following:
    
    1) Interpret the inline extent's data as a disk_bytenr value;
    
    2) In case the inline data is less than 8 bytes, we access part of some
       other item in the leaf, or unused space in the leaf;
    
    3) In case the inline data is less than 8 bytes and the extent item is
       the first item in the leaf, we can access beyond the leaf's limit.
    
    So fix this by not accessing the disk_bytenr field if we have an inline
    extent.
    
    Fixes: b6e833567ea1 ("btrfs: make hole and data seeking a lot more efficient")
    Reported-by: Matthias Schoepfer <matthias.schoepfer@googlemail.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216908
    Link: https://lore.kernel.org/linux-btrfs/7f25442f-b121-2a3a-5a3d-22bcaae83cd4@leemhuis.info/
    CC: stable@vger.kernel.org # 6.1
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix missing error handling when logging directory items [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jan 10 14:56:34 2023 +0000

    btrfs: fix missing error handling when logging directory items
    
    commit 6d3d970b2735b967650d319be27268fedc5598d1 upstream.
    
    When logging a directory, at log_dir_items(), if we get an error when
    attempting to search the subvolume tree for a dir index item, we end up
    returning 0 (success) from log_dir_items() because 'err' is left with a
    value of 0.
    
    This can lead to a few problems, specially in the case the variable
    'last_offset' has a value of (u64)-1 (and it's initialized to that when
    it was declared):
    
    1) By returning from log_dir_items() with success (0) and a value of
       (u64)-1 for '*last_offset_ret', we end up not logging any other dir
       index keys that follow the missing, just deleted, index key. The
       (u64)-1 value makes log_directory_changes() not call log_dir_items()
       again;
    
    2) Before returning with success (0), log_dir_items(), will log a dir
       index range item covering a range from the last old dentry index
       (stored in the variable 'last_old_dentry_offset') to the value of
       'last_offset'. If 'last_offset' has a value of (u64)-1, then it means
       if the log is persisted and replayed after a power failure, it will
       cause deletion of all the directory entries that have an index number
       between last_old_dentry_offset + 1 and (u64)-1;
    
    3) We can end up returning from log_dir_items() with
       ctx->last_dir_item_offset having a lower value than
       inode->last_dir_index_offset, because the former is set to the current
       key we are processing at process_dir_items_leaf(), and at the end of
       log_directory_changes() we set inode->last_dir_index_offset to the
       current value of ctx->last_dir_item_offset. So if for example a
       deletion of a lower dir index key happened, we set
       ctx->last_dir_item_offset to that index value, then if we return from
       log_dir_items() because btrfs_search_slot() returned an error, we end up
       returning without any error from log_dir_items() and then
       log_directory_changes() sets inode->last_dir_index_offset to a lower
       value than it had before.
       This can result in unpredictable and unexpected behaviour when we
       need to log again the directory in the same transaction, and can result
       in ending up with a log tree leaf that has duplicated keys, as we do
       batch insertions of dir index keys into a log tree.
    
    Fix this by setting 'err' to the value of 'ret' in case
    btrfs_search_slot() or btrfs_previous_item() returned an error. That will
    result in falling back to a full transaction commit.
    
    Reported-by: David Arendt <admin@prnet.org>
    Link: https://lore.kernel.org/linux-btrfs/ae169fc6-f504-28f0-a098-6fa6a4dfb612@leemhuis.info/
    Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix race between quota rescan and disable leading to NULL pointer deref [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 12 16:31:08 2023 +0000

    btrfs: fix race between quota rescan and disable leading to NULL pointer deref
    
    commit b7adbf9ada3513d2092362c8eac5cddc5b651f5c upstream.
    
    If we have one task trying to start the quota rescan worker while another
    one is trying to disable quotas, we can end up hitting a race that results
    in the quota rescan worker doing a NULL pointer dereference. The steps for
    this are the following:
    
    1) Quotas are enabled;
    
    2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
       It calls qgroup_rescan_init() which returns 0 (success) and then joins a
       transaction and commits it;
    
    3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
       It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls
       btrfs_qgroup_wait_for_completion(), which returns immediately since the
       rescan worker is not yet running.
       Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;
    
    4) Task A queues the rescan worker, by calling btrfs_queue_work();
    
    5) The rescan worker starts, and calls rescan_should_stop() at the start
       of its while loop, which results in 0 iterations of the loop, since
       the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by
       task B at step 3);
    
    6) Task B sets fs_info->quota_root to NULL;
    
    7) The rescan worker tries to start a transaction and uses
       fs_info->quota_root as the root argument for btrfs_start_transaction().
       This results in a NULL pointer dereference down the call chain of
       btrfs_start_transaction(). The stack trace is something like the one
       reported in Link tag below:
    
       general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
       KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
       CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
       Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
       Workqueue: btrfs-qgroup-rescan btrfs_work_helper
       RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
       Code: 48 89 fb 48 (...)
       RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
       RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
       RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
       R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
       R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
       FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        <TASK>
        btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402
        btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280
        process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
        worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
        kthread+0x266/0x300 kernel/kthread.c:376
        ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
        </TASK>
       Modules linked in:
    
    So fix this by having the rescan worker function not attempt to start a
    transaction if it didn't do any rescan work.
    
    Reported-by: syzbot+96977faa68092ad382c4@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-btrfs/000000000000e5454b05f065a803@google.com/
    Fixes: e804861bd4e6 ("btrfs: fix deadlock between quota disable and qgroup rescan worker")
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix trace event name typo for FLUSH_DELAYED_REFS [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Wed Dec 14 11:06:07 2022 +0900

    btrfs: fix trace event name typo for FLUSH_DELAYED_REFS
    
    [ Upstream commit 0a3212de8ab3e2ce5808c6265855e528d4a6767b ]
    
    Fix a typo of printing FLUSH_DELAYED_REFS event in flush_space() as
    FLUSH_ELAYED_REFS.
    
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: qgroup: do not warn on record without old_roots populated [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jan 10 15:14:17 2023 +0800

    btrfs: qgroup: do not warn on record without old_roots populated
    
    commit 75181406b4eafacc531ff2ee5fb032bd93317e2b upstream.
    
    [BUG]
    There are some reports from the mailing list that since v6.1 kernel, the
    WARN_ON() inside btrfs_qgroup_account_extent() gets triggered during
    rescan:
    
      WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]
      CPU: 3 PID: 6424 Comm: snapperd Tainted: P           OE      6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7
      RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]
      Call Trace:
       <TASK>
      btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
       ? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
      btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
       btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
       ? __rseq_handle_notify_resume+0xa9/0x4a0
       ? mntput_no_expire+0x4a/0x240
       ? __seccomp_filter+0x319/0x4d0
       __x64_sys_ioctl+0x90/0xd0
       do_syscall_64+0x5b/0x80
       ? syscall_exit_to_user_mode+0x17/0x40
       ? do_syscall_64+0x67/0x80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x7fd9b790d9bf
       </TASK>
    
    [CAUSE]
    Since commit e15e9f43c7ca ("btrfs: introduce
    BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting"), if
    our qgroup is already in inconsistent state, we will no longer do the
    time-consuming backref walk.
    
    This can leave some qgroup records without a valid old_roots ulist.
    Normally this is fine, as btrfs_qgroup_account_extents() would also skip
    those records if we have NO_ACCOUNTING flag set.
    
    But there is a small window, if we have NO_ACCOUNTING flag set, and
    inserted some qgroup_record without a old_roots ulist, but then the user
    triggered a qgroup rescan.
    
    During btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then
    commit current transaction.
    
    And since we have a qgroup_record with old_roots = NULL, we trigger the
    WARN_ON() during btrfs_qgroup_account_extents().
    
    [FIX]
    Unfortunately due to the introduction of NO_ACCOUNTING flag, the
    assumption that every qgroup_record would have its old_roots populated
    is no longer correct.
    
    Fix the false alerts and drop the WARN_ON().
    
    Reported-by: Lukas Straub <lukasstraub2@web.de>
    Reported-by: HanatoK <summersnow9403@gmail.com>
    Fixes: e15e9f43c7ca ("btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting")
    CC: stable@vger.kernel.org # 6.1
    Link: https://lore.kernel.org/linux-btrfs/2403c697-ddaf-58ad-3829-0335fc89df09@gmail.com/
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: do not include page data when checking signature [+ + +]
Author: Enzo Matsumiya <ematsumiya@suse.de>
Date:   Wed Jan 18 14:06:57 2023 -0300

    cifs: do not include page data when checking signature
    
    commit 30b2b2196d6e4cc24cbec633535a2404f258ce69 upstream.
    
    On async reads, page data is allocated before sending.  When the
    response is received but it has no data to fill (e.g.
    STATUS_END_OF_FILE), __calc_signature() will still include the pages in
    its computation, leading to an invalid signature check.
    
    This patch fixes this by not setting the async read smb_rqst page data
    (zeroed by default) if its got_bytes is 0.
    
    This can be reproduced/verified with xfstests generic/465.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: fix race in assemble_neg_contexts() [+ + +]
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Thu Dec 29 12:33:56 2022 -0300

    cifs: fix race in assemble_neg_contexts()
    
    [ Upstream commit 775e44d6d86dca400d614cbda5dab4def4951fe7 ]
    
    Serialise access of TCP_Server_Info::hostname in
    assemble_neg_contexts() by holding the server's mutex otherwise it
    might end up accessing an already-freed hostname pointer from
    cifs_reconnect() or cifs_resolve_server().
    
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: reduce roundtrips on create/qinfo requests [+ + +]
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Mon Dec 12 23:39:37 2022 -0300

    cifs: reduce roundtrips on create/qinfo requests
    
    commit c877ce47e1378dbafa6f1bf84c0c83a05ca8972a upstream.
    
    To work around some Window servers that return
    STATUS_OBJECT_NAME_INVALID on query infos under DFS namespaces that
    contain non-ASCII characters, we started checking for -ENOENT on every
    file open, and if so, then send additional requests to figure out
    whether it is a DFS link or not.  It means that all those requests
    will be sent to every non-existing file.
    
    So, in order to reduce the number of roundtrips, check earlier whether
    status code is STATUS_OBJECT_NAME_INVALID and tcon supports dfs, and
    if so, then map -ENOENT to -EREMOTE so mount or automount will take
    care of chasing the DFS link -- if it isn't an DFS link, then -ENOENT
    will be returned appropriately.
    
    Before patch
    
      SMB2 438 Create Request File: ada.test\dfs\foo;GetInfo Request...
      SMB2 310 Create Response, Error: STATUS_OBJECT_NAME_NOT_FOUND;...
      SMB2 228 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \ada.test\dfs\foo
      SMB2 143 Ioctl Response, Error: STATUS_OBJECT_PATH_NOT_FOUND
      SMB2 438 Create Request File: ada.test\dfs\foo;GetInfo Request...
      SMB2 310 Create Response, Error: STATUS_OBJECT_NAME_NOT_FOUND;...
      SMB2 228 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \ada.test\dfs\foo
      SMB2 143 Ioctl Response, Error: STATUS_OBJECT_PATH_NOT_FOUND
    
    After patch
    
      SMB2 438 Create Request File: ada.test\dfs\foo;GetInfo Request...
      SMB2 310 Create Response, Error: STATUS_OBJECT_NAME_NOT_FOUND;...
      SMB2 438 Create Request File: ada.test\dfs\foo;GetInfo Request...
      SMB2 310 Create Response, Error: STATUS_OBJECT_NAME_NOT_FOUND;...
    
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
comedi: adv_pci1760: Fix PWM instruction handling [+ + +]
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jan 3 14:37:54 2023 +0000

    comedi: adv_pci1760: Fix PWM instruction handling
    
    commit 2efb6edd52dc50273f5e68ad863dd1b1fb2f2d1c upstream.
    
    (Actually, this is fixing the "Read the Current Status" command sent to
    the device's outgoing mailbox, but it is only currently used for the PWM
    instructions.)
    
    The PCI-1760 is operated mostly by sending commands to a set of Outgoing
    Mailbox registers, waiting for the command to complete, and reading the
    result from the Incoming Mailbox registers.  One of these commands is
    the "Read the Current Status" command.  The number of this command is
    0x07 (see the User's Manual for the PCI-1760 at
    <https://advdownload.advantech.com/productfile/Downloadfile2/1-11P6653/PCI-1760.pdf>.
    The `PCI1760_CMD_GET_STATUS` macro defined in the driver should expand
    to this command number 0x07, but unfortunately it currently expands to
    0x03.  (Command number 0x03 is not defined in the User's Manual.)
    Correct the definition of the `PCI1760_CMD_GET_STATUS` macro to fix it.
    
    This is used by all the PWM subdevice related instructions handled by
    `pci1760_pwm_insn_config()` which are probably all broken.  The effect
    of sending the undefined command number 0x03 is not known.
    
    Fixes: 14b93bb6bbf0 ("staging: comedi: adv_pci_dio: separate out PCI-1760 support")
    Cc: <stable@vger.kernel.org> # v4.5+
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20230103143754.17564-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dma-buf: fix dma_buf_export init order v2 [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Tue Dec 6 14:07:49 2022 +0100

    dma-buf: fix dma_buf_export init order v2
    
    [ Upstream commit f728a5ea27c92133893590e731ce10f6561ced87 ]
    
    The init order and resulting error handling in dma_buf_export
    was pretty messy.
    
    Subordinate objects like the file and the sysfs kernel objects
    were initializing and wiring itself up with the object in the
    wrong order resulting not only in complicating and partially
    incorrect error handling, but also in publishing only halve
    initialized DMA-buf objects.
    
    Clean this up thoughtfully by allocating the file independent
    of the DMA-buf object. Then allocate and initialize the DMA-buf
    object itself, before publishing it through sysfs. If everything
    works as expected the file is then connected with the DMA-buf
    object and publish it through debugfs.
    
    Also adds the missing dma_resv_fini() into the error handling.
    
    v2: add some missing changes to dma_bug_getfile() and a missing NULL
        check in dma_buf_file_release()
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Reviewed-by: T.J. Mercier <tjmercier@google.com>
    Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221209071535.933698-1-christian.koenig@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
dmaengine: idxd: Do not call DMX TX callbacks during workqueue disable [+ + +]
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Wed Dec 7 14:52:22 2022 -0800

    dmaengine: idxd: Do not call DMX TX callbacks during workqueue disable
    
    commit 6744a030d81e456883bfbb627ac1f30465c1a989 upstream.
    
    On driver unload any pending descriptors are flushed and pending
    DMA descriptors are explicitly completed:
    idxd_dmaengine_drv_remove() ->
            drv_disable_wq() ->
                    idxd_wq_free_irq() ->
                            idxd_flush_pending_descs() ->
                                    idxd_dma_complete_txd()
    
    With this done during driver unload any remaining descriptor is
    likely stuck and can be dropped. Even so, the descriptor may still
    have a callback set that could no longer be accessible. An
    example of such a problem is when the dmatest fails and the dmatest
    module is unloaded. The failure of dmatest leaves descriptors with
    dma_async_tx_descriptor::callback pointing to code that no longer
    exist. This causes a page fault as below at the time the IDXD driver
    is unloaded when it attempts to run the callback:
     BUG: unable to handle page fault for address: ffffffffc0665190
     #PF: supervisor instruction fetch in kernel mode
     #PF: error_code(0x0010) - not-present page
    
    Fix this by clearing the callback pointers on the transmit
    descriptors only when workqueue is disabled.
    
    Fixes: 403a2e236538 ("dmaengine: idxd: change MSIX allocation based on per wq activation")
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/37d06b772aa7f8863ca50f90930ea2fd80b38fc3.1670452419.git.reinette.chatre@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: idxd: Let probe fail when workqueue cannot be enabled [+ + +]
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Wed Dec 7 14:52:20 2022 -0800

    dmaengine: idxd: Let probe fail when workqueue cannot be enabled
    
    commit b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f upstream.
    
    The workqueue is enabled when the appropriate driver is loaded and
    disabled when the driver is removed. When the driver is removed it
    assumes that the workqueue was enabled successfully and proceeds to
    free allocations made during workqueue enabling.
    
    Failure during workqueue enabling does not prevent the driver from
    being loaded. This is because the error path within drv_enable_wq()
    returns success unless a second failure is encountered
    during the error path. By returning success it is possible to load
    the driver even if the workqueue cannot be enabled and
    allocations that do not exist are attempted to be freed during
    driver remove.
    
    Some examples of problematic flows:
    (a)
    
     idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq():
     In above flow, if idxd_wq_request_irq() fails then
     idxd_wq_unmap_portal() is called on error exit path, but
     drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The
     driver is thus loaded successfully.
    
     idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal()
     Above flow on driver unload triggers the WARN in devm_iounmap() because
     the device resource has already been removed during error path of
     drv_enable_wq().
    
    (b)
    
     idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq():
     In above flow, if idxd_wq_request_irq() fails then
     idxd_wq_init_percpu_ref() is never called to initialize the percpu
     counter, yet the driver loads successfully because drv_enable_wq()
     returns 0.
    
     idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill():
     Above flow on driver unload triggers a BUG when attempting to drop the
     initial ref of the uninitialized percpu ref:
     BUG: kernel NULL pointer dereference, address: 0000000000000010
    
    Fix the drv_enable_wq() error path by returning the original error that
    indicates failure of workqueue enabling. This ensures that the probe
    fails when an error is encountered and the driver remove paths are only
    attempted when the workqueue was enabled successfully.
    
    Fixes: 1f2bb40337f0 ("dmaengine: idxd: move wq_enable() to device.c")
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/e8d8116e5efa0fd14fadc5adae6ffd319f0e5ff1.1670452419.git.reinette.chatre@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: idxd: Prevent use after free on completion memory [+ + +]
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Wed Dec 7 14:52:21 2022 -0800

    dmaengine: idxd: Prevent use after free on completion memory
    
    commit 1beeec45f9ac31eba52478379f70a5fa9c2ad005 upstream.
    
    On driver unload any pending descriptors are flushed at the
    time the interrupt is freed:
    idxd_dmaengine_drv_remove() ->
            drv_disable_wq() ->
                    idxd_wq_free_irq() ->
                            idxd_flush_pending_descs().
    
    If there are any descriptors present that need to be flushed this
    flow triggers a "not present" page fault as below:
    
     BUG: unable to handle page fault for address: ff391c97c70c9040
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
    
    The address that triggers the fault is the address of the
    descriptor that was freed moments earlier via:
    drv_disable_wq()->idxd_wq_free_resources()
    
    Fix the use after free by freeing the descriptors after any possible
    usage. This is done after idxd_wq_reset() to ensure that the memory
    remains accessible during possible completion writes by the device.
    
    Fixes: 63c14ae6c161 ("dmaengine: idxd: refactor wq driver enable/disable operations")
    Suggested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/6c4657d9cff0a0a00501a7b928297ac966e9ec9d.1670452419.git.reinette.chatre@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: lgm: Move DT parsing after initialization [+ + +]
Author: Peter Harliman Liem <pliem@maxlinear.com>
Date:   Thu Jan 5 11:05:51 2023 +0800

    dmaengine: lgm: Move DT parsing after initialization
    
    commit 96b3bb18f6cbe259ef4e0bed3135911b7e8d2af5 upstream.
    
    ldma_cfg_init() will parse DT to retrieve certain configs.
    However, that is called before ldma_dma_init_vXX(), which
    will make some initialization to channel configs. It will
    thus incorrectly overwrite certain configs that are declared
    in DT.
    
    To fix that, we move DT parsing after initialization.
    Function name is renamed to better represent what it does.
    
    Fixes: 32d31c79a1a4 ("dmaengine: Add Intel LGM SoC DMA support.")
    Signed-off-by: Peter Harliman Liem <pliem@maxlinear.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/afef6fc1ed20098b684e0d53737d69faf63c125f.1672887183.git.pliem@maxlinear.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: tegra210-adma: fix global intr clear [+ + +]
Author: Mohan Kumar <mkumard@nvidia.com>
Date:   Mon Jan 2 12:18:44 2023 +0530

    dmaengine: tegra210-adma: fix global intr clear
    
    commit 9c7e355ccbb33d239360c876dbe49ad5ade65b47 upstream.
    
    The current global interrupt clear programming register offset
    was not correct. Fix the programming with right offset
    
    Fixes: ded1f3db4cd6 ("dmaengine: tegra210-adma: prepare for supporting newer Tegra chips")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
    Link: https://lore.kernel.org/r/20230102064844.31306-1-mkumard@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
docs: Fix path paste-o for /sys/kernel/warn_count [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Dec 14 14:35:47 2022 -0800

    docs: Fix path paste-o for /sys/kernel/warn_count
    
    commit 00dd027f721e0458418f7750d8a5a664ed3e5994 upstream.
    
    Running "make htmldocs" shows that "/sys/kernel/oops_count" was
    duplicated. This should have been "warn_count":
    
      Warning: /sys/kernel/oops_count is defined 2 times:
      ./Documentation/ABI/testing/sysfs-kernel-warn_count:0
      ./Documentation/ABI/testing/sysfs-kernel-oops_count:0
    
    Fix the typo.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/linux-doc/202212110529.A3Qav8aR-lkp@intel.com
    Fixes: 8b05aa263361 ("panic: Expose "warn_count" to sysfs")
    Cc: linux-hardening@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Calculate output_color_space after pixel encoding adjustment [+ + +]
Author: Joshua Ashton <joshua@froggi.es>
Date:   Tue Jan 10 20:12:21 2023 +0000

    drm/amd/display: Calculate output_color_space after pixel encoding adjustment
    
    commit 79601b894849cb6f6d6122e6590f1887ac4a66b3 upstream.
    
    Code in get_output_color_space depends on knowing the pixel encoding to
    determine whether to pick between eg. COLOR_SPACE_SRGB or
    COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.
    
    v2: Fixed patch being accidentally based on a personal feature branch, oops!
    
    Fixes: ea117312ea9f ("drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded")
    Reviewed-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Joshua Ashton <joshua@froggi.es>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: disable S/G display on DCN 3.1.4 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Jan 18 09:21:22 2023 -0500

    drm/amd/display: disable S/G display on DCN 3.1.4
    
    commit a52287d66dfa1cca32e6273623b63ba39d87f126 upstream.
    
    Causes flickering or white screens in some configurations.
    Disable it for now until we can fix the issue.
    
    Cc: roman.li@amd.com
    Cc: yifan1.zhang@amd.com
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Roman Li <Roman.Li@amd.com>
    Reviewed-by: Yifan Zhang <yifan1.zhang@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>

drm/amd/display: disable S/G display on DCN 3.1.5 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Jan 18 09:19:21 2023 -0500

    drm/amd/display: disable S/G display on DCN 3.1.5
    
    commit e78cc6a4c7486f50c2786d91dd7d9649a87d1dcb upstream.
    
    Causes flickering or white screens in some configurations.
    Disable it for now until we can fix the issue.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2354
    Cc: roman.li@amd.com
    Cc: yifan1.zhang@amd.com
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Yifan Zhang <yifan1.zhang@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>

drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix [+ + +]
Author: Joshua Ashton <joshua@froggi.es>
Date:   Tue Jan 10 22:50:42 2023 +0000

    drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix
    
    commit 973a9c810c785ac270a6d50d8cf862b0c1643a10 upstream.
    
    The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
    missing the values for the fourth column of the matrix.
    
    The fourth column of the matrix is essentially just a value that is
    added given that the color is 3 components in size.
    These values are needed to bias the chroma from the [-1, 1] -> [0, 1]
    range.
    
    This fixes color being very green when using Gamescope HDR on HDMI
    output which prefers YCC 4:4:4.
    
    Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")
    Reviewed-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Joshua Ashton <joshua@froggi.es>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Fix set scaling doesn's work [+ + +]
Author: hongao <hongao@uniontech.com>
Date:   Tue Nov 22 19:20:34 2022 +0800

    drm/amd/display: Fix set scaling doesn's work
    
    commit 040625ab82ce6dca7772cb3867fe5c9eb279a344 upstream.
    
    [Why]
    Setting scaling does not correctly update CRTC state. As a result
    dc stream state's src (composition area) && dest (addressable area)
    was not calculated as expected. This causes set scaling doesn's work.
    
    [How]
    Correctly update CRTC state when setting scaling property.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Tested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: hongao <hongao@uniontech.com>
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/discovery: add PSP IP v13.0.11 support [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Nov 21 16:19:44 2022 +0800

    drm/amdgpu/discovery: add PSP IP v13.0.11 support
    
    commit 7c1389f1b1228b96e621815e63eaa2e89b9f7511 upstream.
    
    Add PSP IP v13.0.11 ip discovery support.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/discovery: enable gfx v11 for GC 11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 11:11:09 2022 +0800

    drm/amdgpu/discovery: enable gfx v11 for GC 11.0.4
    
    commit b952d6b3d3ff3c1570fab77f2137d5e5280a0e57 upstream.
    
    Enable gfx v11 for GC 11.0.4.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/discovery: enable gmc v11 for GC 11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 11:09:50 2022 +0800

    drm/amdgpu/discovery: enable gmc v11 for GC 11.0.4
    
    commit d5fd8c89ed206b2df3933bc4ea129401b2b60869 upstream.
    
    Enable gmc (graphic memory controller) v11 for GC 11.0.4.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/discovery: enable mes support for GC v11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 11:11:57 2022 +0800

    drm/amdgpu/discovery: enable mes support for GC v11.0.4
    
    commit 6a6af77570add4e58721386be429dbd02cd4b9dd upstream.
    
    this patch is to enable mes for GC 11.0.4.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/discovery: enable nbio support for NBIO v7.7.1 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Tue Oct 25 16:59:44 2022 +0800

    drm/amdgpu/discovery: enable nbio support for NBIO v7.7.1
    
    commit 7308ceb44663f40bf9e7373c3b1aa4f7f433d625 upstream.
    
    this patch is to enable nbio support for NBIO v7.7.1.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/discovery: enable soc21 common for GC 11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 11:08:49 2022 +0800

    drm/amdgpu/discovery: enable soc21 common for GC 11.0.4
    
    commit 69dc98bbd44160930b6b3ca9ca558f89435d2702 upstream.
    
    Enable soc21 common for GC 11.0.4.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/discovery: set the APU flag for GC 11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 11:16:29 2022 +0800

    drm/amdgpu/discovery: set the APU flag for GC 11.0.4
    
    commit dd2d9c7fd7716838d477e257f43facd68c53d3a9 upstream.
    
    Set the APU flag appropriately for GC 11.0.4.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/pm: add GFXOFF control IP version check for SMU IP v13.0.11 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 13:17:40 2022 +0800

    drm/amdgpu/pm: add GFXOFF control IP version check for SMU IP v13.0.11
    
    commit 9f83e61201bb21957e4993736532edad7a11c7fa upstream.
    
    Enable the SMU IP v13.0.11 GFXOFF control
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/pm: enable swsmu for SMU IP v13.0.11 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 13:08:30 2022 +0800

    drm/amdgpu/pm: enable swsmu for SMU IP v13.0.11
    
    commit 16412a94364d1dcebded9217ecb693c9659eaabc upstream.
    
    Add the entry to set the ppt functions for SMU IP v13.0.11.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/pm: use the specific mailbox registers only for SMU IP v13.0.4 [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Oct 24 11:05:59 2022 +0800

    drm/amdgpu/pm: use the specific mailbox registers only for SMU IP v13.0.4
    
    commit 069a5af97ce3a1448a3566ce8b63b60e51e19958 upstream.
    
    The SMU IP v13.0.4 ppt interface is shared by IP v13.0.11, they use
    the different mailbox register offset. So use the specific mailbox
    registers offset for v13.0.4.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/soc21: add mode2 asic reset for SMU IP v13.0.11 [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Oct 24 10:32:05 2022 +0800

    drm/amdgpu/soc21: add mode2 asic reset for SMU IP v13.0.11
    
    commit 18ad18853cf2d8b94cef0112ba94f7a7535a9e89 upstream.
    
    Set the default reset method to mode2 for SMU IP v13.0.11
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: add gfx support for GC 11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 12:49:06 2022 +0800

    drm/amdgpu: add gfx support for GC 11.0.4
    
    commit 1763cb65e870e783e26d2dc9def4edbeadcb1050 upstream.
    
    this patch to add GC 11.0.4 gfx support to gfx11 implementation.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: add gmc v11 support for GC 11.0.4 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 12:56:01 2022 +0800

    drm/amdgpu: add gmc v11 support for GC 11.0.4
    
    commit d0ca8248999e4c5b02ac64f40536ff46dc14dda7 upstream.
    
    Add gmc v11 support for GC 11.0.4.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: add smu 13 support for smu 13.0.11 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 13:16:25 2022 +0800

    drm/amdgpu: add smu 13 support for smu 13.0.11
    
    commit 51e7a2168769c2f46edd93a18d4cba4a6d4adb13 upstream.
    
    this patch to add smu 13 support for smu 13.0.11.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: add tmz support for GC 11.0.1 [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Sun Oct 9 14:35:20 2022 +0800

    drm/amdgpu: add tmz support for GC 11.0.1
    
    commit 97074216917b4188f0af3e52cc5b3f2b277bbbca upstream.
    
    this patch to add tmz support for GC 11.0.1.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: add tmz support for GC IP v11.0.4 [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Dec 5 14:33:25 2022 +0800

    drm/amdgpu: add tmz support for GC IP v11.0.4
    
    commit 2aecbe492a3c0bf4c21f78c099a6f6c205fab0c7 upstream.
    
    Add tmz support for GC 11.0.4.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: allow multipipe policy on ASICs with one MEC [+ + +]
Author: Lang Yu <Lang.Yu@amd.com>
Date:   Wed Jan 11 09:32:15 2023 +0800

    drm/amdgpu: allow multipipe policy on ASICs with one MEC
    
    commit dc88063b87775971be564d79dc1b05f7b8b5c135 upstream.
    
    Always enable multipipe policy on ASICs with GC VERSION > 9.0.0
    instead of MEC number > 1.
    
    This will allow multipipe policy on ASICs with one MEC,
    e.g., gfx11 APUs.
    
    Signed-off-by: Lang Yu <Lang.Yu@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Reviewed-by: Yifan Zhang <yifan1.zhang@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>

drm/amdgpu: correct MEC number for gfx11 APUs [+ + +]
Author: Lang Yu <Lang.Yu@amd.com>
Date:   Wed Jan 11 09:52:11 2023 +0800

    drm/amdgpu: correct MEC number for gfx11 APUs
    
    commit 0ddadc3a2208aedb1b27dbb76d0b4e722b5b527a upstream.
    
    There is only one MEC on these APUs.
    
    Signed-off-by: Lang Yu <Lang.Yu@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Reviewed-by: Yifan Zhang <yifan1.zhang@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>

drm/amdgpu: Correct the power calcultion for Renior/Cezanne. [+ + +]
Author: jie1zhan <jesse.zhang@amd.com>
Date:   Fri Jan 13 10:39:13 2023 +0800

    drm/amdgpu: Correct the power calcultion for Renior/Cezanne.
    
    commit c7bae4aaa5609c1fa9761c35dbcc5fcc92915222 upstream.
    
    From smu firmware,the value of power is transferred  in units of watts.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2321
    Fixes: 137aac26a2ed ("drm/amdgpu/smu12: fix power reporting on renoir")
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: enable GFX Clock Gating control for GC IP v11.0.4 [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Dec 5 14:18:23 2022 +0800

    drm/amdgpu: enable GFX Clock Gating control for GC IP v11.0.4
    
    commit f9caa237372b106b5e70ba1a4bfd4222eb79ec71 upstream.
    
    Enable GFX IP v11.0.4 CG gate/ungate control.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: enable GFX IP v11.0.4 CG support [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Dec 5 11:24:37 2022 +0800

    drm/amdgpu: enable GFX IP v11.0.4 CG support
    
    commit f2b91e5a7cc0368709964994ca253781b51a486a upstream.
    
    Add CG support for GFX/MC/HDP/ATHUB/IH/BIF.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: enable GFX Power Gating for GC IP v11.0.4 [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Dec 5 13:55:36 2022 +0800

    drm/amdgpu: enable GFX Power Gating for GC IP v11.0.4
    
    commit a89e2965da6e644729a8ee9c318b7fa9a2990353 upstream.
    
    Enable GFX Power Gating control for GC IP v11.0.4.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: enable PSP IP v13.0.11 support [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Mon Nov 21 10:24:14 2022 +0800

    drm/amdgpu: enable PSP IP v13.0.11 support
    
    commit 2c83e3fd928b9cb1e35340e58d4b1bd2eea23ed6 upstream.
    
    Enable PSP FW loading for PSP IP v13.0.11
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix amdgpu_job_free_resources v2 [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Thu Jan 12 14:46:00 2023 +0100

    drm/amdgpu: fix amdgpu_job_free_resources v2
    
    commit 74ea8e78ab349514c9f4df0be1189d91267d750d upstream.
    
    It can be that neither fence were initialized when we run out of UVD
    streams for example.
    
    v2: fix typo breaking compile
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2324
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-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>

drm/amdgpu: set GC 11.0.4 family [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Wed Oct 12 11:15:24 2022 +0800

    drm/amdgpu: set GC 11.0.4 family
    
    commit 94ab70685844227b5c9cb9027a5c4acd3b0e4564 upstream.
    
    this patch is to set GC 11.0.4 family.
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: Aaron Liu <aaron.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/display: Check source height is > 0 [+ + +]
Author: Drew Davenport <ddavenport@chromium.org>
Date:   Mon Dec 26 22:53:24 2022 -0700

    drm/i915/display: Check source height is > 0
    
    commit 8565c502e7c156d190d8e6d36e443f51b257f165 upstream.
    
    The error message suggests that the height of the src rect must be at
    least 1. Reject source with height of 0.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Drew Davenport <ddavenport@chromium.org>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221226225246.1.I15dff7bb5a0e485c862eae61a69096caf12ef29f@changeid
    (cherry picked from commit 0fe76b198d482b41771a8d17b45fb726d13083cf)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915: Allow switching away via vga-switcheroo if uninitialized [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Mon Jan 16 12:54:23 2023 +0100

    drm/i915: Allow switching away via vga-switcheroo if uninitialized
    
    commit a273e95721e96885971a05f1b34cb6d093904d9d upstream.
    
    Always allow switching away via vga-switcheroo if the display is
    uninitalized. Instead prevent switching to i915 if the device has
    not been initialized.
    
    This issue was introduced by commit 5df7bd130818 ("drm/i915: skip
    display initialization when there is no display") protected, which
    protects code paths from being executed on uninitialized devices.
    In the case of vga-switcheroo, we want to allow a switch away from
    i915's device. So run vga_switcheroo_process_delayed_switch() and
    test in the switcheroo callbacks if the i915 device is available.
    
    Fixes: 5df7bd130818 ("drm/i915: skip display initialization when there is no display")
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
    Cc: Lucas De Marchi <lucas.demarchi@intel.com>
    Cc: José Roberto de Souza <jose.souza@intel.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
    Cc: Manasi Navare <manasi.d.navare@intel.com>
    Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
    Cc: Imre Deak <imre.deak@intel.com>
    Cc: "Jouni Högander" <jouni.hogander@intel.com>
    Cc: Uma Shankar <uma.shankar@intel.com>
    Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: Matt Roper <matthew.d.roper@intel.com>
    Cc: Ramalingam C <ramalingam.c@intel.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Andi Shyti <andi.shyti@linux.intel.com>
    Cc: Andrzej Hajda <andrzej.hajda@intel.com>
    Cc: "José Roberto de Souza" <jose.souza@intel.com>
    Cc: Julia Lawall <Julia.Lawall@inria.fr>
    Cc: intel-gfx@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v5.14+
    Link: https://patchwork.freedesktop.org/patch/msgid/20230116115425.13484-2-tzimmermann@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: re-disable RC6p on Sandy Bridge [+ + +]
Author: Sasa Dragic <sasa.dragic@gmail.com>
Date:   Mon Dec 19 18:29:27 2022 +0100

    drm/i915: re-disable RC6p on Sandy Bridge
    
    commit 67b0b4ed259e425b7eed09da75b42c80682ca003 upstream.
    
    RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
    and GPU hangs.
    
    Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
    RC6p on Sandy Bridge").
    
    Signed-off-by: Sasa Dragic <sasa.dragic@gmail.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221219172927.9603-2-sasa.dragic@gmail.com
    Fixes: fb6db0f5bf1d ("drm/i915: Remove unsafe i915.enable_rc6")
    Fixes: 13c5a577b342 ("drm/i915/gt: Select the deepest available parking mode for rc6")
    Cc: stable@vger.kernel.org
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    (cherry picked from commit 0c8a6e9ea232c221976a0670256bd861408d9917)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Remove unused variable [+ + +]
Author: Nirmoy Das <nirmoy.das@intel.com>
Date:   Wed Jan 18 18:06:24 2023 +0100

    drm/i915: Remove unused variable
    
    commit 2293a73ad4f3b6c37c06713ff1b67659d92ef43d upstream.
    
    Removed unused i915 var.
    
    Fixes: a273e95721e9 ("drm/i915: Allow switching away via vga-switcheroo if uninitialized")
    Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230118170624.9326-1-nirmoy.das@intel.com
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dt-bindings: phy: g12a-usb2-phy: fix compatible string documentation [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Jan 16 21:17:39 2023 +0100

    dt-bindings: phy: g12a-usb2-phy: fix compatible string documentation
    
    commit c63835bf1c750c9b3aec1d5c23d811d6375fc23d upstream.
    
    The compatible strings in the driver don't have the meson prefix.
    Fix this in the documentation and rename the file accordingly.
    
    Fixes: da86d286cce8 ("dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/8d960029-e94d-224b-911f-03e5deb47ebc@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dt-bindings: phy: g12a-usb3-pcie-phy: fix compatible string documentation [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Jan 16 21:19:03 2023 +0100

    dt-bindings: phy: g12a-usb3-pcie-phy: fix compatible string documentation
    
    commit e181119046a0ec16126b682163040e8e33f310c1 upstream.
    
    The compatible string in the driver doesn't have the meson prefix.
    Fix this in the documentation and rename the file accordingly.
    
    Fixes: 87a55485f2fc ("dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/0a82be92-ce85-da34-9d6f-4b33034473e5@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
efi: rt-wrapper: Add missing include [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Jan 9 12:41:46 2023 +0100

    efi: rt-wrapper: Add missing include
    
    commit 18bba1843fc7f264f58c9345d00827d082f9c558 upstream.
    
    Add the missing #include of asm/assembler.h, which is where the ldr_l
    macro is defined.
    
    Fixes: ff7a167961d1b97e ("arm64: efi: Execute runtime services from a dedicated stack")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Lee Jones <lee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
exit: Allow oops_limit to be disabled [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Dec 2 12:59:11 2022 -0800

    exit: Allow oops_limit to be disabled
    
    commit de92f65719cd672f4b48397540b9f9eff67eca40 upstream.
    
    In preparation for keeping oops_limit logic in sync with warn_limit,
    have oops_limit == 0 disable checking the Oops counter.
    
    Cc: Jann Horn <jannh@google.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: Eric Biggers <ebiggers@google.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: linux-doc@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

exit: Expose "oops_count" to sysfs [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 17 15:43:23 2022 -0800

    exit: Expose "oops_count" to sysfs
    
    commit 9db89b41117024f80b38b15954017fb293133364 upstream.
    
    Since Oops count is now tracked and is a fairly interesting signal, add
    the entry /sys/kernel/oops_count to expose it to userspace.
    
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-3-keescook@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

exit: Put an upper limit on how often we can oops [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Thu Nov 17 15:43:22 2022 -0800

    exit: Put an upper limit on how often we can oops
    
    commit d4ccd54d28d3c8598e2354acc13e28c060961dbb upstream.
    
    Many Linux systems are configured to not panic on oops; but allowing an
    attacker to oops the system **really** often can make even bugs that look
    completely unexploitable exploitable (like NULL dereferences and such) if
    each crash elevates a refcount by one or a lock is taken in read mode, and
    this causes a counter to eventually overflow.
    
    The most interesting counters for this are 32 bits wide (like open-coded
    refcounts that don't use refcount_t). (The ldsem reader count on 32-bit
    platforms is just 16 bits, but probably nobody cares about 32-bit platforms
    that much nowadays.)
    
    So let's panic the system if the kernel is constantly oopsing.
    
    The speed of oopsing 2^32 times probably depends on several factors, like
    how long the stack trace is and which unwinder you're using; an empirically
    important one is whether your console is showing a graphical environment or
    a text console that oopses will be printed to.
    In a quick single-threaded benchmark, it looks like oopsing in a vfork()
    child with a very short stack trace only takes ~510 microseconds per run
    when a graphical console is active; but switching to a text console that
    oopses are printed to slows it down around 87x, to ~45 milliseconds per
    run.
    (Adding more threads makes this faster, but the actual oops printing
    happens under &die_lock on x86, so you can maybe speed this up by a factor
    of around 2 and then any further improvement gets eaten up by lock
    contention.)
    
    It looks like it would take around 8-12 days to overflow a 32-bit counter
    with repeated oopsing on a multi-core X86 system running a graphical
    environment; both me (in an X86 VM) and Seth (with a distro kernel on
    normal hardware in a standard configuration) got numbers in that ballpark.
    
    12 days aren't *that* short on a desktop system, and you'd likely need much
    longer on a typical server system (assuming that people don't run graphical
    desktop environments on their servers), and this is a *very* noisy and
    violent approach to exploiting the kernel; and it also seems to take orders
    of magnitude longer on some machines, probably because stuff like EFI
    pstore will slow it down a ton if that's active.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Link: https://lore.kernel.org/r/20221107201317.324457-1-jannh@google.com
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-2-keescook@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

exit: Use READ_ONCE() for all oops/warn limit reads [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Dec 16 12:26:57 2022 -0800

    exit: Use READ_ONCE() for all oops/warn limit reads
    
    commit 7535b832c6399b5ebfc5b53af5c51dd915ee2538 upstream.
    
    Use a temporary variable to take full advantage of READ_ONCE() behavior.
    Without this, the report (and even the test) might be out of sync with
    the initial test.
    
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/lkml/Y5x7GXeluFmZ8E0E@hirez.programming.kicks-ass.net
    Fixes: 9fc9e278a5c0 ("panic: Introduce warn_limit")
    Fixes: d4ccd54d28d3 ("exit: Put an upper limit on how often we can oops")
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Marco Elver <elver@google.com>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
f2fs: let's avoid panic if extent_tree is not created [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Wed Dec 21 16:14:10 2022 -0800

    f2fs: let's avoid panic if extent_tree is not created
    
    [ Upstream commit df9d44b645b83fffccfb4e28c1f93376585fdec8 ]
    
    This patch avoids the below panic.
    
    pc : __lookup_extent_tree+0xd8/0x760
    lr : f2fs_do_write_data_page+0x104/0x87c
    sp : ffffffc010cbb3c0
    x29: ffffffc010cbb3e0 x28: 0000000000000000
    x27: ffffff8803e7f020 x26: ffffff8803e7ed40
    x25: ffffff8803e7f020 x24: ffffffc010cbb460
    x23: ffffffc010cbb480 x22: 0000000000000000
    x21: 0000000000000000 x20: ffffffff22e90900
    x19: 0000000000000000 x18: ffffffc010c5d080
    x17: 0000000000000000 x16: 0000000000000020
    x15: ffffffdb1acdbb88 x14: ffffff888759e2b0
    x13: 0000000000000000 x12: ffffff802da49000
    x11: 000000000a001200 x10: ffffff8803e7ed40
    x9 : ffffff8023195800 x8 : ffffff802da49078
    x7 : 0000000000000001 x6 : 0000000000000000
    x5 : 0000000000000006 x4 : ffffffc010cbba28
    x3 : 0000000000000000 x2 : ffffffc010cbb480
    x1 : 0000000000000000 x0 : ffffff8803e7ed40
    Call trace:
     __lookup_extent_tree+0xd8/0x760
     f2fs_do_write_data_page+0x104/0x87c
     f2fs_write_single_data_page+0x420/0xb60
     f2fs_write_cache_pages+0x418/0xb1c
     __f2fs_write_data_pages+0x428/0x58c
     f2fs_write_data_pages+0x30/0x40
     do_writepages+0x88/0x190
     __writeback_single_inode+0x48/0x448
     writeback_sb_inodes+0x468/0x9e8
     __writeback_inodes_wb+0xb8/0x2a4
     wb_writeback+0x33c/0x740
     wb_do_writeback+0x2b4/0x400
     wb_workfn+0xe4/0x34c
     process_one_work+0x24c/0x5bc
     worker_thread+0x3e8/0xa50
     kthread+0x150/0x1b4
    
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: omapfb: avoid stack overflow warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 15 18:02:28 2022 +0100

    fbdev: omapfb: avoid stack overflow warning
    
    [ Upstream commit 634cf6ead93988b0da9ac054521ab63a3ba189db ]
    
    The dsi_irq_stats structure is a little too big to fit on the
    stack of a 32-bit task, depending on the specific gcc options:
    
    fbdev/omap2/omapfb/dss/dsi.c: In function 'dsi_dump_dsidev_irqs':
    fbdev/omap2/omapfb/dss/dsi.c:1621:1: error: the frame size of 1064 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    
    Since this is only a debugfs file, performance is not critical,
    so just dynamically allocate it, and print an error message
    in there in place of a failure code when the allocation fails.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/ntfs3: Fix attr_punch_hole() null pointer derenference [+ + +]
Author: Alon Zahavi <zahavi.alon@gmail.com>
Date:   Mon Aug 15 14:07:12 2022 +0300

    fs/ntfs3: Fix attr_punch_hole() null pointer derenference
    
    commit 6d5c9e79b726cc473d40e9cb60976dbe8e669624 upstream.
    
    The bug occours due to a misuse of `attr` variable instead of `attr_b`.
    `attr` is being initialized as NULL, then being derenfernced
    as `attr->res.data_size`.
    
    This bug causes a crash of the ntfs3 driver itself,
    If compiled directly to the kernel, it crashes the whole system.
    
    Signed-off-by: Alon Zahavi <zahavi.alon@gmail.com>
    Co-developed-by: Tal Lossos <tallossos@gmail.com>
    Signed-off-by: Tal Lossos <tallossos@gmail.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gsmi: fix null-deref in gsmi_get_variable [+ + +]
Author: Khazhismel Kumykov <khazhy@chromium.org>
Date:   Tue Jan 17 17:02:12 2023 -0800

    gsmi: fix null-deref in gsmi_get_variable
    
    commit a769b05eeed7accc4019a1ed9799dd72067f1ce8 upstream.
    
    We can get EFI variables without fetching the attribute, so we must
    allow for that in gsmi.
    
    commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
    access layer") added a new get_variable call with attr=NULL, which
    triggers panic in gsmi.
    
    Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
    Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hugetlb: unshare some PMDs when splitting VMAs [+ + +]
Author: James Houghton <jthoughton@google.com>
Date:   Wed Jan 4 23:19:10 2023 +0000

    hugetlb: unshare some PMDs when splitting VMAs
    
    commit b30c14cd61025eeea2f2e8569606cd167ba9ad2d upstream.
    
    PMD sharing can only be done in PUD_SIZE-aligned pieces of VMAs; however,
    it is possible that HugeTLB VMAs are split without unsharing the PMDs
    first.
    
    Without this fix, it is possible to hit the uffd-wp-related WARN_ON_ONCE
    in hugetlb_change_protection [1].  The key there is that
    hugetlb_unshare_all_pmds will not attempt to unshare PMDs in
    non-PUD_SIZE-aligned sections of the VMA.
    
    It might seem ideal to unshare in hugetlb_vm_op_open, but we need to
    unshare in both the new and old VMAs, so unsharing in hugetlb_vm_op_split
    seems natural.
    
    [1]: https://lore.kernel.org/linux-mm/CADrL8HVeOkj0QH5VZZbRzybNE8CG-tEGFshnA+bG9nMgcWtBSg@mail.gmail.com/
    
    Link: https://lkml.kernel.org/r/20230104231910.1464197-1-jthoughton@google.com
    Fixes: 6dfeaff93be1 ("hugetlb/userfaultfd: unshare all pmds for hugetlbfs when register wp")
    Signed-off-by: James Houghton <jthoughton@google.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Peter Xu <peterx@redhat.com>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/poll: don't reissue in case of poll race on multishot request [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Jan 20 15:08:21 2023 -0700

    io_uring/poll: don't reissue in case of poll race on multishot request
    
    commit 8caa03f10bf92cb8657408a6ece6a8a73f96ce13 upstream.
    
    A previous commit fixed a poll race that can occur, but it's only
    applicable for multishot requests. For a multishot request, we can safely
    ignore a spurious wakeup, as we never leave the waitqueue to begin with.
    
    A blunt reissue of a multishot armed request can cause us to leak a
    buffer, if they are ring provided. While this seems like a bug in itself,
    it's not really defined behavior to reissue a multishot request directly.
    It's less efficient to do so as well, and not required to rearm anything
    like it is for singleshot poll requests.
    
    Cc: stable@vger.kernel.org
    Fixes: 6e5aedb9324a ("io_uring/poll: attempt request issue after racy poll wakeup")
    Reported-and-tested-by: Olivier Langlois <olivier@trillion01.com>
    Link: https://github.com/axboe/liburing/issues/778
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.1.8 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jan 24 07:24:44 2023 +0100

    Linux 6.1.8
    
    Link: https://lore.kernel.org/r/20230122150246.321043584@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Link: https://lore.kernel.org/r/20230123094931.568794202@linuxfoundation.org
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Add HWCAP_LOONGARCH_CPUCFG to elf_hwcap [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Tue Jan 17 11:42:16 2023 +0800

    LoongArch: Add HWCAP_LOONGARCH_CPUCFG to elf_hwcap
    
    commit d52fec86a465355b379e839fa372ead0334d62e6 upstream.
    
    HWCAP_LOONGARCH_CPUCFG is missing in elf_hwcap, so add it for glibc's
    later use.
    
    Cc: stable@vger.kernel.org
    Reported-by: Yinyu Cai <caiyinyu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mei: bus: fix unlink on bus in error path [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Tue Dec 13 00:02:46 2022 +0200

    mei: bus: fix unlink on bus in error path
    
    commit a43866856125c3c432e2fbb6cc63cee1539ec4a7 upstream.
    
    Unconditional call to mei_cl_unlink in mei_cl_bus_dev_release leads
    to call of the mei_cl_unlink without corresponding mei_cl_link.
    This leads to miscalculation of open_handle_count (decrease without
    increase).
    
    Call unlink in mei_cldev_enable fail path and remove blanket unlink
    from mei_cl_bus_dev_release.
    
    Fixes: 34f1166afd67 ("mei: bus: need to unlink client before freeing")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Reviewed-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20221212220247.286019-1-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: me: add meteor lake point M DID [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Tue Dec 13 00:02:47 2022 +0200

    mei: me: add meteor lake point M DID
    
    commit 0c4d68261717f89fa8c4f98a6967c3832fcb3ad0 upstream.
    
    Add Meteor Lake Point M device id.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20221212220247.286019-2-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memblock tests: Fix compilation error. [+ + +]
Author: Aaron Thompson <dev@aaront.org>
Date:   Wed Jan 4 10:07:37 2023 +0000

    memblock tests: Fix compilation error.
    
    [ Upstream commit 340726747336716350eb5a928b860a29db955f05 ]
    
    Commit cf4694be2b2cf ("tools: Add atomic_test_and_set_bit()") changed
    tools/arch/x86/include/asm/atomic.h to include <asm/asm.h>, which causes
    'make -C tools/testing/memblock' to fail with:
    
    In file included from ../../include/asm/atomic.h:6,
                     from ../../include/linux/atomic.h:5,
                     from ./linux/mmzone.h:5,
                     from ../../include/linux/mm.h:5,
                     from ../../include/linux/pfn.h:5,
                     from ./linux/memory_hotplug.h:6,
                     from ./linux/init.h:7,
                     from ./linux/memblock.h:11,
                     from tests/common.h:8,
                     from tests/basic_api.h:5,
                     from main.c:2:
    ../../include/asm/../../arch/x86/include/asm/atomic.h:11:10: fatal error: asm/asm.h: No such file or directory
       11 | #include <asm/asm.h>
          |          ^~~~~~~~~~~
    
    Create a symlink to asm/asm.h in the same manner as the existing one to
    asm/cmpxchg.h.
    
    Signed-off-by: Aaron Thompson <dev@aaront.org>
    Link: https://lore.kernel.org/r/010101857c402765-96e2dbc6-b82b-47e2-a437-4834dbe0b96b-000000@us-west-2.amazonses.com
    Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: fastrpc: Don't remove map on creater_process and device_release [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Thu Nov 24 17:49:40 2022 +0000

    misc: fastrpc: Don't remove map on creater_process and device_release
    
    commit 5bb96c8f9268e2fdb0e5321cbc358ee5941efc15 upstream.
    
    Do not remove the map from the list on error path in
    fastrpc_init_create_process, instead call fastrpc_map_put, to avoid
    use-after-free. Do not remove it on fastrpc_device_release either,
    call fastrpc_map_put instead.
    
    The fastrpc_free_map is the only proper place to remove the map.
    This is called only after the reference count is 0.
    
    Fixes: b49f6d83e290 ("misc: fastrpc: Fix a possible double free")
    Cc: stable <stable@kernel.org>
    Co-developed-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20221124174941.418450-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Fix use-after-free and race in fastrpc_map_find [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Thu Nov 24 17:49:39 2022 +0000

    misc: fastrpc: Fix use-after-free and race in fastrpc_map_find
    
    commit 9446fa1683a7e3937d9970248ced427c1983a1c5 upstream.
    
    Currently, there is a race window between the point when the mutex is
    unlocked in fastrpc_map_lookup and the reference count increasing
    (fastrpc_map_get) in fastrpc_map_find, which can also lead to
    use-after-free.
    
    So lets merge fastrpc_map_find into fastrpc_map_lookup which allows us
    to both protect the maps list by also taking the &fl->lock spinlock and
    the reference count, since the spinlock will be released only after.
    Add take_ref argument to make this suitable for all callers.
    
    Fixes: 8f6c1d8c4f0c ("misc: fastrpc: Add fdlist implementation")
    Cc: stable <stable@kernel.org>
    Co-developed-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20221124174941.418450-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Fix use-after-free race condition for maps [+ + +]
Author: Ola Jeppsson <ola@snap.com>
Date:   Thu Nov 24 17:49:41 2022 +0000

    misc: fastrpc: Fix use-after-free race condition for maps
    
    commit 96b328d119eca7563c1edcc4e1039a62e6370ecb upstream.
    
    It is possible that in between calling fastrpc_map_get() until
    map->fl->lock is taken in fastrpc_free_map(), another thread can call
    fastrpc_map_lookup() and get a reference to a map that is about to be
    deleted.
    
    Rewrite fastrpc_map_get() to only increase the reference count of a map
    if it's non-zero. Propagate this to callers so they can know if a map is
    about to be deleted.
    
    Fixes this warning:
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate
    ...
    Call trace:
     refcount_warn_saturate
     [fastrpc_map_get inlined]
     [fastrpc_map_lookup inlined]
     fastrpc_map_create
     fastrpc_internal_invoke
     fastrpc_device_ioctl
     __arm64_sys_ioctl
     invoke_syscall
    
    Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20221124174941.418450-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/hugetlb: fix PTE marker handling in hugetlb_change_protection() [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Dec 22 21:55:10 2022 +0100

    mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()
    
    commit 0e678153f5be7e6c8d28835f5a678618da4b7a9c upstream.
    
    Patch series "mm/hugetlb: uffd-wp fixes for hugetlb_change_protection()".
    
    Playing with virtio-mem and background snapshots (using uffd-wp) on
    hugetlb in QEMU, I managed to trigger a VM_BUG_ON().  Looking into the
    details, hugetlb_change_protection() seems to not handle uffd-wp correctly
    in all cases.
    
    Patch #1 fixes my test case.  I don't have reproducers for patch #2, as it
    requires running into migration entries.
    
    I did not yet check in detail yet if !hugetlb code requires similar care.
    
    
    This patch (of 2):
    
    There are two problematic cases when stumbling over a PTE marker in
    hugetlb_change_protection():
    
    (1) We protect an uffd-wp PTE marker a second time using uffd-wp: we will
        end up in the "!huge_pte_none(pte)" case and mess up the PTE marker.
    
    (2) We unprotect a uffd-wp PTE marker: we will similarly end up in the
        "!huge_pte_none(pte)" case even though we cleared the PTE, because
        the "pte" variable is stale. We'll mess up the PTE marker.
    
    For example, if we later stumble over such a "wrongly modified" PTE marker,
    we'll treat it like a present PTE that maps some garbage page.
    
    This can, for example, be triggered by mapping a memfd backed by huge
    pages, registering uffd-wp, uffd-wp'ing an unmapped page and (a)
    uffd-wp'ing it a second time; or (b) uffd-unprotecting it; or (c)
    unregistering uffd-wp. Then, ff we trigger fallocate(FALLOC_FL_PUNCH_HOLE)
    on that file range, we will run into a VM_BUG_ON:
    
    [  195.039560] page:00000000ba1f2987 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0
    [  195.039565] flags: 0x7ffffc0001000(reserved|node=0|zone=0|lastcpupid=0x1fffff)
    [  195.039568] raw: 0007ffffc0001000 ffffe742c0000008 ffffe742c0000008 0000000000000000
    [  195.039569] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    [  195.039569] page dumped because: VM_BUG_ON_PAGE(compound && !PageHead(page))
    [  195.039573] ------------[ cut here ]------------
    [  195.039574] kernel BUG at mm/rmap.c:1346!
    [  195.039579] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    [  195.039581] CPU: 7 PID: 4777 Comm: qemu-system-x86 Not tainted 6.0.12-200.fc36.x86_64 #1
    [  195.039583] Hardware name: LENOVO 20WNS1F81N/20WNS1F81N, BIOS N35ET50W (1.50 ) 09/15/2022
    [  195.039584] RIP: 0010:page_remove_rmap+0x45b/0x550
    [  195.039588] Code: [...]
    [  195.039589] RSP: 0018:ffffbc03c3633ba8 EFLAGS: 00010292
    [  195.039591] RAX: 0000000000000040 RBX: ffffe742c0000000 RCX: 0000000000000000
    [  195.039592] RDX: 0000000000000002 RSI: ffffffff8e7aac1a RDI: 00000000ffffffff
    [  195.039592] RBP: 0000000000000001 R08: 0000000000000000 R09: ffffbc03c3633a08
    [  195.039593] R10: 0000000000000003 R11: ffffffff8f146328 R12: ffff9b04c42754b0
    [  195.039594] R13: ffffffff8fcc6328 R14: ffffbc03c3633c80 R15: ffff9b0484ab9100
    [  195.039595] FS:  00007fc7aaf68640(0000) GS:ffff9b0bbf7c0000(0000) knlGS:0000000000000000
    [  195.039596] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  195.039597] CR2: 000055d402c49110 CR3: 0000000159392003 CR4: 0000000000772ee0
    [  195.039598] PKRU: 55555554
    [  195.039599] Call Trace:
    [  195.039600]  <TASK>
    [  195.039602]  __unmap_hugepage_range+0x33b/0x7d0
    [  195.039605]  unmap_hugepage_range+0x55/0x70
    [  195.039608]  hugetlb_vmdelete_list+0x77/0xa0
    [  195.039611]  hugetlbfs_fallocate+0x410/0x550
    [  195.039612]  ? _raw_spin_unlock_irqrestore+0x23/0x40
    [  195.039616]  vfs_fallocate+0x12e/0x360
    [  195.039618]  __x64_sys_fallocate+0x40/0x70
    [  195.039620]  do_syscall_64+0x58/0x80
    [  195.039623]  ? syscall_exit_to_user_mode+0x17/0x40
    [  195.039624]  ? do_syscall_64+0x67/0x80
    [  195.039626]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [  195.039628] RIP: 0033:0x7fc7b590651f
    [  195.039653] Code: [...]
    [  195.039654] RSP: 002b:00007fc7aaf66e70 EFLAGS: 00000293 ORIG_RAX: 000000000000011d
    [  195.039655] RAX: ffffffffffffffda RBX: 0000558ef4b7f370 RCX: 00007fc7b590651f
    [  195.039656] RDX: 0000000018000000 RSI: 0000000000000003 RDI: 000000000000000c
    [  195.039657] RBP: 0000000008000000 R08: 0000000000000000 R09: 0000000000000073
    [  195.039658] R10: 0000000008000000 R11: 0000000000000293 R12: 0000000018000000
    [  195.039658] R13: 00007fb8bbe00000 R14: 000000000000000c R15: 0000000000001000
    [  195.039661]  </TASK>
    
    Fix it by not going into the "!huge_pte_none(pte)" case if we stumble over
    an exclusive marker.  spin_unlock() + continue would get the job done.
    
    However, instead, make it clearer that there are no fall-through
    statements: we process each case (hwpoison, migration, marker, !none,
    none) and then unlock the page table to continue with the next PTE.  Let's
    avoid "continue" statements and use a single spin_unlock() at the end.
    
    Link: https://lkml.kernel.org/r/20221222205511.675832-1-david@redhat.com
    Link: https://lkml.kernel.org/r/20221222205511.675832-2-david@redhat.com
    Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/hugetlb: fix uffd-wp handling for migration entries in hugetlb_change_protection() [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Dec 22 21:55:11 2022 +0100

    mm/hugetlb: fix uffd-wp handling for migration entries in hugetlb_change_protection()
    
    commit 44f86392bdd165da7e43d3c772aeb1e128ffd6c8 upstream.
    
    We have to update the uffd-wp SWP PTE bit independent of the type of
    migration entry.  Currently, if we're unlucky and we want to install/clear
    the uffd-wp bit just while we're migrating a read-only mapped hugetlb
    page, we would miss to set/clear the uffd-wp bit.
    
    Further, if we're processing a readable-exclusive migration entry and
    neither want to set or clear the uffd-wp bit, we could currently end up
    losing the uffd-wp bit.  Note that the same would hold for writable
    migrating entries, however, having a writable migration entry with the
    uffd-wp bit set would already mean that something went wrong.
    
    Note that the change from !is_readable_migration_entry ->
    writable_migration_entry is harmless and actually cleaner, as raised by
    Miaohe Lin and discussed in [1].
    
    [1] https://lkml.kernel.org/r/90dd6a93-4500-e0de-2bf0-bf522c311b0c@huawei.com
    
    Link: https://lkml.kernel.org/r/20221222205511.675832-3-david@redhat.com
    Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/hugetlb: pre-allocate pgtable pages for uffd wr-protects [+ + +]
Author: Peter Xu <peterx@redhat.com>
Date:   Wed Jan 4 17:52:05 2023 -0500

    mm/hugetlb: pre-allocate pgtable pages for uffd wr-protects
    
    commit fed15f1345dc8a7fc8baa81e8b55c3ba010d7f4b upstream.
    
    Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
    and hugetlb.  Shmem has pre-allocation ready for markers, but hugetlb path
    was overlooked.
    
    Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
    find the huge ptep.  It's possible that huge_pte_alloc() can fail with
    high memory pressure, in that case stop the loop immediately and fail
    silently.  This is not the most ideal solution but it matches with what we
    do with shmem meanwhile it avoids the splat in dmesg.
    
    Link: https://lkml.kernel.org/r/20230104225207.1066932-2-peterx@redhat.com
    Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Reported-by: James Houghton <jthoughton@google.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Acked-by: James Houghton <jthoughton@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: Nadav Amit <nadav.amit@gmail.com>
    Cc: <stable@vger.kernel.org>    [5.19+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma [+ + +]
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Dec 22 12:41:50 2022 -0800

    mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma
    
    commit ab0c3f1251b4670978fde0bd54161795a139b060 upstream.
    
    uprobe_write_opcode() uses collapse_pte_mapped_thp() to restore huge pmd,
    when removing a breakpoint from hugepage text: vma->anon_vma is always set
    in that case, so undo the prohibition.  And MADV_COLLAPSE ought to be able
    to collapse some page tables in a vma which happens to have anon_vma set
    from CoWing elsewhere.
    
    Is anon_vma lock required?  Almost not: if any page other than expected
    subpage of the non-anon huge page is found in the page table, collapse is
    aborted without making any change.  However, it is possible that an anon
    page was CoWed from this extent in another mm or vma, in which case a
    concurrent lookup might look here: so keep it away while clearing pmd (but
    perhaps we shall go back to using pmd_lock() there in future).
    
    Note that collapse_pte_mapped_thp() is exceptional in freeing a page table
    without having cleared its ptes: I'm uneasy about that, and had thought
    pte_clear()ing appropriate; but exclusive i_mmap lock does fix the
    problem, and we would have to move the mmu_notification if clearing those
    ptes.
    
    What this fixes is not a dangerous instability.  But I suggest Cc stable
    because uprobes "healing" has regressed in that way, so this should follow
    8d3c106e19e8 into those stable releases where it was backported (and may
    want adjustment there - I'll supply backports as needed).
    
    Link: https://lkml.kernel.org/r/b740c9fb-edba-92ba-59fb-7a5592e5dfc@google.com
    Fixes: 8d3c106e19e8 ("mm/khugepaged: take the right locks for page table retraction")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: Zach O'Keefe <zokeefe@google.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: <stable@vger.kernel.org>    [5.4+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/MADV_COLLAPSE: don't expand collapse when vm_end is past requested end [+ + +]
Author: Zach O'Keefe <zokeefe@google.com>
Date:   Sat Dec 24 00:20:34 2022 -0800

    mm/MADV_COLLAPSE: don't expand collapse when vm_end is past requested end
    
    commit 52dc031088f00e323140ece4004e70c33153c6dd upstream.
    
    MADV_COLLAPSE acts on one hugepage-aligned/sized region at a time, until
    it has collapsed all eligible memory contained within the bounds supplied
    by the user.
    
    At the top of each hugepage iteration we (re)lock mmap_lock and
    (re)validate the VMA for eligibility and update variables that might have
    changed while mmap_lock was dropped.  One thing that might occur is that
    the VMA could be resized, and as such, we refetch vma->vm_end to make sure
    we don't collapse past the end of the VMA's new end.
    
    However, it's possible that when refetching vma->vm_end that we expand the
    region acted on by MADV_COLLAPSE if vma->vm_end is greater than size+len
    supplied by the user.
    
    The consequence here is that we may attempt to collapse more memory than
    requested, possibly yielding either "too much success" or "false failure"
    user-visible results.  An example of the former is if we MADV_COLLAPSE the
    first 4MiB of a 2TiB mmap()'d file, the incorrect refetch would cause the
    operation to block for much longer than anticipated as we attempt to
    collapse the entire TiB region.  An example of the latter is that applying
    MADV_COLLPSE to a 4MiB file mapped to the start of a 6MiB VMA will
    successfully collapse the first 4MiB, then incorrectly attempt to collapse
    the last hugepage-aligned/sized region -- fail (since readahead/page cache
    lookup will fail) -- and report a failure to the user.
    
    I don't believe there is a kernel stability concern here as we always
    (re)validate the VMA / region accordingly.  Also as Hugh mentions, the
    user-visible effects are: we try to collapse more memory than requested
    by the user, and/or failing an operation that should have otherwise
    succeeded.  An example is trying to collapse a 4MiB file contained
    within a 12MiB VMA.
    
    Don't expand the acted-on region when refetching vma->vm_end.
    
    Link: https://lkml.kernel.org/r/20221224082035.3197140-1-zokeefe@google.com
    Fixes: 4d24de9425f7 ("mm: MADV_COLLAPSE: refetch vm_end after reacquiring mmap_lock")
    Signed-off-by: Zach O'Keefe <zokeefe@google.com>
    Reported-by: Hugh Dickins <hughd@google.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/shmem: restore SHMEM_HUGE_DENY precedence over MADV_COLLAPSE [+ + +]
Author: Zach O'Keefe <zokeefe@google.com>
Date:   Sat Dec 24 00:20:35 2022 -0800

    mm/shmem: restore SHMEM_HUGE_DENY precedence over MADV_COLLAPSE
    
    commit 3de0c269adc6c2fac0bb1fb11965f0de699dc32b upstream.
    
    SHMEM_HUGE_DENY is for emergency use by the admin, to disable allocation
    of shmem huge pages if, for example, a dangerous bug is found in their
    usage: see "deny" in Documentation/mm/transhuge.rst.  An app using
    madvise(,,MADV_COLLAPSE) should not be allowed to override it: restore its
    precedence over shmem_huge_force.
    
    Restore SHMEM_HUGE_DENY precedence over MADV_COLLAPSE.
    
    Link: https://lkml.kernel.org/r/20221224082035.3197140-2-zokeefe@google.com
    Fixes: 7c6c6cc4d3a2 ("mm/shmem: add flag to enforce shmem THP in hugepage_vma_check()")
    Signed-off-by: Zach O'Keefe <zokeefe@google.com>
    Suggested-by: Hugh Dickins <hughd@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Fri Dec 9 09:09:12 2022 +0100

    mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA
    
    commit 51d3d5eb74ff53b92dcff48b30ae2ed8edd85a32 upstream.
    
    Currently, we don't enable writenotify when enabling userfaultfd-wp on a
    shared writable mapping (for now only shmem and hugetlb).  The consequence
    is that vma->vm_page_prot will still include write permissions, to be set
    as default for all PTEs that get remapped (e.g., mprotect(), NUMA hinting,
    page migration, ...).
    
    So far, vma->vm_page_prot is assumed to be a safe default, meaning that we
    only add permissions (e.g., mkwrite) but not remove permissions (e.g.,
    wrprotect).  For example, when enabling softdirty tracking, we enable
    writenotify.  With uffd-wp on shared mappings, that changed.  More details
    on vma->vm_page_prot semantics were summarized in [1].
    
    This is problematic for uffd-wp: we'd have to manually check for a uffd-wp
    PTEs/PMDs and manually write-protect PTEs/PMDs, which is error prone.
    Prone to such issues is any code that uses vma->vm_page_prot to set PTE
    permissions: primarily pte_modify() and mk_pte().
    
    Instead, let's enable writenotify such that PTEs/PMDs/...  will be mapped
    write-protected as default and we will only allow selected PTEs that are
    definitely safe to be mapped without write-protection (see
    can_change_pte_writable()) to be writable.  In the future, we might want
    to enable write-bit recovery -- e.g., can_change_pte_writable() -- at more
    locations, for example, also when removing uffd-wp protection.
    
    This fixes two known cases:
    
    (a) remove_migration_pte() mapping uffd-wp'ed PTEs writable, resulting
        in uffd-wp not triggering on write access.
    (b) do_numa_page() / do_huge_pmd_numa_page() mapping uffd-wp'ed PTEs/PMDs
        writable, resulting in uffd-wp not triggering on write access.
    
    Note that do_numa_page() / do_huge_pmd_numa_page() can be reached even
    without NUMA hinting (which currently doesn't seem to be applicable to
    shmem), for example, by using uffd-wp with a PROT_WRITE shmem VMA.  On
    such a VMA, userfaultfd-wp is currently non-functional.
    
    Note that when enabling userfaultfd-wp, there is no need to walk page
    tables to enforce the new default protection for the PTEs: we know that
    they cannot be uffd-wp'ed yet, because that can only happen after enabling
    uffd-wp for the VMA in general.
    
    Also note that this makes mprotect() on ranges with uffd-wp'ed PTEs not
    accidentally set the write bit -- which would result in uffd-wp not
    triggering on later write access.  This commit makes uffd-wp on shmem
    behave just like uffd-wp on anonymous memory in that regard, even though,
    mixing mprotect with uffd-wp is controversial.
    
    [1] https://lkml.kernel.org/r/92173bad-caa3-6b43-9d1e-9a471fdbc184@redhat.com
    
    Link: https://lkml.kernel.org/r/20221209080912.7968-1-david@redhat.com
    Fixes: b1f9e876862d ("mm/uffd: enable write protection for shmem & hugetlbfs")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reported-by: Ives van Hoorne <ives@codesandbox.io>
    Debugged-by: Peter Xu <peterx@redhat.com>
    Acked-by: Peter Xu <peterx@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Alistair Popple <apopple@nvidia.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Nadav Amit <nadav.amit@gmail.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting [+ + +]
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Wed Dec 7 19:23:15 2022 +0800

    mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting
    
    commit 1e336aa0c0250ec84c6f16efac40c9f0138e367d upstream.
    
    Current code logic may be impacted by the setting of ROM/Bootloader,
    so unmask these bits first, then setting these bits accordingly.
    
    Fixes: 2b16cf326b70 ("mmc: sdhci-esdhc-imx: move tuning static configuration into hwinit function")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20221207112315.1812222-1-haibo.chen@nxp.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sunxi-mmc: Fix clock refcount imbalance during unbind [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Tue Aug 9 21:25:09 2022 -0500

    mmc: sunxi-mmc: Fix clock refcount imbalance during unbind
    
    commit 8509419758f2cc28dd05370385af0d91573b76b4 upstream.
    
    If the controller is suspended by runtime PM, the clock is already
    disabled, so do not try to disable it again during removal. Use
    pm_runtime_disable() to flush any pending runtime PM transitions.
    
    Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220810022509.43743-1-samuel@sholland.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mptcp: explicitly specify sock family at subflow creation time [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Jan 12 18:42:51 2023 +0100

    mptcp: explicitly specify sock family at subflow creation time
    
    commit 6bc1fe7dd748ba5e76e7917d110837cafe7b931c upstream.
    
    Let the caller specify the to-be-created subflow family.
    
    For a given MPTCP socket created with the AF_INET6 family, the current
    userspace PM can already ask the kernel to create subflows in v4 and v6.
    If "plain" IPv4 addresses are passed to the kernel, they are
    automatically mapped in v6 addresses "by accident". This can be
    problematic because the userspace will need to pass different addresses,
    now the v4-mapped-v6 addresses to destroy this new subflow.
    
    On the other hand, if the MPTCP socket has been created with the AF_INET
    family, the command to create a subflow in v6 will be accepted but the
    result will not be the one as expected as new subflow will be created in
    IPv4 using part of the v6 addresses passed to the kernel: not creating
    the expected subflow then.
    
    No functional change intended for the in-kernel PM where an explicit
    enforcement is currently in place. This arbitrary enforcement will be
    leveraged by other patches in a future version.
    
    Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment")
    Cc: stable@vger.kernel.org
    Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.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>

mptcp: netlink: respect v4/v6-only sockets [+ + +]
Author: Matthieu Baerts <matthieu.baerts@tessares.net>
Date:   Thu Jan 12 18:42:52 2023 +0100

    mptcp: netlink: respect v4/v6-only sockets
    
    commit fb00ee4f3343acb2b9222ca9b73b47dd1e1a8efc upstream.
    
    If an MPTCP socket has been created with AF_INET6 and the IPV6_V6ONLY
    option has been set, the userspace PM would allow creating subflows
    using IPv4 addresses, e.g. mapped in v6.
    
    The kernel side of userspace PM will also accept creating subflows with
    local and remote addresses having different families. Depending on the
    subflow socket's family, different behaviours are expected:
     - If AF_INET is forced with a v6 address, the kernel will take the last
       byte of the IP and try to connect to that: a new subflow is created
       but to a non expected address.
     - If AF_INET6 is forced with a v4 address, the kernel will try to
       connect to a v4 address (v4-mapped-v6). A -EBADF error from the
       connect() part is then expected.
    
    It is then required to check the given families can be accepted. This is
    done by using a new helper for addresses family matching, taking care of
    IPv4 vs IPv4-mapped-IPv6 addresses. This helper will be re-used later by
    the in-kernel path-manager to use mixed IPv4 and IPv6 addresses.
    
    While at it, a clear error message is now reported if there are some
    conflicts with the families that have been passed by the userspace.
    
    Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.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>

 
net/ethtool/ioctl: return -EOPNOTSUPP if we have no phy stats [+ + +]
Author: Daniil Tatianin <d-tatianin@yandex-team.ru>
Date:   Mon Dec 26 14:48:23 2022 +0300

    net/ethtool/ioctl: return -EOPNOTSUPP if we have no phy stats
    
    [ Upstream commit 9deb1e9fb88b1120a908676fa33bdf9e2eeaefce ]
    
    It's not very useful to copy back an empty ethtool_stats struct and
    return 0 if we didn't actually have any stats. This also allows for
    further simplification of this function in the future commits.
    
    Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: fix missing mutex_unlock in mlx5_fw_fatal_reporter_err_work() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Jan 5 19:42:20 2023 +0800

    net/mlx5: fix missing mutex_unlock in mlx5_fw_fatal_reporter_err_work()
    
    commit 90e7cb78b81543998217b0eb446c067ce2191a79 upstream.
    
    Add missing mutex_unlock() before returning from
    mlx5_fw_fatal_reporter_err_work().
    
    Fixes: 9078e843efec ("net/mlx5: Avoid recovery in probe flows")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/ulp: use consistent error code when blocking ULP [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Jan 18 13:24:12 2023 +0100

    net/ulp: use consistent error code when blocking ULP
    
    commit 8ccc99362b60c6f27bb46f36fdaaccf4ef0303de upstream.
    
    The referenced commit changed the error code returned by the kernel
    when preventing a non-established socket from attaching the ktls
    ULP. Before to such a commit, the user-space got ENOTCONN instead
    of EINVAL.
    
    The existing self-tests depend on such error code, and the change
    caused a failure:
    
      RUN           global.non_established ...
     tls.c:1673:non_established:Expected errno (22) == ENOTCONN (107)
     non_established: Test failed at step #3
              FAIL  global.non_established
    
    In the unlikely event existing applications do the same, address
    the issue by restoring the prior error code in the above scenario.
    
    Note that the only other ULP performing similar checks at init
    time - smc_ulp_ops - also fails with ENOTCONN when trying to attach
    the ULP to a non-established socket.
    
    Reported-by: Sabrina Dubroca <sd@queasysnail.net>
    Fixes: 2c02d41d71f9 ("net/ulp: prevent ULP without clone op from entering the LISTEN status")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/7bb199e7a93317fb6f8bf8b9b2dc71c18f337cde.1674042685.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: ethernet: marvell: octeontx2: Fix uninitialized variable warning [+ + +]
Author: Anuradha Weeraman <anuradha@debian.org>
Date:   Sun Dec 25 23:12:22 2022 +0530

    net: ethernet: marvell: octeontx2: Fix uninitialized variable warning
    
    [ Upstream commit d3805695fe1e7383517903715cefc9bbdcffdc90 ]
    
    Fix for uninitialized variable warning.
    
    Addresses-Coverity: ("Uninitialized scalar variable")
    Signed-off-by: Anuradha Weeraman <anuradha@debian.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix general protection fault in nilfs_btree_insert() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Jan 5 14:53:56 2023 +0900

    nilfs2: fix general protection fault in nilfs_btree_insert()
    
    commit 7633355e5c7f29c049a9048e461427d1d8ed3051 upstream.
    
    If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
    block by calling __nilfs_btree_get_block() against an invalid virtual
    block address, it returns -ENOENT because conversion of the virtual block
    address to a disk block address fails.  However, this return value is the
    same as the internal code that b-tree lookup routines return to indicate
    that the block being searched does not exist, so functions that operate on
    that b-tree may misbehave.
    
    When nilfs_btree_insert() receives this spurious 'not found' code from
    nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
    successful and continues the insert operation using incomplete lookup path
    data, causing the following crash:
    
     general protection fault, probably for non-canonical address
     0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
     KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
     ...
     RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
     RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
     RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
     Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
     ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c
     28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
     ...
     Call Trace:
     <TASK>
      nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]
      nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147
      nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101
      __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991
      __block_write_begin fs/buffer.c:2041 [inline]
      block_write_begin+0x93/0x1e0 fs/buffer.c:2102
      nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261
      generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
      __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900
      generic_file_write_iter+0xab/0x310 mm/filemap.c:3932
      call_write_iter include/linux/fs.h:2186 [inline]
      new_sync_write fs/read_write.c:491 [inline]
      vfs_write+0x7dc/0xc50 fs/read_write.c:584
      ksys_write+0x177/0x2a0 fs/read_write.c:637
      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
     ...
     </TASK>
    
    This patch fixes the root cause of this problem by replacing the error
    code that __nilfs_btree_get_block() returns on block address conversion
    failure from -ENOENT to another internal code -EINVAL which means that the
    b-tree metadata is corrupted.
    
    By returning -EINVAL, it propagates without glitches, and for all relevant
    b-tree operations, functions in the upper bmap layer output an error
    message indicating corrupted b-tree metadata via
    nilfs_bmap_convert_error(), and code -EIO will be eventually returned as
    it should be.
    
    Link: https://lkml.kernel.org/r/000000000000bd89e205f0e38355@google.com
    Link: https://lkml.kernel.org/r/20230105055356.8811-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+ede796cecd5296353515@syzkaller.appspotmail.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nommu: fix do_munmap() error path [+ + +]
Author: Liam Howlett <liam.howlett@oracle.com>
Date:   Mon Jan 9 20:57:21 2023 +0000

    nommu: fix do_munmap() error path
    
    commit 80be727ec87225797771a39f3e6801baf291faaf upstream.
    
    When removing a VMA from the tree fails due to no memory, do not free the
    VMA since a reference still exists.
    
    Link: https://lkml.kernel.org/r/20230109205708.956103-1-Liam.Howlett@oracle.com
    Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
    Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nommu: fix memory leak in do_mmap() error path [+ + +]
Author: Liam Howlett <liam.howlett@oracle.com>
Date:   Mon Jan 9 20:55:21 2023 +0000

    nommu: fix memory leak in do_mmap() error path
    
    commit 7f31cced5724e6d414fe750aa1cd7e7b578ec22f upstream.
    
    The preallocation of the maple tree nodes may leak if the error path to
    "error_just_free" is taken.  Fix this by moving the freeing of the maple
    tree nodes to a shared location for all error paths.
    
    Link: https://lkml.kernel.org/r/20230109205507.955577-1-Liam.Howlett@oracle.com
    Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
    Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nommu: fix split_vma() map_count error [+ + +]
Author: Liam Howlett <liam.howlett@oracle.com>
Date:   Mon Jan 9 20:58:20 2023 +0000

    nommu: fix split_vma() map_count error
    
    commit fd9edbdbdcde6b489ce59f326755ef16a2ffadd7 upstream.
    
    During the maple tree conversion of nommu, an error in counting the VMAs
    was introduced by counting the existing VMA again.  The counting used to
    be decremented by one and incremented by two, but now it only increments
    by two.  Fix the counting error by moving the increment outside the
    setup_vma_to_mm() function to the callers.
    
    Link: https://lkml.kernel.org/r/20230109205809.956325-1-Liam.Howlett@oracle.com
    Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
    Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
octeontx2-pf: Avoid use of GFP_KERNEL in atomic context [+ + +]
Author: Geetha sowjanya <gakula@marvell.com>
Date:   Fri Jan 13 11:49:02 2023 +0530

    octeontx2-pf: Avoid use of GFP_KERNEL in atomic context
    
    commit 87b93b678e95c7d93fe6a55b0e0fbda26d8c7760 upstream.
    
    Using GFP_KERNEL in preemption disable context, causing below warning
    when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
    
    [   32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
    [   32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
    [   32.558707] preempt_count: 1, expected: 0
    [   32.562710] RCU nest depth: 0, expected: 0
    [   32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G        W          6.2.0-rc2-00269-gae9dcb91c606 #7
    [   32.576188] Hardware name: Marvell CN106XX board (DT)
    [   32.581232] Call trace:
    [   32.583670]  dump_backtrace.part.0+0xe0/0xf0
    [   32.587937]  show_stack+0x18/0x30
    [   32.591245]  dump_stack_lvl+0x68/0x84
    [   32.594900]  dump_stack+0x18/0x34
    [   32.598206]  __might_resched+0x12c/0x160
    [   32.602122]  __might_sleep+0x48/0xa0
    [   32.605689]  __kmem_cache_alloc_node+0x2b8/0x2e0
    [   32.610301]  __kmalloc+0x58/0x190
    [   32.613610]  otx2_sq_aura_pool_init+0x1a8/0x314
    [   32.618134]  otx2_open+0x1d4/0x9d0
    
    To avoid use of GFP_ATOMIC for memory allocation, disable preemption
    after all memory allocation is done.
    
    Fixes: 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura free")
    Signed-off-by: Geetha sowjanya <gakula@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt [+ + +]
Author: Kevin Hao <haokexin@gmail.com>
Date:   Wed Jan 18 15:13:00 2023 +0800

    octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt
    
    commit 55ba18dc62deff5910c0fa64486dea1ff20832ff upstream.
    
    The commit 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura
    free") uses the get/put_cpu() to protect the usage of percpu pointer
    in ->aura_freeptr() callback, but it also unnecessarily disable the
    preemption for the blockable memory allocation. The commit 87b93b678e95
    ("octeontx2-pf: Avoid use of GFP_KERNEL in atomic context") tried to
    fix these sleep inside atomic warnings. But it only fix the one for
    the non-rt kernel. For the rt kernel, we still get the similar warnings
    like below.
      BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
      in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
      preempt_count: 1, expected: 0
      RCU nest depth: 0, expected: 0
      3 locks held by swapper/0/1:
       #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30
       #1: ffff000100c276c0 (&mbox->lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4
       #2: ffffffbfef6537e0 (&cpu_rcache->lock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac
      Preemption disabled at:
      [<ffff800008b1908c>] otx2_rq_aura_pool_init+0x14c/0x284
      CPU: 20 PID: 1 Comm: swapper/0 Tainted: G        W          6.2.0-rc3-rt1-yocto-preempt-rt #1
      Hardware name: Marvell OcteonTX CN96XX board (DT)
      Call trace:
       dump_backtrace.part.0+0xe8/0xf4
       show_stack+0x20/0x30
       dump_stack_lvl+0x9c/0xd8
       dump_stack+0x18/0x34
       __might_resched+0x188/0x224
       rt_spin_lock+0x64/0x110
       alloc_iova_fast+0x1ac/0x2ac
       iommu_dma_alloc_iova+0xd4/0x110
       __iommu_dma_map+0x80/0x144
       iommu_dma_map_page+0xe8/0x260
       dma_map_page_attrs+0xb4/0xc0
       __otx2_alloc_rbuf+0x90/0x150
       otx2_rq_aura_pool_init+0x1c8/0x284
       otx2_init_hw_resources+0xe4/0x3a4
       otx2_open+0xf0/0x610
       __dev_open+0x104/0x224
       __dev_change_flags+0x1e4/0x274
       dev_change_flags+0x2c/0x7c
       ic_open_devs+0x124/0x2f8
       ip_auto_config+0x180/0x42c
       do_one_initcall+0x90/0x4dc
       do_basic_setup+0x10c/0x14c
       kernel_init_freeable+0x10c/0x13c
       kernel_init+0x2c/0x140
       ret_from_fork+0x10/0x20
    
    Of course, we can shuffle the get/put_cpu() to only wrap the invocation
    of ->aura_freeptr() as what commit 87b93b678e95 does. But there are only
    two ->aura_freeptr() callbacks, otx2_aura_freeptr() and
    cn10k_aura_freeptr(). There is no usage of perpcu variable in the
    otx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it.
    We can move the get/put_cpu() into the corresponding callback which
    really has the percpu variable usage and avoid the sprinkling of
    get/put_cpu() in several places.
    
    Fixes: 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura free")
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Link: https://lore.kernel.org/r/20230118071300.3271125-1-haokexin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node, take 2 [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Tue Jan 3 12:00:32 2023 -0600

    of: fdt: Honor CONFIG_CMDLINE* even without /chosen node, take 2
    
    [ Upstream commit 064e32dc5b03114d0767893fecdaf7b5dfd8c286 ]
    
    I do not read a strict requirement on /chosen node in either ePAPR or in
    Documentation/devicetree. Help text for CONFIG_CMDLINE and
    CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on
    the presence of /chosen or the presense of /chosen/bootargs.
    
    However the early check for /chosen and bailing out in
    early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not
    really related to /chosen node or the particular method of passing cmdline
    from bootloader.
    
    This leads to counterintuitive combinations (assuming
    CONFIG_CMDLINE_EXTEND=y):
    
    a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar"
    b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline==""
    c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar"
    
    Rework early_init_dt_scan_chosen() so that the cmdline config options are
    always handled.
    
    [commit msg written by Alexander Sverdlin]
    
    Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Tested-by: Geoff Levand <geoff@infradead.org>
    Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-2-7038e88b18b6@kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
panic: Consolidate open-coded panic_on_warn checks [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 17 15:43:24 2022 -0800

    panic: Consolidate open-coded panic_on_warn checks
    
    commit 79cc1ba7badf9e7a12af99695a557e9ce27ee967 upstream.
    
    Several run-time checkers (KASAN, UBSAN, KFENCE, KCSAN, sched) roll
    their own warnings, and each check "panic_on_warn". Consolidate this
    into a single function so that future instrumentation can be added in
    a single location.
    
    Cc: Marco Elver <elver@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ben Segall <bsegall@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: Valentin Schneider <vschneid@redhat.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: David Gow <davidgow@google.com>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: "Paul E. McKenney" <paulmck@kernel.org>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: kasan-dev@googlegroups.com
    Cc: linux-mm@kvack.org
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Marco Elver <elver@google.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
    Link: https://lore.kernel.org/r/20221117234328.594699-4-keescook@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

panic: Expose "warn_count" to sysfs [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 17 15:43:26 2022 -0800

    panic: Expose "warn_count" to sysfs
    
    commit 8b05aa26336113c4cea25f1c333ee8cd4fc212a6 upstream.
    
    Since Warn count is now tracked and is a fairly interesting signal, add
    the entry /sys/kernel/warn_count to expose it to userspace.
    
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-6-keescook@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

panic: Introduce warn_limit [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 17 15:43:25 2022 -0800

    panic: Introduce warn_limit
    
    commit 9fc9e278a5c0b708eeffaf47d6eb0c82aa74ed78 upstream.
    
    Like oops_limit, add warn_limit for limiting the number of warnings when
    panic_on_warn is not set.
    
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: Eric Biggers <ebiggers@google.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: linux-doc@vger.kernel.org
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-5-keescook@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

panic: Separate sysctl logic from CONFIG_SMP [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 17 15:43:21 2022 -0800

    panic: Separate sysctl logic from CONFIG_SMP
    
    commit 9360d035a579d95d1e76c471061b9065b18a0eb1 upstream.
    
    In preparation for adding more sysctls directly in kernel/panic.c, split
    CONFIG_SMP from the logic that adds sysctls.
    
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-1-keescook@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf/x86/rapl: Add support for Intel Emerald Rapids [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Wed Jan 4 22:58:31 2023 +0800

    perf/x86/rapl: Add support for Intel Emerald Rapids
    
    [ Upstream commit 57512b57dcfaf63c52d8ad2fb35321328cde31b0 ]
    
    Emerald Rapids RAPL support is the same as previous Sapphire Rapids.
    Add Emerald Rapids model for RAPL.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20230104145831.25498-2-rui.zhang@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf/x86/rapl: Add support for Intel Meteor Lake [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Wed Jan 4 22:58:30 2023 +0800

    perf/x86/rapl: Add support for Intel Meteor Lake
    
    [ Upstream commit f52853a668bfeddd79f319d536a506f68cc2b478 ]
    
    Meteor Lake RAPL support is the same as previous Sky Lake.
    Add Meteor Lake model for RAPL.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20230104145831.25498-1-rui.zhang@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf/x86/rapl: Treat Tigerlake like Icelake [+ + +]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 28 06:34:54 2022 -0500

    perf/x86/rapl: Treat Tigerlake like Icelake
    
    [ Upstream commit c07311b5509f6035f1dd828db3e90ff4859cf3b9 ]
    
    Since Tigerlake seems to have inherited its cstates and other RAPL power
    caps from Icelake, assume it also follows Icelake for its RAPL events.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20221228113454.1199118-1-rodrigo.vivi@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pktcdvd: check for NULL returna fter calling bio_split_to_limits() [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 16 08:51:05 2023 -0700

    pktcdvd: check for NULL returna fter calling bio_split_to_limits()
    
    commit 3e9900f3bd7ba30d60f82b162b70a1dffe4e8e24 upstream.
    
    The revert of the removal of this driver happened after we fixed up
    the split limits for NOWAIT issue, hence it got missed. Ensure that
    we check for a NULL bio after splitting, in case it should be retried.
    
    Marking this as fixing both commits, so that stable backport will do
    this correctly.
    
    Cc: stable@vger.kernel.org
    Fixes: 9cea62b2cbab ("block: don't allow splitting of a REQ_NOWAIT bio")
    Fixes: 4b83e99ee709 ("Revert "pktcdvd: remove driver."")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pNFS/filelayout: Fix coalescing test for single DS [+ + +]
Author: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Date:   Tue Dec 20 12:31:29 2022 -0500

    pNFS/filelayout: Fix coalescing test for single DS
    
    [ Upstream commit a6b9d2fa0024e7e399c26facd0fb466b7396e2b9 ]
    
    When there is a single DS no striping constraints need to be placed on
    the IO. When such constraint is applied then buffered reads don't
    coalesce to the DS's rsize.
    
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
prlimit: do_prlimit needs to have a speculation check [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jan 20 11:03:20 2023 +0100

    prlimit: do_prlimit needs to have a speculation check
    
    commit 739790605705ddcf18f21782b9c99ad7d53a8c11 upstream.
    
    do_prlimit() adds the user-controlled resource value to a pointer that
    will subsequently be dereferenced.  In order to help prevent this
    codepath from being used as a spectre "gadget" a barrier needs to be
    added after checking the range.
    
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Tested-by: Jordy Zomer <jordyzomer@google.com>
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
proc: fix PIE proc-empty-vm, proc-pid-vm tests [+ + +]
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Fri Jan 6 22:30:14 2023 +0300

    proc: fix PIE proc-empty-vm, proc-pid-vm tests
    
    commit 5316a017d093f644675a56523bcf5787ba8f4fef upstream.
    
    vsyscall detection code uses direct call to the beginning of
    the vsyscall page:
    
            asm ("call %P0" :: "i" (0xffffffffff600000))
    
    It generates "call rel32" instruction but it is not relocated if binary
    is PIE, so binary segfaults into random userspace address and vsyscall
    page status is detected incorrectly.
    
    Do more direct:
    
            asm ("call *%rax")
    
    which doesn't do need any relocaltions.
    
    Mark g_vsyscall as volatile for a good measure, I didn't find instruction
    setting it to 0. Now the code is obviously correct:
    
            xor     eax, eax
            mov     rdi, rbp
            mov     rsi, rbp
            mov     DWORD PTR [rip+0x2d15], eax      # g_vsyscall = 0
            mov     rax, 0xffffffffff600000
            call    rax
            mov     DWORD PTR [rip+0x2d02], 1        # g_vsyscall = 1
            mov     eax, DWORD PTR ds:0xffffffffff600000
            mov     DWORD PTR [rip+0x2cf1], 2        # g_vsyscall = 2
            mov     edi, [rip+0x2ceb]                # exit(g_vsyscall)
            call    exit
    
    Note: fixed proc-empty-vm test oopses 5.19.0-28-generic kernel
            but this is separate story.
    
    Link: https://lkml.kernel.org/r/Y7h2xvzKLg36DSq8@p183
    Fixes: 5bc73bb3451b9 ("proc: test how it holds up with mapping'less process")
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
    Tested-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
r8169: fix dmar pte write access is not set error [+ + +]
Author: Chunhao Lin <hau@realtek.com>
Date:   Mon Dec 26 20:31:53 2022 +0800

    r8169: fix dmar pte write access is not set error
    
    [ Upstream commit bb41c13c05c23d9bc46b4e37d8914078c6a40e3a ]
    
    When close device, if wol is enabled, rx will be enabled. When open
    device it will cause rx packet to be dma to the wrong memory address
    after pci_set_master() and system log will show blow messages.
    
    DMAR: DRHD: handling fault status reg 3
    DMAR: [DMA Write] Request device [02:00.0] PASID ffffffff fault addr
    ffdd4000 [fault reason 05] PTE Write access is not set
    
    In this patch, driver disable tx/rx when close device. If wol is
    enabled, only enable rx filter and disable rxdv_gate(if support) to
    let hardware only receive packet to fifo but not to dma it.
    
    Signed-off-by: Chunhao Lin <hau@realtek.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

r8169: move rtl_wol_enable_rx() and rtl_prepare_power_down() [+ + +]
Author: Chunhao Lin <hau@realtek.com>
Date:   Mon Dec 26 20:31:52 2022 +0800

    r8169: move rtl_wol_enable_rx() and rtl_prepare_power_down()
    
    [ Upstream commit ad425666a1f05d9b215a84cf010c3789b2ea8206 ]
    
    There is no functional change. Moving these two functions for following
    patch "r8169: fix dmar pte write access is not set error".
    
    Signed-off-by: Chunhao Lin <hau@realtek.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/srp: Move large values to a new enum for gcc13 [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Mon Dec 12 13:04:11 2022 +0100

    RDMA/srp: Move large values to a new enum for gcc13
    
    [ Upstream commit 56c5dab20a6391604df9521f812c01d1e3fe1bd0 ]
    
    Since gcc13, each member of an enum has the same type as the enum [1]. And
    that is inherited from its members. Provided these two:
      SRP_TAG_NO_REQ        = ~0U,
      SRP_TAG_TSK_MGMT      = 1U << 31
    all other members are unsigned ints.
    
    Esp. with SRP_MAX_SGE and SRP_TSK_MGMT_SQ_SIZE and their use in min(),
    this results in the following warnings:
      include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast
      drivers/infiniband/ulp/srp/ib_srp.c:563:42: note: in expansion of macro 'min'
    
      include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast
      drivers/infiniband/ulp/srp/ib_srp.c:2369:27: note: in expansion of macro 'min'
    
    So move the large values away to a separate enum, so that they don't
    affect other members.
    
    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
    
    Link: https://lore.kernel.org/r/20221212120411.13750-1-jirislaby@kernel.org
    Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jan 20 11:16:59 2023 +0100

    Revert "serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler"
    
    commit 2cbafffbf69addd7509072f4be5917f81d238cf6 upstream.
    
    This reverts commit f24771b62a83239f0dce816bddf0f6807f436235 as it is
    reported to break the build.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/r/202301200130.ttBiTzfO-lkp@intel.com
    Fixes: f24771b62a83 ("serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler")
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Valentin Caron <valentin.caron@foss.st.com> # V3
    Cc: Marek Vasut <marex@denx.de>
    Cc: Johan Hovold <johan@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()" [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 13 12:43:26 2023 +0000

    Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()"
    
    commit 80f8a66dede0a4b4e9e846765a97809c6fe49ce5 upstream.
    
    This reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293.
    
    ieee80211_if_free() is already called from free_netdev(ndev)
    because ndev->priv_destructor == ieee80211_if_free
    
    syzbot reported:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
    CPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline]
    RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline]
    RIP: 0010:free_percpu mm/percpu.c:2271 [inline]
    RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254
    Code: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc
    RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002
    RAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004
    RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020
    RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000
    R13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988
    FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352
    ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411
    mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583
    hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176
    genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968
    genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
    genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065
    netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564
    genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
    netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]
    netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356
    netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xd3/0x120 net/socket.c:734
    ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
    __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Fixes: 13e5afd3d773 ("wifi: mac80211: fix memory leak in ieee80211_if_add()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Zhengchao Shao <shaozhengchao@huawei.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230113124326.3533978-1-edumazet@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: dts: sifive: fu740: fix size of pcie 32bit memory [+ + +]
Author: Ben Dooks <ben.dooks@codethink.co.uk>
Date:   Fri Jan 6 13:44:56 2023 +0000

    riscv: dts: sifive: fu740: fix size of pcie 32bit memory
    
    commit 43d5f5d63699724d47f0d9e0eae516a260d232b4 upstream.
    
    The 32-bit memory resource is needed for non-prefetchable memory
    allocations on the PCIe bus, however with some cards (such as the
    SM768) the system fails to allocate memory from this.
    
    Checking the allocation against the datasheet, it looks like there
    has been a mis-calcualation of the resource for the first memory
    region (0x0060090000..0x0070ffffff) which in the data-sheet for
    the fu740 (v1p2) is from 0x0060000000..0x007fffffff. Changing
    this to allocate from 0x0060090000..0x007fffffff fixes the probing
    issues.
    
    Fixes: ae80d5148085 ("riscv: dts: Add PCIe support for the SiFive FU740-C000 SoC")
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Greentime Hu <greentime.hu@sifive.com>
    Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
    Cc: stable@vger.kernel.org
    Tested-by: Ron Economos <re@w6rz.net> # from IRC
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID [+ + +]
Author: Hao Sun <sunhao.th@gmail.com>
Date:   Thu Dec 22 10:44:14 2022 +0800

    selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID
    
    [ Upstream commit cedebd74cf3883f0384af9ec26b4e6f8f1964dd4 ]
    
    Verify that nullness information is not porpagated in the branches
    of register to register JEQ and JNE operations if one of them is
    PTR_TO_BTF_ID. Implement this in C level so we can use CO-RE.
    
    Signed-off-by: Hao Sun <sunhao.th@gmail.com>
    Suggested-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20221222024414.29539-2-sunhao.th@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mptcp: userspace: validate v4-v6 subflows mix [+ + +]
Author: Matthieu Baerts <matthieu.baerts@tessares.net>
Date:   Thu Jan 12 18:42:53 2023 +0100

    selftests: mptcp: userspace: validate v4-v6 subflows mix
    
    commit 4656d72c1efa495a58ad6d8b073a60907073e4e6 upstream.
    
    MPTCP protocol supports having subflows in both IPv4 and IPv6. In Linux,
    it is possible to have that if the MPTCP socket has been created with
    AF_INET6 family without the IPV6_V6ONLY option.
    
    Here, a new IPv4 subflow is being added to the initial IPv6 connection,
    then being removed using Netlink commands.
    
    Cc: stable@vger.kernel.org # v5.19+
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.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>

selftests: net: fix cmsg_so_mark.sh test hang [+ + +]
Author: Po-Hsu Lin <po-hsu.lin@canonical.com>
Date:   Thu Dec 29 13:41:06 2022 +0800

    selftests: net: fix cmsg_so_mark.sh test hang
    
    [ Upstream commit 1573c6882018f69991aead951d09423ce978adac ]
    
    This cmsg_so_mark.sh test will hang on non-amd64 systems because of the
    infinity loop for argument parsing in cmsg_sender.
    
    Variable "o" in cs_parse_args() for taking getopt() should be an int,
    otherwise it will be 255 when getopt() returns -1 on non-amd64 system
    and thus causing infinity loop.
    
    Link: https://lore.kernel.org/lkml/CA+G9fYsM2k7mrF7W4V_TrZ-qDauWM394=8yEJ=-t1oUg8_40YA@mail.gmail.com/t/
    Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: amba-pl011: fix high priority character transmission in rs486 mode [+ + +]
Author: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Date:   Sun Jan 8 19:17:35 2023 +0100

    serial: amba-pl011: fix high priority character transmission in rs486 mode
    
    commit 4f39aca2360c82dccd2f5179d77e94aab665bea6 upstream.
    
    In RS485 mode the transmission of a high priority character fails since it
    is written to the data register before the transmitter is enabled. Fix this
    in pl011_tx_chars() by enabling RS485 transmission before writing the
    character.
    
    Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
    Link: https://lore.kernel.org/r/20230108181735.10937-1-LinoSanfilippo@gmx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: atmel: fix incorrect baudrate setup [+ + +]
Author: Tobias Schramm <t.schramm@manjaro.org>
Date:   Mon Jan 9 08:29:40 2023 +0100

    serial: atmel: fix incorrect baudrate setup
    
    commit 5bfdd3c654bd879bff50c2e85e42f85ae698b42f upstream.
    
    Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
    setup") changed uart_set_options to select the correct baudrate
    configuration based on the absolute error between requested baudrate and
    available standard baudrate settings.
    Prior to that commit the baudrate was selected based on which predefined
    standard baudrate did not exceed the requested baudrate.
    This change of selection logic was never reflected in the atmel serial
    driver. Thus the comment left in the atmel serial driver is no longer
    accurate.
    Additionally the manual rounding up described in that comment and applied
    via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
    tty_termios_encode_baud_rate to determine the appropriate baudrate flags
    this can cause baudrate selection to fail entirely because
    tty_termios_encode_baud_rate will only select a baudrate if relative error
    between requested and selected baudrate does not exceed +/-2%.
    Fix that by requesting actual, exact baudrate used by the serial.
    
    Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
    Acked-by: Richard Genoud <richard.genoud@gmail.com>
    Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: exar: Add support for Sealevel 7xxxC serial cards [+ + +]
Author: Matthew Howell <matthew.howell@sealevel.com>
Date:   Thu Jan 19 14:40:29 2023 -0500

    serial: exar: Add support for Sealevel 7xxxC serial cards
    
    commit 14ee78d5932afeb710c8305196a676a715bfdea8 upstream.
    
    Add support for Sealevel 7xxxC serial cards.
    
    This patch:
    * Adds IDs to recognize 7xxxC cards from Sealevel Systems.
    * Updates exar_pci_probe() to set nr_ports to last two bytes of primary
      dev ID for these cards.
    
    Signed-off-by: Matthew Howell <matthew.howell@sealevel.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2301191440010.22558@tstest-VirtualBox
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: pch_uart: Pass correct sg to dma_unmap_sg() [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Tue Jan 3 11:34:35 2023 +0200

    serial: pch_uart: Pass correct sg to dma_unmap_sg()
    
    commit e8914b52e5b024e4af3d810a935fe0805eee8a36 upstream.
    
    A local variable sg is used to store scatterlist pointer in
    pch_dma_tx_complete(). The for loop doing Tx byte accounting before
    dma_unmap_sg() alters sg in its increment statement. Therefore, the
    pointer passed into dma_unmap_sg() won't match to the one given to
    dma_map_sg().
    
    To fix the problem, use priv->sg_tx_p directly in dma_unmap_sg()
    instead of the local variable.
    
    Fixes: da3564ee027e ("pch_uart: add multi-scatter processing")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20230103093435.4396-1-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Jan 12 19:04:17 2023 +0100

    serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
    
    commit f24771b62a83239f0dce816bddf0f6807f436235 upstream.
    
    Requesting an interrupt with IRQF_ONESHOT will run the primary handler
    in the hard-IRQ context even in the force-threaded mode. The
    force-threaded mode is used by PREEMPT_RT in order to avoid acquiring
    sleeping locks (spinlock_t) in hard-IRQ context. This combination
    makes it impossible and leads to "sleeping while atomic" warnings.
    
    Use one interrupt handler for both handlers (primary and secondary)
    and drop the IRQF_ONESHOT flag which is not needed.
    
    Fixes: e359b4411c283 ("serial: stm32: fix threaded interrupt handling")
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Valentin Caron <valentin.caron@foss.st.com> # V3
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230112180417.25595-1-marex@denx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soc: qcom: apr: Make qcom,protection-domain optional again [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Thu Dec 29 16:16:48 2022 +0100

    soc: qcom: apr: Make qcom,protection-domain optional again
    
    commit 599d41fb8ea8bd2a99ca9525dd69405020e43dda upstream.
    
    APR should not fail if the service device tree node does not have
    the qcom,protection-domain property, since this functionality does
    not exist on older platforms such as MSM8916 and MSM8996.
    
    Ignore -EINVAL (returned when the property does not exist) to fix
    a regression on 6.2-rc1 that prevents audio from working:
    
      qcom,apr remoteproc0:smd-edge.apr_audio_svc.-1.-1:
        Failed to read second value of qcom,protection-domain
      qcom,apr remoteproc0:smd-edge.apr_audio_svc.-1.-1:
        Failed to add apr 3 svc
    
    Fixes: 6d7860f5750d ("soc: qcom: apr: Add check for idr_alloc and of_property_read_string_index")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221229151648.19839-3-stephan@gerhold.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
staging: vchiq_arm: fix enum vchiq_status return types [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 17:39:32 2023 +0100

    staging: vchiq_arm: fix enum vchiq_status return types
    
    commit 7d83299351fe7c812c529f5e39fe63b5312e4233 upstream.
    
    gcc-13 notices a type mismatch between function declaration
    and definition for a few functions that have been converted
    from returning vchiq specific status values to regular error
    codes:
    
    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:662:5: error: conflicting types for 'vchiq_initialise' due to enum/integer mismatch; have 'int(struct vchiq_instance **)' [-Werror=enum-int-mismatch]
    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1411:1: error: conflicting types for 'vchiq_use_internal' due to enum/integer mismatch; have 'int(struct vchiq_state *, struct vchiq_service *, enum USE_TYPE_E)' [-Werror=enum-int-mismatch]
    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1468:1: error: conflicting types for 'vchiq_release_internal' due to enum/integer mismatch; have 'int(struct vchiq_state *, struct vchiq_service *)' [-Werror=enum-int-mismatch]
    
    Change the declarations to match the actual function definition.
    
    Fixes: a9fbd828be7f ("staging: vchiq_arm: drop enum vchiq_status from vchiq_*_internal")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20230117163957.1109872-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
thunderbolt: Disable XDomain lane 1 only in software connection manager [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Sep 8 09:45:22 2022 +0300

    thunderbolt: Disable XDomain lane 1 only in software connection manager
    
    commit 84ee211c83212f4d35b56e0603acdcc41f860f1b upstream.
    
    When firmware connection manager is in use we should not touch the lane
    adapter (well or any) configuration space so do this only when we know
    that the software connection manager is active.
    
    Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding")
    Cc: stable@vger.kernel.org
    Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

thunderbolt: Do not call PM runtime functions in tb_retimer_scan() [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Dec 29 14:10:30 2022 +0200

    thunderbolt: Do not call PM runtime functions in tb_retimer_scan()
    
    commit 23257cfc1cb7202fd0065e9f4a6a0aac1c04c4a9 upstream.
    
    We cannot call PM runtime functions in tb_retimer_scan() because it will
    also be called when retimers are scanned from userspace (happens when
    there is no device connected on ChromeOS for instance) and at the same
    USB4 port runtime resume hook. This leads to hang because neither can
    proceed.
    
    Fix this by runtime resuming USB4 ports in tb_scan_port() instead. This
    makes sure the ports are runtime PM active when retimers are added under
    it while avoiding the reported hang as well.
    
    Reported-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
    Fixes: 1e56c88adecc ("thunderbolt: Runtime resume USB4 port when retimers are scanned")
    Cc: stable@vger.kernel.org
    Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

thunderbolt: Do not report errors if on-board retimers are found [+ + +]
Author: Utkarsh Patel <utkarsh.h.patel@intel.com>
Date:   Thu Dec 22 20:22:46 2022 -0800

    thunderbolt: Do not report errors if on-board retimers are found
    
    commit c28f3d80383571d3630df1a0e89500d23e855924 upstream.
    
    Currently we return an error even if on-board retimers are found and
    that's not expected. Fix this to return an error only if there was one
    and 0 otherwise.
    
    Fixes: 1e56c88adecc ("thunderbolt: Runtime resume USB4 port when retimers are scanned")
    Cc: stable@vger.kernel.org
    Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

thunderbolt: Use correct function to calculate maximum USB3 link rate [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri May 20 13:35:19 2022 +0300

    thunderbolt: Use correct function to calculate maximum USB3 link rate
    
    commit e8ff07fb33026c5c1bb5b81293496faba5d68059 upstream.
    
    We need to take minimum of both sides of the USB3 link into consideration,
    not just the downstream port. Fix this by calling tb_usb3_max_link_rate()
    instead.
    
    Fixes: 0bd680cd900c ("thunderbolt: Add USB3 bandwidth management")
    Cc: stable@vger.kernel.org
    Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tools/virtio: initialize spinlocks in vring_test.c [+ + +]
Author: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Date:   Wed Oct 12 08:29:49 2022 +0200

    tools/virtio: initialize spinlocks in vring_test.c
    
    [ Upstream commit c262f75cb6bb5a63828e72ce3b8fe808e5029479 ]
    
    The virtio_device vqs_list spinlocks must be initialized before use to
    prevent functions that manipulate the device virtualqueues, such as
    vring_new_virtqueue(), from blocking indefinitely.
    
    Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
    Message-Id: <20221012062949.1526176-1-ricardo.canuelo@collabora.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: fix possible null-ptr-defer in spk_ttyio_release [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Fri Dec 2 14:06:33 2022 +0800

    tty: fix possible null-ptr-defer in spk_ttyio_release
    
    commit 5abbeebd8296c2301023b8dc4b5a6c0d5229b4f5 upstream.
    
    Run the following tests on the qemu platform:
    
    syzkaller:~# modprobe speakup_audptr
     input: Speakup as /devices/virtual/input/input4
     initialized device: /dev/synth, node (MAJOR 10, MINOR 125)
     speakup 3.1.6: initialized
     synth name on entry is: (null)
     synth probe
    
    spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned
    failed (errno -16), then remove the module, we will get a null-ptr-defer
    problem, as follow:
    
    syzkaller:~# modprobe -r speakup_audptr
     releasing synth audptr
     BUG: kernel NULL pointer dereference, address: 0000000000000080
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 0 P4D 0
     Oops: 0002 [#1] PREEMPT SMP PTI
     CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1
     RIP: 0010:mutex_lock+0x14/0x30
     Call Trace:
     <TASK>
      spk_ttyio_release+0x19/0x70 [speakup]
      synth_release.part.6+0xac/0xc0 [speakup]
      synth_remove+0x56/0x60 [speakup]
      __x64_sys_delete_module+0x156/0x250
      ? fpregs_assert_state_consistent+0x1d/0x50
      do_syscall_64+0x37/0x90
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
     </TASK>
     Modules linked in: speakup_audptr(-) speakup
     Dumping ftrace buffer:
    
    in_synth->dev was not initialized during modprobe, so we add check
    for in_synth->dev to fix this bug.
    
    Fixes: 4f2a81f3a882 ("speakup: Reference synth from tty and tty from synth")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221202060633.217364-1-cuigaosheng1@huawei.com
    Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Dec 21 17:40:22 2022 +0100

    tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
    
    commit b8caf69a6946e18ffebad49847e258f5b6d52ac2 upstream.
    
    Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on
    default RX FIFO depth, e.g. 16.  Later during serial startup the
    qcom_geni_serial_port_setup() updates the RX FIFO depth
    (port->rx_fifo_depth) to match real device capabilities, e.g. to 32.
    
    The RX UART handle code will read "port->rx_fifo_depth" number of words
    into "port->rx_fifo" buffer, thus exceeding the bounds.  This can be
    observed in certain configurations with Qualcomm Bluetooth HCI UART
    device and KASAN:
    
      Bluetooth: hci0: QCA Product ID   :0x00000010
      Bluetooth: hci0: QCA SOC Version  :0x400a0200
      Bluetooth: hci0: QCA ROM Version  :0x00000200
      Bluetooth: hci0: QCA Patch Version:0x00000d2b
      Bluetooth: hci0: QCA controller version 0x02000200
      Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
      bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2
      Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)
      Bluetooth: hci0: QCA Failed to download patch (-2)
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c
      Write of size 4 at addr ffff279347d578c0 by task swapper/0/0
    
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26
      Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
      Call trace:
       dump_backtrace.part.0+0xe0/0xf0
       show_stack+0x18/0x40
       dump_stack_lvl+0x8c/0xb8
       print_report+0x188/0x488
       kasan_report+0xb4/0x100
       __asan_store4+0x80/0xa4
       handle_rx_uart+0xa8/0x18c
       qcom_geni_serial_handle_rx+0x84/0x9c
       qcom_geni_serial_isr+0x24c/0x760
       __handle_irq_event_percpu+0x108/0x500
       handle_irq_event+0x6c/0x110
       handle_fasteoi_irq+0x138/0x2cc
       generic_handle_domain_irq+0x48/0x64
    
    If the RX FIFO depth changes after probe, be sure to resize the buffer.
    
    Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210 [+ + +]
Author: Juhyung Park <qkrwngud825@gmail.com>
Date:   Tue Jan 17 17:51:54 2023 +0900

    usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210
    
    commit dbd24ec17b85b45f4e823d1aa5607721920f2b05 upstream.
    
    The commit e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
    blacklists UAS for all of RTL9210 enclosures.
    
    The RTL9210 controller was advertised with UAS since its release back in
    2019 and was shipped with a lot of enclosure products with different
    firmware combinations.
    
    Blacklist UAS only for HIKSEMI MD202.
    
    This should hopefully be replaced with more robust method than just
    comparing strings.  But with limited information [1] provided thus far
    (dmesg when the device is plugged in, which includes manufacturer and
    product, but no lsusb -v to compare against), this is the best we can do
    for now.
    
    [1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com
    
    Fixes: e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Hongling Zeng <zenghongling@kylinos.cn>
    Cc: stable@vger.kernel.org
    Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20230117085154.123301-1-qkrwngud825@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: acpi: add helper to check port lpm capability using acpi _DSM [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:15 2023 +0200

    usb: acpi: add helper to check port lpm capability using acpi _DSM
    
    commit cd702d18c882d5a4ea44bbdb38edd5d5577ef640 upstream.
    
    Add a helper to evaluate ACPI usb device specific method (_DSM) provided
    in case the USB3 port shouldn't enter U1 and U2 link states.
    
    This _DSM was added as port specific retimer configuration may lead to
    exit latencies growing beyond U1/U2 exit limits, and OS needs a way to
    find which ports can't support U1/U2 link power management states.
    
    This _DSM is also used by windows:
    Link: https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-
    
    Some patch issues found in testing resolved by Ron Lee
    
    Cc: stable@vger.kernel.org
    Tested-by: Ron Lee <ron.lee@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-7-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdns3: remove fetched trb from cache before dequeuing [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Tue Nov 15 05:00:39 2022 -0500

    usb: cdns3: remove fetched trb from cache before dequeuing
    
    commit 1301c7b9f7efad2f11ef924e317c18ebd714fc9a upstream.
    
    After doorbell DMA fetches the TRB. If during dequeuing request
    driver changes NORMAL TRB to LINK TRB but doesn't delete it from
    controller cache then controller will handle cached TRB and packet
    can be lost.
    
    The example scenario for this issue looks like:
    1. queue request - set doorbell
    2. dequeue request
    3. send OUT data packet from host
    4. Device will accept this packet which is unexpected
    5. queue new request - set doorbell
    6. Device lost the expected packet.
    
    By setting DFLUSH controller clears DRDY bit and stop DMA transfer.
    
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    cc: <stable@vger.kernel.org>
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20221115100039.441295-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: hub: disable autosuspend for TI TUSB8041 [+ + +]
Author: Flavio Suligoi <f.suligoi@asem.it>
Date:   Mon Dec 19 13:47:59 2022 +0100

    usb: core: hub: disable autosuspend for TI TUSB8041
    
    commit 7171b0e261b17de96490adf053b8bb4b00061bcf upstream.
    
    The Texas Instruments TUSB8041 has an autosuspend problem at high
    temperature.
    
    If there is not USB traffic, after a couple of ms, the device enters in
    autosuspend mode. In this condition the external clock stops working, to
    save energy. When the USB activity turns on, ther hub exits the
    autosuspend state, the clock starts running again and all works fine.
    
    At ambient temperature all works correctly, but at high temperature,
    when the USB activity turns on, the external clock doesn't restart and
    the hub disappears from the USB bus.
    
    Disabling the autosuspend mode for this hub solves the issue.
    
    Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
    Cc: stable <stable@kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: gadget: Add ID numbers to configfs-gadget driver names [+ + +]
Author: Chanh Nguyen <chanh@os.amperecomputing.com>
Date:   Wed Jan 11 13:51:05 2023 +0700

    USB: gadget: Add ID numbers to configfs-gadget driver names
    
    commit 7c07553807c5125c89de242d35c10c206fd8e6bb upstream.
    
    It is unable to use configfs to attach more than one gadget. When
    attaching the second gadget, it always fails and the kernel message
    prints out:
    
    Error: Driver 'configfs-gadget' is already registered, aborting...
    UDC core: g1: driver registration failed: -16
    
    This commit fixes the problem by using the gadget name as a suffix
    to each configfs_gadget's driver name, thus making the names
    distinct.
    
    Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
    Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Frank Li <frank.li@nxp.com>
    Link: https://lore.kernel.org/r/20230111065105.29205-1-chanh@os.amperecomputing.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() [+ + +]
Author: Maciej Żenczykowski <maze@google.com>
Date:   Tue Jan 17 05:18:39 2023 -0800

    usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
    
    commit c6ec929595c7443250b2a4faea988c62019d5cd2 upstream.
    
    In Google internal bug 265639009 we've received an (as yet) unreproducible
    crash report from an aarch64 GKI 5.10.149-android13 running device.
    
    AFAICT the source code is at:
      https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10
    
    The call stack is:
      ncm_close() -> ncm_notify() -> ncm_do_notify()
    with the crash at:
      ncm_do_notify+0x98/0x270
    Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)
    
    Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):
    
      // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)
      0B 0D 00 79    strh w11, [x8, #6]
    
      // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)
      6C 0A 00 B9    str  w12, [x19, #8]
    
      // x10 (NULL) was read here from offset 0 of valid pointer x9
      // IMHO we're reading 'cdev->gadget' and getting NULL
      // gadget is indeed at offset 0 of struct usb_composite_dev
      2A 01 40 F9    ldr  x10, [x9]
    
      // loading req->buf pointer, which is at offset 0 of struct usb_request
      69 02 40 F9    ldr  x9, [x19]
    
      // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed
      4B 5D 40 B9    ldr  w11, [x10, #0x5c]
    
    which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:
    
      event->wLength = cpu_to_le16(8);
      req->length = NCM_STATUS_BYTECOUNT;
    
      /* SPEED_CHANGE data is up/down speeds in bits/sec */
      data = req->buf + sizeof *event;
      data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
    
    My analysis of registers and NULL ptr deref crash offset
      (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
    heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:
      data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
    which calls:
      ncm_bitrate(NULL)
    which then calls:
      gadget_is_superspeed(NULL)
    which reads
      ((struct usb_gadget *)NULL)->max_speed
    and hits a panic.
    
    AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
    (remember there's a GKI KABI reservation of 16 bytes in struct work_struct)
    
    It's not at all clear to me how this is all supposed to work...
    but returning 0 seems much better than panic-ing...
    
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Cc: Carlos Llamas <cmllamas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: g_webcam: Send color matching descriptor per frame [+ + +]
Author: Daniel Scally <dan.scally@ideasonboard.com>
Date:   Fri Dec 16 16:05:28 2022 +0000

    usb: gadget: g_webcam: Send color matching descriptor per frame
    
    commit e95765e97d9cb93258a4840440d410fa6ff7e819 upstream.
    
    Currently the color matching descriptor is only sent across the wire
    a single time, following the descriptors for each format and frame.
    According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching
    Descriptors"):
    
    "Only one instance is allowed for a given format and if present,
    the Color Matching descriptor shall be placed following the Video
    and Still Image Frame descriptors for that format".
    
    Add another reference to the color matching descriptor after the
    yuyv frames so that it's correctly transmitted for that format
    too.
    
    Fixes: a9914127e834 ("USB gadget: Webcam device")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Link: https://lore.kernel.org/r/20221216160528.479094-1-dan.scally@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: gadgetfs: Fix race between mounting and unmounting [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Dec 23 09:59:09 2022 -0500

    USB: gadgetfs: Fix race between mounting and unmounting
    
    commit d18dcfe9860e842f394e37ba01ca9440ab2178f4 upstream.
    
    The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
    in the gadgetfs driver, involving processes concurrently mounting and
    unmounting the gadgetfs filesystem.  In particular, gadgetfs_fill_super()
    can race with gadgetfs_kill_sb(), causing the latter to deallocate
    the_device while the former is using it.  The output from KASAN says,
    in part:
    
    BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
    BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
    BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
    BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
    BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
    BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
    BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
    Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
    
    CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Call Trace:
     <TASK>
    ...
     atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
     __refcount_sub_and_test include/linux/refcount.h:272 [inline]
     __refcount_dec_and_test include/linux/refcount.h:315 [inline]
     refcount_dec_and_test include/linux/refcount.h:333 [inline]
     put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
     gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
     deactivate_locked_super+0xa7/0xf0 fs/super.c:332
     vfs_get_super fs/super.c:1190 [inline]
     get_tree_single+0xd0/0x160 fs/super.c:1207
     vfs_get_tree+0x88/0x270 fs/super.c:1531
     vfs_fsconfig_locked fs/fsopen.c:232 [inline]
    
    The simplest solution is to ensure that gadgetfs_fill_super() and
    gadgetfs_kill_sb() are serialized by making them both acquire a new
    mutex.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+33d7ad66d65044b93f16@syzkaller.appspotmail.com
    Reported-and-tested-by: Gerald Lee <sundaywind2004@gmail.com>
    Link: https://lore.kernel.org/linux-usb/CAO3qeMVzXDP-JU6v1u5Ags6Q-bb35kg3=C6d04DjzA9ffa5x1g@mail.gmail.com/
    Fixes: e5d82a7360d1 ("vfs: Convert gadgetfs to use the new mount API")
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/Y6XCPXBpn3tmjdCC@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: host: ehci-fsl: Fix module alias [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Jan 20 13:27:14 2023 +0100

    usb: host: ehci-fsl: Fix module alias
    
    commit 5d3d01ae15d2f37ed0325c99ab47ef0ae5d05f3c upstream.
    
    Commit ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent
    driver module") changed DRV_NAME which was used for MODULE_ALIAS as well.
    Starting from this the module alias didn't match the platform device
    name created in fsl-mph-dr-of.c
    Change DRV_NAME to match the driver name for host mode in fsl-mph-dr-of.
    This is needed for module autoloading on ls1021a.
    
    Fixes: ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent driver module")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20230120122714.3848784-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jan 20 14:53:30 2023 +0100

    USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100
    
    commit 14ff7460bb58662d86aa50298943cc7d25532e28 upstream.
    
    The USB_DEVICE_ID_CODEMERCS_IOW100 header size was incorrect, it should
    be 12, not 13.
    
    Cc: stable <stable@kernel.org>
    Fixes: 17a82716587e ("USB: iowarrior: fix up report size handling for some devices")
    Reported-by: Christoph Jung <jung@codemercs.com>
    Link: https://lore.kernel.org/r/20230120135330.3842518-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: misc: onboard_hub: Invert driver registration order [+ + +]
Author: Matthias Kaehlcke <mka@chromium.org>
Date:   Tue Jan 10 17:32:52 2023 +0000

    usb: misc: onboard_hub: Invert driver registration order
    
    commit e5854355d76b8d768cea8e4fc3ce6dfdba25518a upstream.
    
    The onboard_hub 'driver' consists of two drivers, a platform
    driver and a USB driver. Currently when the onboard hub driver
    is initialized it first registers the platform driver, then the
    USB driver. This results in a race condition when the 'attach'
    work is executed, which is scheduled when the platform device
    is probed. The purpose of fhe 'attach' work is to bind elegible
    USB hub devices to the onboard_hub USB driver. This fails if
    the work runs before the USB driver has been registered.
    
    Register the USB driver first, then the platform driver. This
    increases the chances that the onboard_hub USB devices are probed
    before their corresponding platform device, which the USB driver
    tries to locate in _probe(). The driver already handles this
    situation and defers probing if the onboard hub platform device
    doesn't exist yet.
    
    Cc: stable@vger.kernel.org
    Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver")
    Link: https://lore.kernel.org/lkml/Y6W00vQm3jfLflUJ@hovoldconsulting.com/T/#m0d64295f017942fd988f7c53425db302d61952b4
    Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Link: https://lore.kernel.org/r/20230110172954.v2.1.I75494ebee7027a50235ce4b1e930fa73a578fbe2@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: onboard_hub: Move 'attach' work to the driver [+ + +]
Author: Matthias Kaehlcke <mka@chromium.org>
Date:   Tue Jan 10 17:32:53 2023 +0000

    usb: misc: onboard_hub: Move 'attach' work to the driver
    
    commit cde37881e2e14590675d0acdfbad408300d9ca95 upstream.
    
    Currently each onboard_hub platform device owns an 'attach' work,
    which is scheduled when the device probes. With this deadlocks
    have been reported on a Raspberry Pi 3 B+ [1], which has nested
    onboard hubs.
    
    The flow of the deadlock is something like this (with the onboard_hub
    driver built as a module) [2]:
    
    - USB root hub is instantiated
    - core hub driver calls onboard_hub_create_pdevs(), which creates the
      'raw' platform device for the 1st level hub
    - 1st level hub is probed by the core hub driver
    - core hub driver calls onboard_hub_create_pdevs(), which creates
      the 'raw' platform device for the 2nd level hub
    
    - onboard_hub platform driver is registered
    - platform device for 1st level hub is probed
      - schedules 'attach' work
    - platform device for 2nd level hub is probed
      - schedules 'attach' work
    
    - onboard_hub USB driver is registered
    - device (and parent) lock of hub is held while the device is
      re-probed with the onboard_hub driver
    
    - 'attach' work (running in another thread) calls driver_attach(), which
       blocks on one of the hub device locks
    
    - onboard_hub_destroy_pdevs() is called by the core hub driver when one
      of the hubs is detached
    - destroying the pdevs invokes onboard_hub_remove(), which waits for the
      'attach' work to complete
      - waits forever, since the 'attach' work can't acquire the device lock
    
    Use a single work struct for the driver instead of having a work struct
    per onboard hub platform driver instance. With that it isn't necessary
    to cancel the work in onboard_hub_remove(), which fixes the deadlock.
    The work is only cancelled when the driver is unloaded.
    
    [1] https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/
    [2] https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/
    
    Cc: stable@vger.kernel.org
    Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver")
    Link: https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/
    Link: https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/
    Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Link: https://lore.kernel.org/r/20230110172954.v2.2.I16b51f32db0c32f8a8532900bfe1c70c8572881a@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: fix error return code in omap2430_probe() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Dec 30 16:17:30 2022 +0800

    usb: musb: fix error return code in omap2430_probe()
    
    commit bd449ad8cee9d4b523abbdfa73e1a2a08333f331 upstream.
    
    Before calling platform_get_resource() in omap2430_probe(), the 'ret' is
    re-assgined to 0, it can't return an error code, if platform_get_resource
    fails. Set the error code to -EINVAL to fix this.
    
    Fixes: ffbe2feac59b ("usb: musb: omap2430: Fix probe regression for missing resources")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221230081730.1655616-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: cp210x: add SCALANCE LPE-9000 device id [+ + +]
Author: Michael Adler <michael.adler@siemens.com>
Date:   Tue Jan 3 14:48:50 2023 +0100

    USB: serial: cp210x: add SCALANCE LPE-9000 device id
    
    commit 3f9e76e31704a325170e5aec2243c8d084d74854 upstream.
    
    Add the USB serial console device ID for Siemens SCALANCE LPE-9000
    which have a USB port for their serial console.
    
    Signed-off-by: Michael Adler <michael.adler@siemens.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EC200U modem [+ + +]
Author: Ali Mirghasemi <ali.mirghasemi1376@gmail.com>
Date:   Wed Dec 28 15:08:47 2022 +0330

    USB: serial: option: add Quectel EC200U modem
    
    commit d9bbb15881046bd76f8710c76e26a740eee997ef upstream.
    
    Add support for EC200U modem
    
    0x0901: EC200U - AT + AP + CP + NMEA + DIAG + MOS
    
    usb-device output:
    T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=2c7c ProdID=0901 Rev= 3.18
    S: Manufacturer=Android
    S: Product=Android
    C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=400mA
    A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=32ms
    I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=83(I) Atr=03(Int.) MxPS= 512 Ivl=4096ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=89(I) Atr=03(Int.) MxPS= 512 Ivl=4096ms
    I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Ali Mirghasemi <ali.mirghasemi1376@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G (CS) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Tue Dec 27 01:28:25 2022 -0800

    USB: serial: option: add Quectel EM05-G (CS) modem
    
    commit bb78654b0b46316dac687fd4b7dc7cce636f46cd upstream.
    
    The EM05-G (CS) modem has 2 USB configurations that are configurable via
    the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate
    with the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=030C Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=030C Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G (GR) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Tue Dec 27 01:44:30 2022 -0800

    USB: serial: option: add Quectel EM05-G (GR) modem
    
    commit 6c331f32e32ac71eb3e8b93fceda2802d7ecb889 upstream.
    
    The EM05-G (GR) modem has 2 USB configurations that are configurable via
    the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate
    with the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0313 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0313 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G (RS) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Tue Dec 27 01:51:27 2022 -0800

    USB: serial: option: add Quectel EM05-G (RS) modem
    
    commit b72d13977689f0c717444010e108c4f20658dfee upstream.
    
    The EM05-G (RS) modem has 2 USB configurations that are configurable via
    the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate
    with the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0314 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0314 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05CN (SG) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Sun Jan 15 18:07:27 2023 -0800

    USB: serial: option: add Quectel EM05CN (SG) modem
    
    commit 1541dd0097c0f8f470e76eddf5120fc55a7e3101 upstream.
    
    The EM05CN (SG) modem has 2 USB configurations that are configurable via the AT
    command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with
    the following interfaces, respectively:
    
    "MBIM"  : AT + MBIM + DIAG + NMEA  + MODEM
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    
    The detailed description of the USB configuration for each mode as follows:
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0310 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 2 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0310 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05CN modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Sun Jan 15 18:33:28 2023 -0800

    USB: serial: option: add Quectel EM05CN modem
    
    commit 71dfd381a7c051f16a61f82fbd38a4cca563bdca upstream.
    
    The EM05CN modem has 2 USB configurations that are configurable via the AT
    command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with
    the following interfaces, respectively:
    
    "MBIM"  : AT + MBIM + DIAG + NMEA  + MODEM
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    
    The detailed description of the USB configuration for each mode as follows:
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0312 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 2 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0312 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: altmodes/displayport: Add pin assignment helper [+ + +]
Author: Prashant Malani <pmalani@chromium.org>
Date:   Wed Jan 11 02:05:41 2023 +0000

    usb: typec: altmodes/displayport: Add pin assignment helper
    
    commit 582836e3cfab4faafbdc93bbec96fce036a08ee1 upstream.
    
    The code to extract a peripheral's currently supported Pin Assignments
    is repeated in a couple of locations. Factor it out into a separate
    function.
    
    This will also make it easier to add fixes (we only need to update 1
    location instead of 2).
    
    Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
    Cc: stable@vger.kernel.org
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Prashant Malani <pmalani@chromium.org>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20230111020546.3384569-1-pmalani@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: altmodes/displayport: Fix pin assignment calculation [+ + +]
Author: Prashant Malani <pmalani@chromium.org>
Date:   Wed Jan 11 02:05:42 2023 +0000

    usb: typec: altmodes/displayport: Fix pin assignment calculation
    
    commit 9682b41e52cc9f42f5c33caf410464392adaef04 upstream.
    
    Commit c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin
    assignment for UFP receptacles") fixed the pin assignment calculation
    to take into account whether the peripheral was a plug or a receptacle.
    
    But the "pin_assignments" sysfs logic was not updated. Address this by
    using the macros introduced in the aforementioned commit in the sysfs
    logic too.
    
    Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
    Cc: stable@vger.kernel.org
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Prashant Malani <pmalani@chromium.org>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20230111020546.3384569-2-pmalani@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail [+ + +]
Author: ChiYuan Huang <cy_huang@richtek.com>
Date:   Mon Jan 9 15:19:50 2023 +0800

    usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail
    
    commit 36f78477ac2c89e9a2eed4a31404a291a3450b5d upstream.
    
    There's the altmode re-registeration issue after data role
    swap (DR_SWAP).
    
    Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP
    can initiate the VDM command to get partner identity information.
    
    For a USBPD 3.0 UFP device, it may already get the identity information
    from its port partner before DR_SWAP. If DR_SWAP send or receive at the
    mean time, 'send_discover' flag will be raised again. It causes discover
    identify action restart while entering ready state. And after all
    discover actions are done, the 'tcpm_register_altmodes' will be called.
    If old altmode is not unregistered, this sysfs create fail can be found.
    
    In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes.
    For UFP, the original altmodes keep registered.
    
    This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes'
    must be called whatever the current data role is.
    
    Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together")
    Reported-by: TommyYl Chen <tommyyl.chen@mediatek.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/1673248790-15794-1-git-send-email-cy_huang@richtek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci: Check endpoint is valid before dereferencing it [+ + +]
Author: Jimmy Hu <hhhuuu@google.com>
Date:   Mon Jan 16 16:22:11 2023 +0200

    usb: xhci: Check endpoint is valid before dereferencing it
    
    commit e8fb5bc76eb86437ab87002d4a36d6da02165654 upstream.
    
    When the host controller is not responding, all URBs queued to all
    endpoints need to be killed. This can cause a kernel panic if we
    dereference an invalid endpoint.
    
    Fix this by using xhci_get_virt_ep() helper to find the endpoint and
    checking if the endpoint is valid before dereferencing it.
    
    [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
    [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8
    
    [233311.853964] pc : xhci_hc_died+0x10c/0x270
    [233311.853971] lr : xhci_hc_died+0x1ac/0x270
    
    [233311.854077] Call trace:
    [233311.854085]  xhci_hc_died+0x10c/0x270
    [233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4
    [233311.854105]  call_timer_fn+0x50/0x2d4
    [233311.854112]  expire_timers+0xac/0x2e4
    [233311.854118]  run_timer_softirq+0x300/0xabc
    [233311.854127]  __do_softirq+0x148/0x528
    [233311.854135]  irq_exit+0x194/0x1a8
    [233311.854143]  __handle_domain_irq+0x164/0x1d0
    [233311.854149]  gic_handle_irq.22273+0x10c/0x188
    [233311.854156]  el1_irq+0xfc/0x1a8
    [233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
    [233311.854185]  cpuidle_enter_state+0x1f0/0x764
    [233311.854194]  do_idle+0x594/0x6ac
    [233311.854201]  cpu_startup_entry+0x7c/0x80
    [233311.854209]  secondary_start_kernel+0x170/0x198
    
    Fixes: 50e8725e7c42 ("xhci: Refactor command watchdog and fix split string.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jimmy Hu <hhhuuu@google.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Message-ID: <0fe978ed-8269-9774-1c40-f8a98c17e838@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vdpa/mlx5: Avoid overwriting CVQ iotlb [+ + +]
Author: Eli Cohen <elic@nvidia.com>
Date:   Mon Nov 14 15:17:56 2022 +0200

    vdpa/mlx5: Avoid overwriting CVQ iotlb
    
    [ Upstream commit 38fc462f57ef4e5dc722bab6824854b105de8aa2 ]
    
    When qemu uses different address spaces for data and control virtqueues,
    the current code would overwrite the control virtqueue iotlb through the
    dup_iotlb call. Fix this by referring to the address space identifier
    and the group to asid mapping to determine which mapping needs to be
    updated. We also move the address space logic from mlx5 net to core
    directory.
    
    Reported-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Message-Id: <20221114131759.57883-6-elic@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

vdpa/mlx5: Avoid using reslock in event_handler [+ + +]
Author: Eli Cohen <elic@nvidia.com>
Date:   Mon Nov 14 15:17:55 2022 +0200

    vdpa/mlx5: Avoid using reslock in event_handler
    
    [ Upstream commit 0dbc1b4ae07d003b2e88ba9d4142846320f8e349 ]
    
    event_handler runs under atomic context and may not acquire reslock. We
    can still guarantee that the handler won't be called after suspend by
    clearing nb_registered, unregistering the handler and flushing the
    workqueue.
    
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Message-Id: <20221114131759.57883-5-elic@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

vdpa/mlx5: Return error on vlan ctrl commands if not supported [+ + +]
Author: Eli Cohen <elic@nvidia.com>
Date:   Mon Nov 14 15:17:53 2022 +0200

    vdpa/mlx5: Return error on vlan ctrl commands if not supported
    
    [ Upstream commit 5aec804936bbff182081f1cdc271fcb76af1a4ff ]
    
    Check if VIRTIO_NET_F_CTRL_VLAN is negotiated and return error if
    control VQ command is received.
    
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Message-Id: <20221114131759.57883-3-elic@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vdpa_sim_net: should not drop the multicast/broadcast packet [+ + +]
Author: Cindy Lu <lulu@redhat.com>
Date:   Wed Dec 14 13:43:06 2022 +0800

    vdpa_sim_net: should not drop the multicast/broadcast packet
    
    [ Upstream commit 72455a1142527e607e1d69439f3ffa2ef6d09e26 ]
    
    In the receive_filter(), should not drop the packet with the
    broadcast/multicast address. Add the check for this
    
    Signed-off-by: Cindy Lu <lulu@redhat.com>
    Message-Id: <20221214054306.24145-1-lulu@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vduse: Validate vq_num in vduse_validate_config() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Mon Nov 28 07:57:15 2022 -0800

    vduse: Validate vq_num in vduse_validate_config()
    
    [ Upstream commit 937c783aa3d8d77963ec91918d3298edb45b9161 ]
    
    Add a limit to 'config->vq_num' which is user controlled data which
    comes from an vduse_ioctl to prevent large memory allocations.
    
    Micheal says  - This limit is somewhat arbitrary.
    However, currently virtio pci and ccw are limited to a 16 bit vq number.
    While MMIO isn't it is also isn't used with lots of VQs due to
    current lack of support for per-vq interrupts.
    Thus, the 0xffff limit on number of VQs corresponding
    to a 16-bit VQ number seems sufficient for now.
    
    This is found using static analysis with smatch.
    
    Suggested-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Message-Id: <20221128155717.2579992-1-harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_pci: modify ENOENT to EINVAL [+ + +]
Author: Angus Chen <angus.chen@jaguarmicro.com>
Date:   Tue Nov 1 19:16:54 2022 +0800

    virtio_pci: modify ENOENT to EINVAL
    
    [ Upstream commit b66ead2d0ecac00c3a06a6218af5411cb5fcb5d5 ]
    
    Virtio_crypto use max_data_queues+1 to setup vqs,
    we use vp_modern_get_num_queues to protect the vq range in setup_vq.
    We could enter index >= vp_modern_get_num_queues(mdev) in setup_vq
    if common->num_queues is not set well,and it return -ENOENT.
    It is better to use -EINVAL instead.
    
    Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com>
    Message-Id: <20221101111655.1947-1-angus.chen@jaguarmicro.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
VMCI: Use threaded irqs instead of tasklets [+ + +]
Author: Vishnu Dasa <vdasa@vmware.com>
Date:   Tue Nov 29 23:05:11 2022 -0800

    VMCI: Use threaded irqs instead of tasklets
    
    commit 3daed6345d5880464f46adab871d208e1baa2f3a upstream.
    
    The vmci_dispatch_dgs() tasklet function calls vmci_read_data()
    which uses wait_event() resulting in invalid sleep in an atomic
    context (and therefore potentially in a deadlock).
    
    Use threaded irqs to fix this issue and completely remove usage
    of tasklets.
    
    [   20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145
    [   20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd
    [   20.264645] preempt_count: 101, expected: 0
    [   20.264646] RCU nest depth: 0, expected: 0
    [   20.264647] 1 lock held by vmtoolsd/762:
    [   20.264648]  #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock]
    [   20.264658] Preemption disabled at:
    [   20.264659] [<ffff80000151d7d8>] vmci_send_datagram+0x44/0xa0 [vmw_vmci]
    [   20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1
    [   20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020
    [   20.264668] Call trace:
    [   20.264669]  dump_backtrace+0xc4/0x130
    [   20.264672]  show_stack+0x24/0x80
    [   20.264673]  dump_stack_lvl+0x88/0xb4
    [   20.264676]  dump_stack+0x18/0x34
    [   20.264677]  __might_resched+0x1a0/0x280
    [   20.264679]  __might_sleep+0x58/0x90
    [   20.264681]  vmci_read_data+0x74/0x120 [vmw_vmci]
    [   20.264683]  vmci_dispatch_dgs+0x64/0x204 [vmw_vmci]
    [   20.264686]  tasklet_action_common.constprop.0+0x13c/0x150
    [   20.264688]  tasklet_action+0x40/0x50
    [   20.264689]  __do_softirq+0x23c/0x6b4
    [   20.264690]  __irq_exit_rcu+0x104/0x214
    [   20.264691]  irq_exit_rcu+0x1c/0x50
    [   20.264693]  el1_interrupt+0x38/0x6c
    [   20.264695]  el1h_64_irq_handler+0x18/0x24
    [   20.264696]  el1h_64_irq+0x68/0x6c
    [   20.264697]  preempt_count_sub+0xa4/0xe0
    [   20.264698]  _raw_spin_unlock_irqrestore+0x64/0xb0
    [   20.264701]  vmci_send_datagram+0x7c/0xa0 [vmw_vmci]
    [   20.264703]  vmci_datagram_dispatch+0x84/0x100 [vmw_vmci]
    [   20.264706]  vmci_datagram_send+0x2c/0x40 [vmw_vmci]
    [   20.264709]  vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport]
    [   20.264711]  vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport]
    [   20.264713]  vsock_connect+0x278/0x330 [vsock]
    [   20.264715]  __sys_connect_file+0x8c/0xc0
    [   20.264718]  __sys_connect+0x84/0xb4
    [   20.264720]  __arm64_sys_connect+0x2c/0x3c
    [   20.264721]  invoke_syscall+0x78/0x100
    [   20.264723]  el0_svc_common.constprop.0+0x68/0x124
    [   20.264724]  do_el0_svc+0x38/0x4c
    [   20.264725]  el0_svc+0x60/0x180
    [   20.264726]  el0t_64_sync_handler+0x11c/0x150
    [   20.264728]  el0t_64_sync+0x190/0x194
    
    Signed-off-by: Vishnu Dasa <vdasa@vmware.com>
    Suggested-by: Zack Rusin <zackr@vmware.com>
    Reported-by: Nadav Amit <namit@vmware.com>
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Fixes: 463713eb6164 ("VMCI: dma dg: add support for DMA datagrams receive")
    Cc: <stable@vger.kernel.org> # v5.18+
    Cc: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Bryan Tan <bryantan@vmware.com>
    Reviewed-by: Bryan Tan <bryantan@vmware.com>
    Reviewed-by: Zack Rusin <zackr@vmware.com>
    Link: https://lore.kernel.org/r/20221130070511.46558-1-vdasa@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices [+ + +]
Author: Arend van Spriel <arend.vanspriel@broadcom.com>
Date:   Wed Jan 11 12:24:19 2023 +0100

    wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices
    
    commit ed05cb177ae5cd7f02f1d6e7706ba627d30f1696 upstream.
    
    A sanity check was introduced considering maximum flowrings above
    256 as insane and effectively aborting the device probe. This
    resulted in regression for number of users as the value turns out
    to be sane after all.
    
    Fixes: 2aca4f3734bd ("brcmfmac: return error when getting invalid max_flowrings from dongle")
    Reported-by: chainofflowers <chainofflowers@posteo.net>
    Link: https://lore.kernel.org/all/4781984.GXAFRqVoOG@luna/
    Reported-by: Christian Marillat <marillat@debian.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216894
    Cc: stable@vger.kernel.org
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230111112419.24185-1-arend.vanspriel@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: iwlwifi: fw: skip PPAG for JF [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Dec 13 23:15:04 2022 +0200

    wifi: iwlwifi: fw: skip PPAG for JF
    
    [ Upstream commit 1c4c0b28b517d778d37900deedfe91088839f07a ]
    
    For JF RFs we don't support PPAG, but many firmware
    images lie about it. Always skip support for JF to
    avoid firmware errors when sending the command.
    
    Reported-and-tested-by: Íñigo Huguet <ihuguet@redhat.com>
    Link: https://lore.kernel.org/linux-wireless/CACT4oufQsqHGp6bah2c4+jPn2wG1oZqY=UKa_TmPx=F6Lxng8Q@mail.gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20221213225723.2a43415d8990.I9ac210740a45b41f1b2e15274e1daf4284f2808a@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix initialization of rx->link and rx->link_sta [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Dec 30 21:07:47 2022 +0100

    wifi: mac80211: fix initialization of rx->link and rx->link_sta
    
    commit e66b7920aa5ac5b1a1997a454004ba9246a3c005 upstream.
    
    There are some codepaths that do not initialize rx->link_sta properly. This
    causes a crash in places which assume that rx->link_sta is valid if rx->sta
    is valid.
    One known instance is triggered by __ieee80211_rx_h_amsdu being called from
    fast-rx. It results in a crash like this one:
    
     BUG: kernel NULL pointer dereference, address: 00000000000000a8
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page PGD 0 P4D 0
     Oops: 0002 [#1] PREEMPT SMP PTI
     CPU: 1 PID: 506 Comm: mt76-usb-rx phy Tainted: G            E      6.1.0-debian64x+1.7 #3
     Hardware name: ZOTAC ZBOX-ID92/ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01, BIOS B220P007 05/21/2014
     RIP: 0010:ieee80211_deliver_skb+0x62/0x1f0 [mac80211]
     Code: 00 48 89 04 24 e8 9e a7 c3 df 89 c0 48 03 1c c5 a0 ea 39 a1 4c 01 6b 08 48 ff 03 48
           83 7d 28 00 74 11 48 8b 45 30 48 63 55 44 <48> 83 84 d0 a8 00 00 00 01 41 8b 86 c0
           11 00 00 8d 50 fd 83 fa 01
     RSP: 0018:ffff999040803b10 EFLAGS: 00010286
     RAX: 0000000000000000 RBX: ffffb9903f496480 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
     RBP: ffff999040803ce0 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d21828ac900
     R13: 000000000000004a R14: ffff8d2198ed89c0 R15: ffff8d2198ed8000
     FS:  0000000000000000(0000) GS:ffff8d24afe80000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00000000000000a8 CR3: 0000000429810002 CR4: 00000000001706e0
     Call Trace:
      <TASK>
      __ieee80211_rx_h_amsdu+0x1b5/0x240 [mac80211]
      ? ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]
      ? __local_bh_enable_ip+0x3b/0xa0
      ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]
      ? prepare_transfer+0x109/0x1a0 [xhci_hcd]
      ieee80211_rx_list+0xa80/0xda0 [mac80211]
      mt76_rx_complete+0x207/0x2e0 [mt76]
      mt76_rx_poll_complete+0x357/0x5a0 [mt76]
      mt76u_rx_worker+0x4f5/0x600 [mt76_usb]
      ? mt76_get_min_avg_rssi+0x140/0x140 [mt76]
      __mt76_worker_fn+0x50/0x80 [mt76]
      kthread+0xed/0x120
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x22/0x30
    
    Since the initialization of rx->link and rx->link_sta is rather convoluted
    and duplicated in many places, clean it up by using a helper function to
    set it.
    
    Fixes: ccdde7c74ffd ("wifi: mac80211: properly implement MLO key handling")
    Fixes: b320d6c456ff ("wifi: mac80211: use correct rx link_sta instead of default")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20221230200747.19040-1-nbd@nbd.name
    [remove unnecessary rx->sta->sta.mlo check]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: mac80211: fix MLO + AP_VLAN check [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Wed Dec 14 14:03:26 2022 +0100

    wifi: mac80211: fix MLO + AP_VLAN check
    
    commit f216033d770f7ca0eda491fe01a9f02e7af59576 upstream.
    
    Instead of preventing adding AP_VLAN to MLO enabled APs, this check was
    preventing adding more than one 4-addr AP_VLAN regardless of the MLO status.
    Fix this by adding missing extra checks.
    
    Fixes: ae960ee90bb1 ("wifi: mac80211: prevent VLANs on MLDs")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20221214130326.37756-1-nbd@nbd.name
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: mac80211: reset multiple BSSID options in stop_ap() [+ + +]
Author: Aloka Dixit <quic_alokad@quicinc.com>
Date:   Wed Dec 21 10:56:16 2022 -0800

    wifi: mac80211: reset multiple BSSID options in stop_ap()
    
    commit 0eb38842ada035d71bb06fb9116f26f24ee0f998 upstream.
    
    Reset multiple BSSID options when all AP related configurations are
    reset in ieee80211_stop_ap().
    
    Stale values result in HWSIM test failures (e.g. p2p_group_cli_invalid),
    if run after 'he_ap_ema'.
    
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
    Link: https://lore.kernel.org/r/20221221185616.11514-1-quic_alokad@quicinc.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: mac80211: sdata can be NULL during AMPDU start [+ + +]
Author: Alexander Wetzel <alexander@wetzel-home.de>
Date:   Fri Dec 30 13:18:50 2022 +0100

    wifi: mac80211: sdata can be NULL during AMPDU start
    
    commit 69403bad97aa0162e3d7911b27e25abe774093df upstream.
    
    ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
    deauthentication is ongoing.
    
    Here a trace triggering the race with the hostapd test
    multi_ap_fronthaul_on_ap:
    
    (gdb) list *drv_ampdu_action+0x46
    0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
    391             int ret = -EOPNOTSUPP;
    392
    393             might_sleep();
    394
    395             sdata = get_bss_sdata(sdata);
    396             if (!check_sdata_in_driver(sdata))
    397                     return -EIO;
    398
    399             trace_drv_ampdu_action(local, sdata, params);
    400
    
    wlan0: moving STA 02:00:00:00:03:00 to state 3
    wlan0: associated
    wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
    wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
    wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
    wlan0: moving STA 02:00:00:00:03:00 to state 2
    wlan0: moving STA 02:00:00:00:03:00 to state 1
    wlan0: Removed STA 02:00:00:00:03:00
    wlan0: Destroyed STA 02:00:00:00:03:00
    BUG: unable to handle page fault for address: fffffffffffffb48
    PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G        W          6.1.0-rc8-wt+ #59
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
    Workqueue: phy3 ieee80211_ba_session_work [mac80211]
    RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
    Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
    RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
    RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
    RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
    RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
    R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
    R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
    FS:  0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
    Call Trace:
     <TASK>
     ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]
     ieee80211_ba_session_work+0xff/0x2e0 [mac80211]
     process_one_work+0x29f/0x620
     worker_thread+0x4d/0x3d0
     ? process_one_work+0x620/0x620
     kthread+0xfb/0x120
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x22/0x30
     </TASK>
    
    Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
    Link: https://lore.kernel.org/r/20221230121850.218810-2-alexander@wetzel-home.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/asm: Fix an assembler warning with current binutils [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 3 10:24:11 2023 -0500

    x86/asm: Fix an assembler warning with current binutils
    
    [ Upstream commit 55d235361fccef573990dfa5724ab453866e7816 ]
    
    Fix a warning: "found `movsd'; assuming `movsl' was meant"
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN [+ + +]
Author: YingChi Long <me@inclyc.cn>
Date:   Fri Nov 18 08:55:35 2022 +0800

    x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN
    
    commit 55228db2697c09abddcb9487c3d9fa5854a932cd upstream.
    
    WG14 N2350 specifies that it is an undefined behavior to have type
    definitions within offsetof", see
    
      https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
    
    This specification is also part of C23.
    
    Therefore, replace the TYPE_ALIGN macro with the _Alignof builtin to
    avoid undefined behavior. (_Alignof itself is C11 and the kernel is
    built with -gnu11).
    
    ISO C11 _Alignof is subtly different from the GNU C extension
    __alignof__. Latter is the preferred alignment and _Alignof the
    minimal alignment. For long long on x86 these are 8 and 4
    respectively.
    
    The macro TYPE_ALIGN's behavior matches _Alignof rather than
    __alignof__.
    
      [ bp: Massage commit message. ]
    
    Signed-off-by: YingChi Long <me@inclyc.cn>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20220925153151.2467884-1-me@inclyc.cn
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci-pci: set the dma max_seg_size [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Jan 16 16:22:10 2023 +0200

    xhci-pci: set the dma max_seg_size
    
    commit 93915a4170e9defd56a767a18e6c4076f3d18609 upstream.
    
    Allow devices to have dma operations beyond 64K, and avoid warnings such
    as:
    
    xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536]
    
    Cc: stable@vger.kernel.org
    Cc: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci: Add a flag to disable USB3 lpm on a xhci root port level. [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:14 2023 +0200

    xhci: Add a flag to disable USB3 lpm on a xhci root port level.
    
    commit 0522b9a1653048440da5f21747f21e498b9220d1 upstream.
    
    One USB3 roothub port may support link power management, while another
    root port on the same xHC can't due to different retimers used for
    the ports.
    
    This is the case with Intel Alder Lake, and possible future platforms
    where retimers used for USB4 ports cause too long exit latecy to
    enable native USB3 lpm U1 and U2 states.
    
    Add a flag in the xhci port structure to indicate if the port is
    lpm_incapable, and check it while calculating exit latency.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Add update_hub_device override for PCI xHCI hosts [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:13 2023 +0200

    xhci: Add update_hub_device override for PCI xHCI hosts
    
    commit 23a3b8d5a2365653fd9bc5a9454d1e7f4facbf85 upstream.
    
    Allow PCI hosts to check and tune roothub and port settings
    before the hub is up and running.
    
    This override is needed to turn off U1 and U2 LPM for some ports
    based on per port ACPI _DSM, _UPC, or possibly vendor specific mmio
    values for Intel xHC hosts.
    
    Usb core calls the host update_hub_device once it creates a hub.
    
    Entering U1 or U2 link power save state on ports with this limitation
    will cause link to fail, turning the usb device unusable in that setup.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:16 2023 +0200

    xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables
    
    commit 74622f0a81d0c2bcfc39f9192b788124e8c7f0af upstream.
    
    USB3 ports on xHC hosts may have retimers that cause too long
    exit latency to work with native USB3 U1/U2 link power management states.
    
    For now only use usb_acpi_port_lpm_incapable() to evaluate if port lpm
    should be disabled while setting up the USB3 roothub.
    
    Other ways to identify lpm incapable ports can be added here later if
    ACPI _DSM does not exist.
    
    Limit this to Intel hosts for now, this is to my knowledge only
    an Intel issue.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-8-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Fix null pointer dereference when host dies [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:12 2023 +0200

    xhci: Fix null pointer dereference when host dies
    
    commit a2bc47c43e70cf904b1af49f76d572326c08bca7 upstream.
    
    Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
    and cause null pointer dereference when host suddenly dies.
    
    Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]
    virt device at the same time that xhci_kill_endpoint_urbs() tries to
    loop through all the device's endpoints, checking if there are any
    cancelled urbs left to give back.
    
    hold the xhci spinlock while freeing the virt device
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
zonefs: Detect append writes at invalid locations [+ + +]
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Fri Jan 6 17:43:06 2023 +0900

    zonefs: Detect append writes at invalid locations
    
    commit a608da3bd730d718f2d3ebec1c26f9865f8f17ce upstream.
    
    Using REQ_OP_ZONE_APPEND operations for synchronous writes to sequential
    files succeeds regardless of the zone write pointer position, as long as
    the target zone is not full. This means that if an external (buggy)
    application writes to the zone of a sequential file underneath the file
    system, subsequent file write() operation will succeed but the file size
    will not be correct and the file will contain invalid data written by
    another application.
    
    Modify zonefs_file_dio_append() to check the written sector of an append
    write (returned in bio->bi_iter.bi_sector) and return -EIO if there is a
    mismatch with the file zone wp offset field. This change triggers a call
    to zonefs_io_error() and a zone check. Modify zonefs_io_error_cb() to
    not expose the unexpected data after the current inode size when the
    errors=remount-ro mode is used. Other error modes are correctly handled
    already.
    
    Fixes: 02ef12a663c7 ("zonefs: use REQ_OP_ZONE_APPEND for sync DIO")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>