Linux 5.10.180

 
ACPI: processor: Fix evaluating _PDC method when running as Xen dom0 [+ + +]
Author: Roger Pau Monne <[email protected]>
Date:   Wed Mar 22 12:13:29 2023 +0100

    ACPI: processor: Fix evaluating _PDC method when running as Xen dom0
    
    [ Upstream commit 073828e954459b883f23e53999d31e4c55ab9654 ]
    
    In ACPI systems, the OS can direct power management, as opposed to the
    firmware.  This OS-directed Power Management is called OSPM.  Part of
    telling the firmware that the OS going to direct power management is
    making ACPI "_PDC" (Processor Driver Capabilities) calls.  These _PDC
    methods must be evaluated for every processor object.  If these _PDC
    calls are not completed for every processor it can lead to
    inconsistency and later failures in things like the CPU frequency
    driver.
    
    In a Xen system, the dom0 kernel is responsible for system-wide power
    management.  The dom0 kernel is in charge of OSPM.  However, the
    number of CPUs available to dom0 can be different than the number of
    CPUs physically present on the system.
    
    This leads to a problem: the dom0 kernel needs to evaluate _PDC for
    all the processors, but it can't always see them.
    
    In dom0 kernels, ignore the existing ACPI method for determining if a
    processor is physically present because it might not be accurate.
    Instead, ask the hypervisor for this information.
    
    Fix this by introducing a custom function to use when running as Xen
    dom0 in order to check whether a processor object matches a CPU that's
    online.  Such checking is done using the existing information fetched
    by the Xen pCPU subsystem, extending it to also store the ACPI ID.
    
    This ensures that _PDC method gets evaluated for all physically online
    CPUs, regardless of the number of CPUs made available to dom0.
    
    Fixes: 5d554a7bb064 ("ACPI: processor: add internal processor_physically_present()")
    Signed-off-by: Roger Pau Monné <[email protected]>
    Reviewed-by: Juergen Gross <[email protected]>
    Signed-off-by: Rafael J. Wysocki <ra[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_packet: Don't send zero-byte data in packet_sendmsg_spkt(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Mon May 1 13:28:57 2023 -0700

    af_packet: Don't send zero-byte data in packet_sendmsg_spkt().
    
    [ Upstream commit 6a341729fb31b4c5df9f74f24b4b1c98410c9b87 ]
    
    syzkaller reported a warning below [0].
    
    We can reproduce it by sending 0-byte data from the (AF_PACKET,
    SOCK_PACKET) socket via some devices whose dev->hard_header_len
    is 0.
    
        struct sockaddr_pkt addr = {
            .spkt_family = AF_PACKET,
            .spkt_device = "tun0",
        };
        int fd;
    
        fd = socket(AF_PACKET, SOCK_PACKET, 0);
        sendto(fd, NULL, 0, 0, (struct sockaddr *)&addr, sizeof(addr));
    
    We have a similar fix for the (AF_PACKET, SOCK_RAW) socket as
    commit dc633700f00f ("net/af_packet: check len when min_header_len
    equals to 0").
    
    Let's add the same test for the SOCK_PACKET socket.
    
    [0]:
    skb_assert_len
    WARNING: CPU: 1 PID: 19945 at include/linux/skbuff.h:2552 skb_assert_len include/linux/skbuff.h:2552 [inline]
    WARNING: CPU: 1 PID: 19945 at include/linux/skbuff.h:2552 __dev_queue_xmit+0x1f26/0x31d0 net/core/dev.c:4159
    Modules linked in:
    CPU: 1 PID: 19945 Comm: syz-executor.0 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:skb_assert_len include/linux/skbuff.h:2552 [inline]
    RIP: 0010:__dev_queue_xmit+0x1f26/0x31d0 net/core/dev.c:4159
    Code: 89 de e8 1d a2 85 fd 84 db 75 21 e8 64 a9 85 fd 48 c7 c6 80 2a 1f 86 48 c7 c7 c0 06 1f 86 c6 05 23 cf 27 04 01 e8 fa ee 56 fd <0f> 0b e8 43 a9 85 fd 0f b6 1d 0f cf 27 04 31 ff 89 de e8 e3 a1 85
    RSP: 0018:ffff8880217af6e0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90001133000
    RDX: 0000000000040000 RSI: ffffffff81186922 RDI: 0000000000000001
    RBP: ffff8880217af8b0 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: ffff888030045640
    R13: ffff8880300456b0 R14: ffff888030045650 R15: ffff888030045718
    FS:  00007fc5864da640(0000) GS:ffff88806cd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020005740 CR3: 000000003f856003 CR4: 0000000000770ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     dev_queue_xmit include/linux/netdevice.h:3085 [inline]
     packet_sendmsg_spkt+0xc4b/0x1230 net/packet/af_packet.c:2066
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg+0x1b4/0x200 net/socket.c:747
     ____sys_sendmsg+0x331/0x970 net/socket.c:2503
     ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2557
     __sys_sendmmsg+0x18c/0x430 net/socket.c:2643
     __do_sys_sendmmsg net/socket.c:2672 [inline]
     __se_sys_sendmmsg net/socket.c:2669 [inline]
     __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2669
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x7fc58791de5d
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
    RSP: 002b:00007fc5864d9cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
    RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007fc58791de5d
    RDX: 0000000000000001 RSI: 0000000020005740 RDI: 0000000000000004
    RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fc58797e530 R15: 0000000000000000
     </TASK>
    ---[ end trace 0000000000000000 ]---
    skb len=0 headroom=16 headlen=0 tailroom=304
    mac=(16,0) net=(16,-1) trans=-1
    shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
    csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
    hash(0x0 sw=0 l4=0) proto=0x0000 pkttype=0 iif=0
    dev name=sit0 feat=0x00000006401d7869
    sk family=17 type=10 proto=0
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
afs: Fix updating of i_size with dv jump from server [+ + +]
Author: Marc Dionne <[email protected]>
Date:   Fri Dec 2 10:07:01 2022 -0400

    afs: Fix updating of i_size with dv jump from server
    
    [ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]
    
    If the data version returned from the server is larger than expected,
    the local data is invalidated, but we may still want to note the remote
    file size.
    
    Since we're setting change_size, we have to also set data_changed
    for the i_size to get updated.
    
    Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
    Signed-off-by: Marc Dionne <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: caiaq: input: Add error handling for unsupported input methods in `snd_usb_caiaq_input_init` [+ + +]
Author: Ruliang Lin <[email protected]>
Date:   Thu May 4 14:50:53 2023 +0800

    ALSA: caiaq: input: Add error handling for unsupported input methods in `snd_usb_caiaq_input_init`
    
    [ Upstream commit 0d727e1856ef22dd9337199430258cb64cbbc658 ]
    
    Smatch complains that:
    snd_usb_caiaq_input_init() warn: missing error code 'ret'
    
    This patch adds a new case to handle the situation where the
    device does not support any input methods in the
    `snd_usb_caiaq_input_init` function. It returns an `-EINVAL` error code
    to indicate that no input methods are supported on the device.
    
    Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support")
    Signed-off-by: Ruliang Lin <[email protected]>
    Reviewed-by: Dongliang Mu <[email protected]>
    Acked-by: Daniel Mack <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: Always load shadow stack pointer directly from the task struct [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Mon Jan 9 18:47:59 2023 +0100

    arm64: Always load shadow stack pointer directly from the task struct
    
    commit 2198d07c509f1db4a1185d1f65aaada794c6ea59 upstream.
    
    All occurrences of the scs_load macro load the value of the shadow call
    stack pointer from the task which is current at that point. So instead
    of taking a task struct register argument in the scs_load macro to
    specify the task struct to load from, let's always reference the current
    task directly. This should make it much harder to exploit any
    instruction sequences reloading the shadow call stack pointer register
    from memory.
    
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Catalin Marinas <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: ipq8074: Fix the PCI I/O port range [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Feb 28 22:17:41 2023 +0530

    arm64: dts: qcom: ipq8074: Fix the PCI I/O port range
    
    [ Upstream commit e49eafefe5ab325e38dd074f2005076ffc271e54 ]
    
    For 64KiB of the I/O region, the I/O ports of the legacy PCI devices are
    located in the range of 0x0 to 0x10000. Hence, fix the bogus PCI addresses
    (0x10200000, 0x20200000) specified in the ranges property for I/O region.
    
    While at it, let's use the missing 0x prefix for the addresses and align
    them in a single line.
    
    Fixes: 33057e1672fe ("ARM: dts: ipq8074: Add pcie nodes")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/linux-arm-msm/[email protected]/
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: msm8996: Fix the PCI I/O port range [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Feb 28 22:17:43 2023 +0530

    arm64: dts: qcom: msm8996: Fix the PCI I/O port range
    
    [ Upstream commit cf0ac10feb17661987d0018eb9475dc03e2a2253 ]
    
    For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
    located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
    (0x0c200000, 0x0d200000, 0x0e200000) specified in the ranges property for
    I/O region.
    
    While at it, let's also align the entries.
    
    Fixes: ed965ef89227 ("arm64: dts: qcom: msm8996: add support to pcie")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/linux-arm-msm/[email protected]/
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: msm8998: Fix stm-stimulus-base reg name [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Feb 13 22:03:31 2023 +0100

    arm64: dts: qcom: msm8998: Fix stm-stimulus-base reg name
    
    [ Upstream commit b5d08f08377218b1d2ab4026e427a7788b271c8e ]
    
    The name stm-data-base comes from ancient (msm-3.10 or older)
    downstream kernels. Upstream uses stm-stimulus-base instead. Fix it.
    
    Fixes: 783abfa2249a ("arm64: dts: qcom: msm8998: Add Coresight support")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: msm8998: Fix the PCI I/O port range [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Feb 28 22:17:38 2023 +0530

    arm64: dts: qcom: msm8998: Fix the PCI I/O port range
    
    [ Upstream commit c30a27dcfe4545edbda1578b3a63ed6147519cdd ]
    
    For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
    located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI address
    (0x1b200000) specified in the ranges property for I/O region.
    
    Fixes: b84dfd175c09 ("arm64: dts: qcom: msm8998: Add PCIe PHY and RC nodes")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/linux-arm-msm/[email protected]/
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/20230228164752.55682-3-manivannan.sa[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sdm845: correct dynamic power coefficients [+ + +]
Author: Vincent Guittot <[email protected]>
Date:   Fri Jan 6 17:46:18 2023 +0100

    arm64: dts: qcom: sdm845: correct dynamic power coefficients
    
    commit 44750f153699b6e4f851a399287e5c8df208d696 upstream.
    
    While stressing EAS on my dragonboard RB3, I have noticed that LITTLE cores
    where never selected as the most energy efficient CPU whatever the
    utilization level of waking task.
    
    energy model framework uses its cost field to estimate the energy with
    the formula:
    
      nrg = cost of the selected OPP * utilization / CPU's max capacity
    
    which ends up selecting the CPU with lowest cost / max capacity ration
    as long as the utilization fits in the OPP's capacity.
    
    If we compare the cost of a little OPP with similar capacity of a big OPP
    like :
           OPP(kHz)   OPP capacity    cost     max capacity   cost/max capacity
    LITTLE 1766400    407             351114   407            863
    big    1056000    408             520267   1024           508
    
    This can be interpreted as the LITTLE core consumes 70% more than big core
    for the same compute capacity.
    
    According to [1], LITTLE consumes 10% less than big core for Coremark
    benchmark at those OPPs. If we consider that everything else stays
    unchanged, the dynamic-power-coefficient of LITTLE core should be
    only 53% of the current value: 290 * 53% = 154
    
    Set the dynamic-power-coefficient of CPU0-3 to 154 to fix the energy model.
    
    [1] https://github.com/kdrag0n/freqbench/tree/master/results/sdm845/main
    
    Fixes: 0e0a8e35d725 ("arm64: dts: qcom: sdm845: correct dynamic power coefficients")
    Signed-off-by: Vincent Guittot <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: sdm845: correct dynamic power coefficients [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Tue Mar 15 17:11:04 2022 +0300

    arm64: dts: qcom: sdm845: correct dynamic power coefficients
    
    [ Upstream commit 0e0a8e35d72533b3eef3365e900baacd7cede8e2 ]
    
    Following sm8150/sm8250 update sdm845 capacity-dmips-mhz and
    dynamic-power-coefficient based on the measurements [1], [2].
    
    The energy model dynamic-power-coefficient values were calculated with
        DPC = µW / MHz / V^2
    for each OPP, and averaged across all OPPs within each cluster for the
    final coefficient. Voltages were obtained from the qcom-cpufreq-hw
    driver that reads voltages from the OSM LUT programmed into the SoC.
    
    Normalized DMIPS/MHz capacity scale values for each CPU were calculated
    from CoreMarks/MHz (CoreMark iterations per second per MHz), which
    serves the same purpose. For each CPU, the final capacity-dmips-mhz
    value is the C/MHz value of its maximum frequency normalized to
    SCHED_CAPACITY_SCALE (1024) for the fastest CPU in the system.
    
    For more details on measurement process see the commit message for the
    commit 6aabed5526ee ("arm64: dts: qcom: sm8250: Add CPU capacities and
    energy model").
    
    [1] https://github.com/kdrag0n/freqbench
    [2] https://github.com/kdrag0n/freqbench/tree/master/results/sdm845/main
    
    Cc: Danny Lin <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sdm845: Fix the PCI I/O port range [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Feb 28 22:17:37 2023 +0530

    arm64: dts: qcom: sdm845: Fix the PCI I/O port range
    
    [ Upstream commit 67aa109eee654c76dcc100554e637fa64d5aa099 ]
    
    For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
    located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
    (0x60200000, 0x40200000) specified in the ranges property for I/O region.
    
    While at it, let's use the missing 0x prefix for the addresses.
    
    Fixes: 42ad231338c1 ("arm64: dts: qcom: sdm845: Add second PCIe PHY and controller")
    Fixes: 5c538e09cb19 ("arm64: dts: qcom: sdm845: Add first PCIe controller and PHY")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/linux-arm-msm/[email protected]/
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r8a774c0: Remove bogus voltages from OPP table [+ + +]
Author: Geert Uytterhoeven <geert+rene[email protected]>
Date:   Thu Feb 16 16:30:32 2023 +0100

    arm64: dts: renesas: r8a774c0: Remove bogus voltages from OPP table
    
    [ Upstream commit 554edc3e9239bb81e61be9f0f5dbbeb528a69e72 ]
    
    According to the RZ/G Series, 2nd Generation Hardware User’s Manual
    Rev. 1.11, the System CPU cores on RZ/G2E do not have their own power
    supply, but use the common internal power supply (typical 1.03V).
    
    Hence remove the "opp-microvolt" properties from the Operating
    Performance Points table.  They are optional, and unused, when none of
    the CPU nodes is tied to a regulator using the "cpu-supply" property.
    
    Fixes: 231d8908a66fa98f ("arm64: dts: renesas: r8a774c0: Add OPPs table for cpu devices")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/8348e18a011ded94e35919cd8e17c0be1f9acf2f.1676560856.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r8a77990: Remove bogus voltages from OPP table [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Feb 16 16:30:31 2023 +0100

    arm64: dts: renesas: r8a77990: Remove bogus voltages from OPP table
    
    [ Upstream commit fb76b0fae3ca880363214e1dcd6513ab8bd529e7 ]
    
    According to the R-Car Series, 3rd Generation Hardware User’s Manual
    Rev. 2.30, the System CPU cores on R-Car E3 do not have their own power
    supply, but use the common internal power supply (typical 1.03V).
    
    Hence remove the "opp-microvolt" properties from the Operating
    Performance Points table.  They are optional, and unused, when none of
    the CPU nodes is tied to a regulator using the "cpu-supply" property.
    
    Fixes: dd7188eb4ed128dc ("arm64: dts: renesas: r8a77990: Add OPPs table for cpu devices")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/9232578d9d395d529f64db3333a371e31327f459.1676560856.git.geert+[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step [+ + +]
Author: Sumit Garg <[email protected]>
Date:   Thu Feb 2 13:01:48 2023 +0530

    arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step
    
    [ Upstream commit af6c0bd59f4f3ad5daad2f7b777954b1954551d5 ]
    
    Currently only the first attempt to single-step has any effect. After
    that all further stepping remains "stuck" at the same program counter
    value.
    
    Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12,
    PSTATE.SS=1 should be set at each step before transferring the PE to the
    'Active-not-pending' state. The problem here is PSTATE.SS=1 is not set
    since the second single-step.
    
    After the first single-step, the PE transferes to the 'Inactive' state,
    with PSTATE.SS=0 and MDSCR.SS=1, thus PSTATE.SS won't be set to 1 due to
    kernel_active_single_step()=true. Then the PE transferes to the
    'Active-pending' state when ERET and returns to the debugger by step
    exception.
    
    Before this patch:
    ==================
    Entering kdb (current=0xffff3376039f0000, pid 1) on processor 0 due to Keyboard Entry
    [0]kdb>
    
    [0]kdb>
    [0]kdb> bp write_sysrq_trigger
    Instruction(i) BP #0 at 0xffffa45c13d09290 (write_sysrq_trigger)
        is enabled   addr at ffffa45c13d09290, hardtype=0 installed=0
    
    [0]kdb> go
    $ echo h > /proc/sysrq-trigger
    
    Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to Breakpoint @ 0xffffad651a309290
    [1]kdb> ss
    
    Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
    [1]kdb> ss
    
    Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
    [1]kdb>
    
    After this patch:
    =================
    Entering kdb (current=0xffff6851c39f0000, pid 1) on processor 0 due to Keyboard Entry
    [0]kdb> bp write_sysrq_trigger
    Instruction(i) BP #0 at 0xffffc02d2dd09290 (write_sysrq_trigger)
        is enabled   addr at ffffc02d2dd09290, hardtype=0 installed=0
    
    [0]kdb> go
    $ echo h > /proc/sysrq-trigger
    
    Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to Breakpoint @ 0xffffc02d2dd09290
    [1]kdb> ss
    
    Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09294
    [1]kdb> ss
    
    Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09298
    [1]kdb> ss
    
    Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd0929c
    [1]kdb>
    
    Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support")
    Co-developed-by: Wei Li <[email protected]>
    Signed-off-by: Wei Li <[email protected]>
    Signed-off-by: Sumit Garg <[email protected]>
    Tested-by: Douglas Anderson <[email protected]>
    Acked-by: Daniel Thompson <[email protected]>
    Tested-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: Stash shadow stack pointer in the task struct on interrupt [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Mon Jan 9 18:48:00 2023 +0100

    arm64: Stash shadow stack pointer in the task struct on interrupt
    
    commit 59b37fe52f49955791a460752c37145f1afdcad1 upstream.
    
    Instead of reloading the shadow call stack pointer from the ordinary
    stack, which may be vulnerable to the kind of gadget based attacks
    shadow call stacks were designed to prevent, let's store a task's shadow
    call stack pointer in the task struct when switching to the shadow IRQ
    stack.
    
    Given that currently, the task_struct::scs_sp field is only used to
    preserve the shadow call stack pointer while a task is scheduled out or
    running in user space, reusing this field to preserve and restore it
    while running off the IRQ stack must be safe, as those occurrences are
    guaranteed to never overlap. (The stack switching logic only switches
    stacks when running from the task stack, and so the value being saved
    here always corresponds to the task mode shadow stack)
    
    While at it, fold a mov/add/mov sequence into a single add.
    
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Catalin Marinas <[email protected]>
    [ardb: v5.10 backport, which doesn't have call_on_irq_stack() yet *]
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ARM: dts: exynos: fix WM8960 clock name in Itop Elite [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Feb 17 16:06:27 2023 +0100

    ARM: dts: exynos: fix WM8960 clock name in Itop Elite
    
    commit 6c950c20da38debf1ed531e0b972bd8b53d1c11f upstream.
    
    The WM8960 Linux driver expects the clock to be named "mclk".  Otherwise
    the clock will be ignored and not prepared/enabled by the driver.
    
    Cc: <[email protected]>
    Fixes: 339b2fb36a67 ("ARM: dts: exynos: Add TOPEET itop elite based board")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ARM: dts: gta04: fix excess dma channel usage [+ + +]
Author: H. Nikolaus Schaller <[email protected]>
Date:   Fri Jan 13 22:11:51 2023 +0100

    ARM: dts: gta04: fix excess dma channel usage
    
    [ Upstream commit a622310f7f0185da02e42cdb06475f533efaae60 ]
    
    OMAP processors support 32 channels but there is no check or
    inspect this except booting a device and looking at dmesg reports
    of not available channels.
    
    Recently some more subsystems with DMA (aes1+2) were added filling
    the list of dma channels beyond the limit of 32 (even if other
    parameters indicate 96 or 128 channels). This leads to random
    subsystem failures i(e.g. mcbsp for audio) after boot or boot
    messages that DMA can not be initialized.
    
    Another symptom is that
    
    /sys/kernel/debug/dmaengine/summary
    
    has 32 entries and does not show all required channels.
    
    Fix by disabling unused (on the GTA04 hardware) mcspi1...4.
    Each SPI channel allocates 4 DMA channels rapidly filling
    the available ones.
    
    Disabling unused SPI modules on the OMAP3 SoC may also save
    some energy (has not been checked).
    
    Fixes: c312f066314e ("ARM: dts: omap3: Migrate AES from hwmods to sysc-omap2")
    Signed-off-by: H. Nikolaus Schaller <[email protected]>
    [re-enabled aes2, improved commit subject line]
    Signed-off-by: Andreas Kemnade <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: qcom: ipq4019: Fix the PCI I/O port range [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Feb 28 22:17:51 2023 +0530

    ARM: dts: qcom: ipq4019: Fix the PCI I/O port range
    
    [ Upstream commit 2540279e9a9e74fc880d1e4c83754ecfcbe290a0 ]
    
    For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
    located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI address
    (0x40200000) specified in the ranges property for I/O region.
    
    While at it, let's use the missing 0x prefix for the addresses.
    
    Fixes: 187519403273 ("ARM: dts: ipq4019: Add a few peripheral nodes")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/linux-arm-msm/[email protected]/
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: qcom: ipq8064: Fix the PCI I/O port range [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Feb 28 22:17:52 2023 +0530

    ARM: dts: qcom: ipq8064: Fix the PCI I/O port range
    
    [ Upstream commit 0b16b34e491629016109e56747ad64588074194b ]
    
    For 64KiB of the I/O region, the I/O ports of the legacy PCI devices are
    located in the range of 0x0 to 0x10000. Hence, fix the bogus PCI addresses
    (0x0fe00000, 0x31e00000, 0x35e00000) specified in the ranges property for
    I/O region.
    
    While at it, let's use the missing 0x prefix for the addresses.
    
    Fixes: 93241840b664 ("ARM: dts: qcom: Add pcie nodes for ipq8064")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/linux-arm-msm/[email protected]/
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Bjorn Andersson <anders[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: qcom: ipq8064: reduce pci IO size to 64K [+ + +]
Author: Christian Marangi <[email protected]>
Date:   Thu Jul 7 03:09:40 2022 +0200

    ARM: dts: qcom: ipq8064: reduce pci IO size to 64K
    
    [ Upstream commit 8fafb7e5c041814876266259e5e439f93571dcef ]
    
    The current value for pci IO is problematic for ath10k wifi card
    commonly connected to ipq8064 SoC.
    The current value is probably a typo and is actually uncommon to find
    1MB IO space even on a x86 arch. Also with recent changes to the pci
    driver, pci1 and pci2 now fails to function as any connected device
    fails any reg read/write. Reduce this to 64K as it should be more than
    enough and 3 * 64K of total IO space doesn't exceed the IO_SPACE_LIMIT
    hardcoded for the ARM arch.
    
    Signed-off-by: Christian Marangi <[email protected]>
    Tested-by: Jonathan McDowell <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 0b16b34e4916 ("ARM: dts: qcom: ipq8064: Fix the PCI I/O port range")
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: s5pv210: correct MIPI CSIS clock name [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Feb 12 19:58:18 2023 +0100

    ARM: dts: s5pv210: correct MIPI CSIS clock name
    
    commit 665b9459bb53b8f19bd1541567e1fe9782c83c4b upstream.
    
    The Samsung S5P/Exynos MIPI CSIS bindings and Linux driver expect first
    clock name to be "csis".  Otherwise the driver fails to probe.
    
    Fixes: 94ad0f6d9278 ("ARM: dts: Add Device tree for s5pv210 SoC")
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
asm-generic/io.h: suppress endianness warnings for readq() and writeq() [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Mon Jan 9 15:11:52 2023 +0200

    asm-generic/io.h: suppress endianness warnings for readq() and writeq()
    
    [ Upstream commit d564fa1ff19e893e2971d66e5c8f49dc1cdc8ffc ]
    
    Commit c1d55d50139b ("asm-generic/io.h: Fix sparse warnings on
    big-endian architectures") missed fixing the 64-bit accessors.
    
    Arnd explains in the attached link why the casts are necessary, even if
    __raw_readq() and __raw_writeq() do not take endian-specific types.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Suggested-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: es8316: Handle optional IRQ assignment [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Mar 28 12:49:01 2023 +0300

    ASoC: es8316: Handle optional IRQ assignment
    
    [ Upstream commit 39db65a0a17b54915b269d3685f253a4731f344c ]
    
    The driver is able to work fine without relying on a mandatory interrupt
    being assigned to the I2C device. This is only needed when making use of
    the jack-detect support.
    
    However, the following warning message is always emitted when there is
    no such interrupt available:
    
      es8316 0-0011: Failed to get IRQ 0: -22
    
    Do not attempt to request an IRQ if it is not available/valid. This also
    ensures the rather misleading message is not displayed anymore.
    
    Also note the IRQ validation relies on commit dab472eb931bc291 ("i2c /
    ACPI: Use 0 to indicate that device does not have interrupt assigned").
    
    Fixes: 822257661031 ("ASoC: es8316: Add jack-detect support")
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: es8316: Use IRQF_NO_AUTOEN when requesting the IRQ [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sun Oct 3 15:22:54 2021 +0200

    ASoC: es8316: Use IRQF_NO_AUTOEN when requesting the IRQ
    
    [ Upstream commit 1cf2aa665901054b140eb71748661ceae99b6b5a ]
    
    Use the new IRQF_NO_AUTOEN flag when requesting the IRQ, rather then
    disabling it immediately after requesting it.
    
    This fixes a possible race where the IRQ might trigger between requesting
    and disabling it; and this also leads to a small code cleanup.
    
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 39db65a0a17b ("ASoC: es8316: Handle optional IRQ assignment")
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: fsl_mqs: move of_node_put() to the correct location [+ + +]
Author: Liliang Ye <[email protected]>
Date:   Mon Apr 3 23:26:47 2023 +0800

    ASoC: fsl_mqs: move of_node_put() to the correct location
    
    [ Upstream commit 1c34890273a020d61d6127ade3f68ed1cb21c16a ]
    
    of_node_put() should have been done directly after
    mqs_priv->regmap = syscon_node_to_regmap(gpr_np);
    otherwise it creates a reference leak on the success path.
    
    To fix this, of_node_put() is moved to the correct location, and change
    all the gotos to direct returns.
    
    Fixes: a9d273671440 ("ASoC: fsl_mqs: Fix error handling in probe")
    Signed-off-by: Liliang Ye <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: bytcr_rt5640: Add quirk for the Acer Iconia One 7 B1-750 [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Mar 22 15:53:32 2023 +0100

    ASoC: Intel: bytcr_rt5640: Add quirk for the Acer Iconia One 7 B1-750
    
    [ Upstream commit e38c5e80c3d293a883c6f1d553f2146ec0bda35e ]
    
    The Acer Iconia One 7 B1-750 tablet mostly works fine with the defaults
    for an Bay Trail CR tablet. Except for the internal mic, instead of
    an analog mic on IN3 a digital mic on DMIC1 is uses.
    
    Add a quirk with these settings for this tablet.
    
    Acked-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
blk-crypto: make blk_crypto_evict_key() more robust [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Wed May 3 21:09:41 2023 -0700

    blk-crypto: make blk_crypto_evict_key() more robust
    
    commit 5c7cb94452901a93e90c2230632e2c12a681bc92 upstream.
    
    If blk_crypto_evict_key() sees that the key is still in-use (due to a
    bug) or that ->keyslot_evict failed, it currently just returns while
    leaving the key linked into the keyslot management structures.
    
    However, blk_crypto_evict_key() is only called in contexts such as inode
    eviction where failure is not an option.  So actually the caller
    proceeds with freeing the blk_crypto_key regardless of the return value
    of blk_crypto_evict_key().
    
    These two assumptions don't match, and the result is that there can be a
    use-after-free in blk_crypto_reprogram_all_keys() after one of these
    errors occurs.  (Note, these errors *shouldn't* happen; we're just
    talking about what happens if they do anyway.)
    
    Fix this by making blk_crypto_evict_key() unlink the key from the
    keyslot management structures even on failure.
    
    Also improve some comments.
    
    Fixes: 1b2628397058 ("block: Keyslot Manager for Inline Encryption")
    Cc: [email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

blk-crypto: make blk_crypto_evict_key() return void [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Wed May 3 21:09:40 2023 -0700

    blk-crypto: make blk_crypto_evict_key() return void
    
    commit 70493a63ba04f754f7a7dd53a4fcc82700181490 upstream.
    
    blk_crypto_evict_key() is only called in contexts such as inode eviction
    where failure is not an option.  So there is nothing the caller can do
    with errors except log them.  (dm-table.c does "use" the error code, but
    only to pass on to upper layers, so it doesn't really count.)
    
    Just make blk_crypto_evict_key() return void and log errors itself.
    
    Cc: [email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
blk-mq: release crypto keyslot before reporting I/O complete [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Wed May 3 21:09:39 2023 -0700

    blk-mq: release crypto keyslot before reporting I/O complete
    
    commit 9cd1e566676bbcb8a126acd921e4e194e6339603 upstream.
    
    Once all I/O using a blk_crypto_key has completed, filesystems can call
    blk_crypto_evict_key().  However, the block layer currently doesn't call
    blk_crypto_put_keyslot() until the request is being freed, which happens
    after upper layers have been told (via bio_endio()) the I/O has
    completed.  This causes a race condition where blk_crypto_evict_key()
    can see 'slot_refs != 0' without there being an actual bug.
    
    This makes __blk_crypto_evict_key() hit the
    'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return without
    doing anything, eventually causing a use-after-free in
    blk_crypto_reprogram_all_keys().  (This is a very rare bug and has only
    been seen when per-file keys are being used with fscrypt.)
    
    There are two options to fix this: either release the keyslot before
    bio_endio() is called on the request's last bio, or make
    __blk_crypto_evict_key() ignore slot_refs.  Let's go with the first
    solution, since it preserves the ability to report bugs (via
    WARN_ON_ONCE) where a key is evicted while still in-use.
    
    Fixes: a892c8d52c02 ("block: Inline encryption support for blk-mq")
    Cc: [email protected]
    Reviewed-by: Nathan Huckleberry <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Eric Biggers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bluetooth: Perform careful capability checks in hci_sock_ioctl() [+ + +]
Author: Ruihan Li <[email protected]>
Date:   Sun Apr 16 16:14:04 2023 +0800

    bluetooth: Perform careful capability checks in hci_sock_ioctl()
    
    commit 25c150ac103a4ebeed0319994c742a90634ddf18 upstream.
    
    Previously, capability was checked using capable(), which verified that the
    caller of the ioctl system call had the required capability. In addition,
    the result of the check would be stored in the HCI_SOCK_TRUSTED flag,
    making it persistent for the socket.
    
    However, malicious programs can abuse this approach by deliberately sharing
    an HCI socket with a privileged task. The HCI socket will be marked as
    trusted when the privileged task occasionally makes an ioctl call.
    
    This problem can be solved by using sk_capable() to check capability, which
    ensures that not only the current task but also the socket opener has the
    specified capability, thus reducing the risk of privilege escalation
    through the previously identified vulnerability.
    
    Cc: [email protected]
    Fixes: f81f5b2db869 ("Bluetooth: Send control open and close messages for HCI raw sockets")
    Signed-off-by: Ruihan Li <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bpf, sockmap: fix deadlocks in the sockhash and sockmap [+ + +]
Author: Xin Liu <[email protected]>
Date:   Thu Apr 6 20:26:22 2023 +0800

    bpf, sockmap: fix deadlocks in the sockhash and sockmap
    
    [ Upstream commit ed17aa92dc56b6d8883e4b7a8f1c6fbf5ed6cd29 ]
    
    When huang uses sched_switch tracepoint, the tracepoint
    does only one thing in the mounted ebpf program, which
    deletes the fixed elements in sockhash ([0])
    
    It seems that elements in sockhash are rarely actively
    deleted by users or ebpf program. Therefore, we do not
    pay much attention to their deletion. Compared with hash
    maps, sockhash only provides spin_lock_bh protection.
    This causes it to appear to have self-locking behavior
    in the interrupt context.
    
      [0]:https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
    
    Reported-by: Hsin-Wei Hung <[email protected]>
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Xin Liu <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf, sockmap: Revert buggy deadlock fix in the sockhash and sockmap [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Thu Apr 13 20:28:42 2023 +0200

    bpf, sockmap: Revert buggy deadlock fix in the sockhash and sockmap
    
    [ Upstream commit 8c5c2a4898e3d6bad86e29d471e023c8a19ba799 ]
    
    syzbot reported a splat and bisected it to recent commit ed17aa92dc56 ("bpf,
    sockmap: fix deadlocks in the sockhash and sockmap"):
    
      [...]
      WARNING: CPU: 1 PID: 9280 at kernel/softirq.c:376 __local_bh_enable_ip+0xbe/0x130 kernel/softirq.c:376
      Modules linked in:
      CPU: 1 PID: 9280 Comm: syz-executor.1 Not tainted 6.2.0-syzkaller-13249-gd319f344561d #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
      RIP: 0010:__local_bh_enable_ip+0xbe/0x130 kernel/softirq.c:376
      [...]
      Call Trace:
      <TASK>
      spin_unlock_bh include/linux/spinlock.h:395 [inline]
      sock_map_del_link+0x2ea/0x510 net/core/sock_map.c:165
      sock_map_unref+0xb0/0x1d0 net/core/sock_map.c:184
      sock_hash_delete_elem+0x1ec/0x2a0 net/core/sock_map.c:945
      map_delete_elem kernel/bpf/syscall.c:1536 [inline]
      __sys_bpf+0x2edc/0x53e0 kernel/bpf/syscall.c:5053
      __do_sys_bpf kernel/bpf/syscall.c:5166 [inline]
      __se_sys_bpf kernel/bpf/syscall.c:5164 [inline]
      __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5164
      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
      RIP: 0033:0x7fe8f7c8c169
      </TASK>
      [...]
    
    Revert for now until we have a proper solution.
    
    Fixes: ed17aa92dc56 ("bpf, sockmap: fix deadlocks in the sockhash and sockmap")
    Reported-by: [email protected]
    Cc: Hsin-Wei Hung <[email protected]>
    Cc: Xin Liu <[email protected]>
    Cc: John Fastabend <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Don't EFAULT for getsockopt with optval=NULL [+ + +]
Author: Stanislav Fomichev <[email protected]>
Date:   Tue Apr 18 15:53:38 2023 -0700

    bpf: Don't EFAULT for getsockopt with optval=NULL
    
    [ Upstream commit 00e74ae0863827d944e36e56a4ce1e77e50edb91 ]
    
    Some socket options do getsockopt with optval=NULL to estimate the size
    of the final buffer (which is returned via optlen). This breaks BPF
    getsockopt assumptions about permitted optval buffer size. Let's enforce
    these assumptions only when non-NULL optval is provided.
    
    Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
    Reported-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Stanislav Fomichev <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]/T/#mb68daf700f87a9244a15d01d00c3f0e5b08f49f7
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: fix precision propagation verbose logging [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Mon Mar 13 11:40:17 2023 -0700

    bpf: fix precision propagation verbose logging
    
    [ Upstream commit 34f0677e7afd3a292bc1aadda7ce8e35faedb204 ]
    
    Fix wrong order of frame index vs register/slot index in precision
    propagation verbose (level 2) output. It's wrong and very confusing as is.
    
    Fixes: 529409ea92d5 ("bpf: propagate precision across all frames, not just the last one")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Remove misleading spec_v1 check on var-offset stack read [+ + +]
Author: Luis Gerhorst <[email protected]>
Date:   Wed Mar 15 17:54:00 2023 +0100

    bpf: Remove misleading spec_v1 check on var-offset stack read
    
    [ Upstream commit 082cdc69a4651dd2a77539d69416a359ed1214f5 ]
    
    For every BPF_ADD/SUB involving a pointer, adjust_ptr_min_max_vals()
    ensures that the resulting pointer has a constant offset if
    bypass_spec_v1 is false. This is ensured by calling sanitize_check_bounds()
    which in turn calls check_stack_access_for_ptr_arithmetic(). There,
    -EACCESS is returned if the register's offset is not constant, thereby
    rejecting the program.
    
    In summary, an unprivileged user must never be able to create stack
    pointers with a variable offset. That is also the case, because a
    respective check in check_stack_write() is missing. If they were able
    to create a variable-offset pointer, users could still use it in a
    stack-write operation to trigger unsafe speculative behavior [1].
    
    Because unprivileged users must already be prevented from creating
    variable-offset stack pointers, viable options are to either remove
    this check (replacing it with a clarifying comment), or to turn it
    into a "verifier BUG"-message, also adding a similar check in
    check_stack_write() (for consistency, as a second-level defense).
    This patch implements the first option to reduce verifier bloat.
    
    This check was introduced by commit 01f810ace9ed ("bpf: Allow
    variable-offset stack access") which correctly notes that
    "variable-offset reads and writes are disallowed (they were already
    disallowed for the indirect access case) because the speculative
    execution checking code doesn't support them". However, it does not
    further discuss why the check in check_stack_read() is necessary.
    The code which made this check obsolete was also introduced in this
    commit.
    
    I have compiled ~650 programs from the Linux selftests, Linux samples,
    Cilium, and libbpf/examples projects and confirmed that none of these
    trigger the check in check_stack_read() [2]. Instead, all of these
    programs are, as expected, already rejected when constructing the
    variable-offset pointers. Note that the check in
    check_stack_access_for_ptr_arithmetic() also prints "off=%d" while the
    code removed by this patch does not (the error removed does not appear
    in the "verification_error" values). For reproducibility, the
    repository linked includes the raw data and scripts used to create
    the plot.
    
      [1] https://arxiv.org/pdf/1807.03757.pdf
      [2] https://gitlab.cs.fau.de/un65esoq/bpf-spectre/-/raw/53dc19fcf459c186613b1156a81504b39c8d49db/data/plots/23-02-26_23-56_bpftool/bpftool/0004-errors.pdf?inline=false
    
    Fixes: 01f810ace9ed ("bpf: Allow variable-offset stack access")
    Signed-off-by: Luis Gerhorst <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: take into account liveness when propagating precision [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Thu Mar 9 14:41:31 2023 -0800

    bpf: take into account liveness when propagating precision
    
    [ Upstream commit 52c2b005a3c18c565fc70cfd0ca49375f301e952 ]
    
    When doing state comparison, if old state has register that is not
    marked as REG_LIVE_READ, then we just skip comparison, regardless what's
    the state of corresponing register in current state. This is because not
    REG_LIVE_READ register is irrelevant for further program execution and
    correctness. All good here.
    
    But when we get to precision propagation, after two states were declared
    equivalent, we don't take into account old register's liveness, and thus
    attempt to propagate precision for register in current state even if
    that register in old state was not REG_LIVE_READ anymore. This is bad,
    because register in current state could be anything at all and this
    could cause -EFAULT due to internal logic bugs.
    
    Fix by taking into account REG_LIVE_READ liveness mark to keep the logic
    in state comparison in sync with precision propagation.
    
    Fixes: a3ce685dd01a ("bpf: fix precision tracking")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpftool: Fix bug for long instructions in program CFG dumps [+ + +]
Author: Quentin Monnet <[email protected]>
Date:   Wed Apr 5 14:21:15 2023 +0100

    bpftool: Fix bug for long instructions in program CFG dumps
    
    [ Upstream commit 67cf52cdb6c8fa6365d29106555dacf95c9fd374 ]
    
    When dumping the control flow graphs for programs using the 16-byte long
    load instruction, we need to skip the second part of this instruction
    when looking for the next instruction to process. Otherwise, we end up
    printing "BUG_ld_00" from the kernel disassembler in the CFG.
    
    Fixes: efcef17a6d65 ("tools: bpftool: generate .dot graph from CFG information")
    Signed-off-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: don't free qgroup space unless specified [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Tue May 2 16:00:06 2023 -0400

    btrfs: don't free qgroup space unless specified
    
    commit d246331b78cbef86237f9c22389205bc9b4e1cc1 upstream.
    
    Boris noticed in his simple quotas testing that he was getting a leak
    with Sweet Tea's change to subvol create that stopped doing a
    transaction commit.  This was just a side effect of that change.
    
    In the delayed inode code we have an optimization that will free extra
    reservations if we think we can pack a dir item into an already modified
    leaf.  Previously this wouldn't be triggered in the subvolume create
    case because we'd commit the transaction, it was still possible but
    much harder to trigger.  It could actually be triggered if we did a
    mkdir && subvol create with qgroups enabled.
    
    This occurs because in btrfs_insert_delayed_dir_index(), which gets
    called when we're adding the dir item, we do the following:
    
      btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);
    
    if we're able to skip reserving space.
    
    The problem here is that trans->block_rsv points at the temporary block
    rsv for the subvolume create, which has qgroup reservations in the block
    rsv.
    
    This is a problem because btrfs_block_rsv_release() will do the
    following:
    
      if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) {
              qgroup_to_release = block_rsv->qgroup_rsv_reserved -
                      block_rsv->qgroup_rsv_size;
              block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size;
      }
    
    The temporary block rsv just has ->qgroup_rsv_reserved set,
    ->qgroup_rsv_size == 0.  The optimization in
    btrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0.  Then
    later on when we call btrfs_subvolume_release_metadata() which has
    
      btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release);
      btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);
    
    qgroup_to_release is set to 0, and we do not convert the reserved
    metadata space.
    
    The problem here is that the block rsv code has been unconditionally
    messing with ->qgroup_rsv_reserved, because the main place this is used
    is delalloc, and any time we call btrfs_block_rsv_release() we do it
    with qgroup_to_release set, and thus do the proper accounting.
    
    The subvolume code is the only other code that uses the qgroup
    reservation stuff, but it's intermingled with the above optimization,
    and thus was getting its reservation freed out from underneath it and
    thus leaking the reserved space.
    
    The solution is to simply not mess with the qgroup reservations if we
    don't have qgroup_to_release set.  This works with the existing code as
    anything that messes with the delalloc reservations always have
    qgroup_to_release set.  This fixes the leak that Boris was observing.
    
    Reviewed-by: Qu Wenruo <[email protected]>
    CC: [email protected] # 5.4+
    Signed-off-by: Josef Bacik <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix btrfs_prev_leaf() to not return the same key twice [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed Apr 12 11:33:09 2023 +0100

    btrfs: fix btrfs_prev_leaf() to not return the same key twice
    
    commit 6f932d4ef007d6a4ae03badcb749fbb8f49196f6 upstream.
    
    A call to btrfs_prev_leaf() may end up returning a path that points to the
    same item (key) again. This happens if while btrfs_prev_leaf(), after we
    release the path, a concurrent insertion happens, which moves items off
    from a sibling into the front of the previous leaf, and an item with the
    computed previous key does not exists.
    
    For example, suppose we have the two following leaves:
    
      Leaf A
    
      -------------------------------------------------------------
      | ...   key (300 96 10)   key (300 96 15)   key (300 96 16) |
      -------------------------------------------------------------
                  slot 20             slot 21             slot 22
    
      Leaf B
    
      -------------------------------------------------------------
      | key (300 96 20)   key (300 96 21)   key (300 96 22)   ... |
      -------------------------------------------------------------
          slot 0             slot 1             slot 2
    
    If we call btrfs_prev_leaf(), from btrfs_previous_item() for example, with
    a path pointing to leaf B and slot 0 and the following happens:
    
    1) At btrfs_prev_leaf() we compute the previous key to search as:
       (300 96 19), which is a key that does not exists in the tree;
    
    2) Then we call btrfs_release_path() at btrfs_prev_leaf();
    
    3) Some other task inserts a key at leaf A, that sorts before the key at
       slot 20, for example it has an objectid of 299. In order to make room
       for the new key, the key at slot 22 is moved to the front of leaf B.
       This happens at push_leaf_right(), called from split_leaf().
    
       After this leaf B now looks like:
    
      --------------------------------------------------------------------------------
      | key (300 96 16)    key (300 96 20)   key (300 96 21)   key (300 96 22)   ... |
      --------------------------------------------------------------------------------
           slot 0              slot 1             slot 2             slot 3
    
    4) At btrfs_prev_leaf() we call btrfs_search_slot() for the computed
       previous key: (300 96 19). Since the key does not exists,
       btrfs_search_slot() returns 1 and with a path pointing to leaf B
       and slot 1, the item with key (300 96 20);
    
    5) This makes btrfs_prev_leaf() return a path that points to slot 1 of
       leaf B, the same key as before it was called, since the key at slot 0
       of leaf B (300 96 16) is less than the computed previous key, which is
       (300 96 19);
    
    6) As a consequence btrfs_previous_item() returns a path that points again
       to the item with key (300 96 20).
    
    For some users of btrfs_prev_leaf() or btrfs_previous_item() this may not
    be functional a problem, despite not making sense to return a new path
    pointing again to the same item/key. However for a caller such as
    tree-log.c:log_dir_items(), this has a bad consequence, as it can result
    in not logging some dir index deletions in case the directory is being
    logged without holding the inode's VFS lock (logging triggered while
    logging a child inode for example) - for the example scenario above, in
    case the dir index keys 17, 18 and 19 were deleted in the current
    transaction.
    
    CC: [email protected] # 4.14+
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: print-tree: parent bytenr must be aligned to sector size [+ + +]
Author: Anastasia Belova <[email protected]>
Date:   Wed Apr 26 14:53:23 2023 +0300

    btrfs: print-tree: parent bytenr must be aligned to sector size
    
    commit c87f318e6f47696b4040b58f460d5c17ea0280e6 upstream.
    
    Check nodesize to sectorsize in alignment check in print_extent_item.
    The comment states that and this is correct, similar check is done
    elsewhere in the functions.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: ea57788eb76d ("btrfs: require only sector size alignment for parent eb bytenr")
    CC: [email protected] # 4.14+
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Anastasia Belova <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: scrub: reject unsupported scrub flags [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Thu Apr 6 13:00:34 2023 +0800

    btrfs: scrub: reject unsupported scrub flags
    
    commit 604e6681e114d05a2e384c4d1e8ef81918037ef5 upstream.
    
    Since the introduction of scrub interface, the only flag that we support
    is BTRFS_SCRUB_READONLY.  Thus there is no sanity checks, if there are
    some undefined flags passed in, we just ignore them.
    
    This is problematic if we want to introduce new scrub flags, as we have
    no way to determine if such flags are supported.
    
    Address the problem by introducing a check for the flags, and if
    unsupported flags are set, return -EOPNOTSUPP to inform the user space.
    
    This check should be backported for all supported kernels before any new
    scrub flags are introduced.
    
    CC: [email protected] # 4.14+
    Reviewed-by: Anand Jain <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cifs: fix pcchunk length type in smb2_copychunk_range [+ + +]
Author: Pawel Witek <[email protected]>
Date:   Fri May 5 17:14:59 2023 +0200

    cifs: fix pcchunk length type in smb2_copychunk_range
    
    commit d66cde50c3c868af7abddafce701bb86e4a93039 upstream.
    
    Change type of pcchunk->Length from u32 to u64 to match
    smb2_copychunk_range arguments type. Fixes the problem where performing
    server-side copy with CIFS_IOC_COPYCHUNK_FILE ioctl resulted in incomplete
    copy of large files while returning -EINVAL.
    
    Fixes: 9bf0c9cd4314 ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files")
    Cc: <[email protected]>
    Signed-off-by: Pawel Witek <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clk: add missing of_node_put() in "assigned-clocks" property parsing [+ + +]
Author: Clément Léger <[email protected]>
Date:   Tue Jan 31 09:32:27 2023 +0100

    clk: add missing of_node_put() in "assigned-clocks" property parsing
    
    [ Upstream commit 27a6e1b09a782517fddac91259970ac466a3f7b6 ]
    
    When returning from of_parse_phandle_with_args(), the np member of the
    of_phandle_args structure should be put after usage. Add missing
    of_node_put() calls in both __set_clk_parents() and __set_clk_rates().
    
    Fixes: 86be408bfbd8 ("clk: Support for clock parents and rates assigned from device tree")
    Signed-off-by: Clément Léger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: at91: clk-sam9x60-pll: fix return value check [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Mon Feb 27 12:59:31 2023 +0200

    clk: at91: clk-sam9x60-pll: fix return value check
    
    [ Upstream commit 1bd8e27fd0db0fe7f489213836dcbab92934f8fa ]
    
    sam9x60_frac_pll_compute_mul_frac() can't return zero. Remove the check
    against zero to reflect this.
    
    Fixes: 43b1bb4a9b3e ("clk: at91: clk-sam9x60-pll: re-factor to support plls with multiple outputs")
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: rockchip: rk3399: allow clk_cifout to force clk_cifout_src to reparent [+ + +]
Author: Quentin Schulz <[email protected]>
Date:   Thu Nov 17 13:04:31 2022 +0100

    clk: rockchip: rk3399: allow clk_cifout to force clk_cifout_src to reparent
    
    commit 933bf364e152cd60902cf9585c2ba310d593e69f upstream.
    
    clk_cifout is derived from clk_cifout_src through an integer divider
    limited to 32. clk_cifout_src is a child of either cpll, gpll or npll
    without any possibility of a divider of any sort. The default clock
    parent is cpll.
    
    Let's allow clk_cifout to ask its parent clk_cifout_src to reparent in
    order to find the real closest possible rate for clk_cifout and not one
    derived from cpll only.
    
    Cc: [email protected] # 4.10+
    Fixes: fd8bc829336a ("clk: rockchip: fix the rk3399 cifout clock")
    Signed-off-by: Quentin Schulz <[email protected]>
    Link: https://lore.kernel.org/r/20221117-rk3399-cifout-set-rate-parent-v1-0-432[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clocksource/drivers/davinci: Fix memory leak in davinci_timer_register when init fails [+ + +]
Author: Qinrun Dai <[email protected]>
Date:   Thu Apr 13 13:50:37 2023 +0000

    clocksource/drivers/davinci: Fix memory leak in davinci_timer_register when init fails
    
    [ Upstream commit fb73556386e074e9bee9fa2d253aeaefe4e063e0 ]
    
    Smatch reports:
    drivers/clocksource/timer-davinci.c:332 davinci_timer_register()
    warn: 'base' from ioremap() not released on lines: 274.
    
    Fix this and other potential memory leak problems
    by adding a set of corresponding exit lables.
    
    Fixes: 721154f972aa ("clocksource/drivers/davinci: Add support for clockevents")
    Signed-off-by: Qinrun Dai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: etm_pmu: Set the module field [+ + +]
Author: Suzuki K Poulose <[email protected]>
Date:   Wed Apr 5 10:49:22 2023 +0100

    coresight: etm_pmu: Set the module field
    
    [ Upstream commit 18996a113f2567aef3057e300e3193ce2df1684c ]
    
    struct pmu::module must be set to the module owning the PMU driver.
    Set this for the coresight etm_pmu.
    
    Fixes: 8e264c52e1dab ("coresight: core: Allow the coresight core driver to be built as a module")
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
counter: 104-quad-8: Fix race condition between FLAG and CNTR reads [+ + +]
Author: William Breathitt Gray <[email protected]>
Date:   Sun Mar 12 19:15:49 2023 -0400

    counter: 104-quad-8: Fix race condition between FLAG and CNTR reads
    
    commit 4aa3b75c74603c3374877d5fd18ad9cc3a9a62ed upstream.
    
    The Counter (CNTR) register is 24 bits wide, but we can have an
    effective 25-bit count value by setting bit 24 to the XOR of the Borrow
    flag and Carry flag. The flags can be read from the FLAG register, but a
    race condition exists: the Borrow flag and Carry flag are instantaneous
    and could change by the time the count value is read from the CNTR
    register.
    
    Since the race condition could result in an incorrect 25-bit count
    value, remove support for 25-bit count values from this driver;
    hard-coded maximum count values are replaced by a LS7267_CNTR_MAX define
    for consistency and clarity.
    
    Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
    Cc: <[email protected]> # 6.1.x
    Cc: <[email protected]> # 6.2.x
    Link: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: William Breathitt Gray <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
crypto: api - Demote BUG_ON() in crypto_unregister_alg() to a WARN_ON() [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Mon Mar 13 10:17:24 2023 +0100

    crypto: api - Demote BUG_ON() in crypto_unregister_alg() to a WARN_ON()
    
    commit a543ada7db729514ddd3ba4efa45f4c7b802ad85 upstream.
    
    The crypto_unregister_alg() function expects callers to ensure that any
    algorithm that is unregistered has a refcnt of exactly 1, and issues a
    BUG_ON() if this is not the case. However, there are in fact drivers that
    will call crypto_unregister_alg() without ensuring that the refcnt has been
    lowered first, most notably on system shutdown. This causes the BUG_ON() to
    trigger, which prevents a clean shutdown and hangs the system.
    
    To avoid such hangs on shutdown, demote the BUG_ON() in
    crypto_unregister_alg() to a WARN_ON() with early return. Cc stable because
    this problem was observed on a 6.2 kernel, cf the link below.
    
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

crypto: caam - Clear some memory in instantiate_rng [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Tue Mar 21 07:59:30 2023 +0100

    crypto: caam - Clear some memory in instantiate_rng
    
    [ Upstream commit 9c19fb86a8cb2ee82a832c95e139f29ea05c4d08 ]
    
    According to the comment at the end of the 'for' loop just a few lines
    below, it looks needed to clear 'desc'.
    
    So it should also be cleared for the first iteration.
    
    Move the memset() to the beginning of the loop to be safe.
    
    Fixes: 281922a1d4f5 ("crypto: caam - add support for SEC v5.x RNG4")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Gaurav Jain <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - Clear PSP interrupt status register before calling handler [+ + +]
Author: Jeremi Piotrowski <[email protected]>
Date:   Tue Mar 28 15:16:36 2023 +0000

    crypto: ccp - Clear PSP interrupt status register before calling handler
    
    [ Upstream commit 45121ad4a1750ca47ce3f32bd434bdb0cdbf0043 ]
    
    The PSP IRQ is edge-triggered (MSI or MSI-X) in all cases supported by
    the psp module so clear the interrupt status register early in the
    handler to prevent missed interrupts. sev_irq_handler() calls wake_up()
    on a wait queue, which can result in a new command being submitted from
    a different CPU. This then races with the clearing of isr and can result
    in missed interrupts. A missed interrupt results in a command waiting
    until it times out, which results in the psp being declared dead.
    
    This is unlikely on bare metal, but has been observed when running
    virtualized. In the cases where this is observed, sev->cmdresp_reg has
    PSP_CMDRESP_RESP set which indicates that the command was processed
    correctly but no interrupt was asserted.
    
    The full sequence of events looks like this:
    
    CPU 1: submits SEV cmd #1
    CPU 1: calls wait_event_timeout()
    CPU 0: enters psp_irq_handler()
    CPU 0: calls sev_handler()->wake_up()
    CPU 1: wakes up; finishes processing cmd #1
    CPU 1: submits SEV cmd #2
    CPU 1: calls wait_event_timeout()
    PSP:   finishes processing cmd #2; interrupt status is still set; no interrupt
    CPU 0: clears intsts
    CPU 0: exits psp_irq_handler()
    CPU 1: wait_event_timeout() times out; psp_dead=true
    
    Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
    Cc: [email protected]
    Signed-off-by: Jeremi Piotrowski <[email protected]>
    Acked-by: Tom Lendacky <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: drbg - make drbg_prepare_hrng() handle jent instantiation errors [+ + +]
Author: Nicolai Stange <[email protected]>
Date:   Mon Nov 15 15:18:08 2021 +0100

    crypto: drbg - make drbg_prepare_hrng() handle jent instantiation errors
    
    [ Upstream commit 559edd47cce4cc407d606b4d7f376822816fd4b8 ]
    
    Now that drbg_prepare_hrng() doesn't do anything but to instantiate a
    jitterentropy crypto_rng instance, it looks a little odd to have the
    related error handling at its only caller, drbg_instantiate().
    
    Move the handling of jitterentropy allocation failures from
    drbg_instantiate() close to the allocation itself in drbg_prepare_hrng().
    
    There is no change in behaviour.
    
    Signed-off-by: Nicolai Stange <[email protected]>
    Reviewed-by: Stephan Müller <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Stable-dep-of: 686cd976b6dd ("crypto: drbg - Only fail when jent is unavailable in FIPS mode")
    Signed-off-by: Sasha Levin <[email protected]>

crypto: drbg - Only fail when jent is unavailable in FIPS mode [+ + +]
Author: Herbert Xu <[email protected]>
Date:   Tue Mar 28 11:35:23 2023 +0800

    crypto: drbg - Only fail when jent is unavailable in FIPS mode
    
    [ Upstream commit 686cd976b6ddedeeb1a1fb09ba53a891d3cc9a03 ]
    
    When jent initialisation fails for any reason other than ENOENT,
    the entire drbg fails to initialise, even when we're not in FIPS
    mode.  This is wrong because we can still use the kernel RNG when
    we're not in FIPS mode.
    
    Change it so that it only fails when we are in FIPS mode.
    
    Fixes: 57225e679788 ("crypto: drbg - Use callback API for random readiness")
    Signed-off-by: Herbert Xu <[email protected]>
    Reviewed-by: Stephan Mueller <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sa2ul - Select CRYPTO_DES [+ + +]
Author: Suman Anna <[email protected]>
Date:   Fri Mar 24 20:28:12 2023 +0530

    crypto: sa2ul - Select CRYPTO_DES
    
    [ Upstream commit 8832023efd20966e29944dac92118dfbf1fa1bc0 ]
    
    The SA2UL Crypto driver provides support for couple of
    DES3 algos "cbc(des3_ede)" and "ecb(des3_ede)", and enabling
    the crypto selftest throws the following errors (as seen on
    K3 J721E SoCs):
      saul-crypto 4e00000.crypto: Error allocating fallback algo cbc(des3_ede)
      alg: skcipher: failed to allocate transform for cbc-des3-sa2ul: -2
      saul-crypto 4e00000.crypto: Error allocating fallback algo ecb(des3_ede)
      alg: skcipher: failed to allocate transform for ecb-des3-sa2ul: -2
    
    Fix this by selecting CRYPTO_DES which was missed while
    adding base driver support.
    
    Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver")
    Signed-off-by: Suman Anna <[email protected]>
    Signed-off-by: Jayesh Choudhary <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: safexcel - Cleanup ring IRQ workqueues on load failure [+ + +]
Author: Jonathan McDowell <[email protected]>
Date:   Tue Feb 28 18:28:58 2023 +0000

    crypto: safexcel - Cleanup ring IRQ workqueues on load failure
    
    commit ca25c00ccbc5f942c63897ed23584cfc66e8ec81 upstream.
    
    A failure loading the safexcel driver results in the following warning
    on boot, because the IRQ affinity has not been correctly cleaned up.
    Ensure we clean up the affinity and workqueues on a failure to load the
    driver.
    
    crypto-safexcel: probe of f2800000.crypto failed with error -2
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340
    Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4
    CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G        W          6.1.6-00002-g9d4898824677 #3
    Hardware name: MikroTik RB5009 (DT)
    pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : free_irq+0x300/0x340
    lr : free_irq+0x2e0/0x340
    sp : ffff800008fa3890
    x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000
    x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50
    x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80
    x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e
    x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040
    x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370
    x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18
    x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188
    x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0
    Call trace:
     free_irq+0x300/0x340
     devm_irq_release+0x14/0x20
     devres_release_all+0xa0/0x100
     device_unbind_cleanup+0x14/0x60
     really_probe+0x198/0x2d4
     __driver_probe_device+0x74/0xdc
     driver_probe_device+0x3c/0x110
     __driver_attach+0x8c/0x190
     bus_for_each_dev+0x6c/0xc0
     driver_attach+0x20/0x30
     bus_add_driver+0x148/0x1fc
     driver_register+0x74/0x120
     __platform_driver_register+0x24/0x30
     safexcel_init+0x48/0x1000 [crypto_safexcel]
     do_one_initcall+0x4c/0x1b0
     do_init_module+0x44/0x1cc
     load_module+0x1724/0x1be4
     __do_sys_finit_module+0xbc/0x110
     __arm64_sys_finit_module+0x1c/0x24
     invoke_syscall+0x44/0x110
     el0_svc_common.constprop.0+0xc0/0xe0
     do_el0_svc+0x20/0x80
     el0_svc+0x14/0x4c
     el0t_64_sync_handler+0xb0/0xb4
     el0t_64_sync+0x148/0x14c
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 1b44c5a60c13 ("inside-secure - add SafeXcel EIP197 crypto engine driver")
    Signed-off-by: Jonathan McDowell <[email protected]>
    Cc: [email protected]
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon Apr 17 22:25:09 2023 +0200

    crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs()
    
    [ Upstream commit 8fd91151ebcb21b3f2f2bf158ac6092192550b2b ]
    
    SS_ENCRYPTION is (0 << 7 = 0), so the test can never be true.
    Use a direct comparison to SS_ENCRYPTION instead.
    
    The same king of test is already done the same way in sun8i_ss_run_task().
    
    Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
debugobject: Ensure pool refill (again) [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Mon May 1 17:42:06 2023 +0200

    debugobject: Ensure pool refill (again)
    
    commit 0af462f19e635ad522f28981238334620881badc upstream.
    
    The recent fix to ensure atomicity of lookup and allocation inadvertently
    broke the pool refill mechanism.
    
    Prior to that change debug_objects_activate() and debug_objecs_assert_init()
    invoked debug_objecs_init() to set up the tracking object for statically
    initialized objects. That's not longer the case and debug_objecs_init() is
    now the only place which does pool refills.
    
    Depending on the number of statically initialized objects this can be
    enough to actually deplete the pool, which was observed by Ido via a
    debugobjects OOM warning.
    
    Restore the old behaviour by adding explicit refill opportunities to
    debug_objects_activate() and debug_objecs_assert_init().
    
    Fixes: 63a759694eed ("debugobject: Prevent init race with static objects")
    Reported-by: Ido Schimmel <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Ido Schimmel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

debugobject: Prevent init race with static objects [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Wed Apr 12 09:54:39 2023 +0200

    debugobject: Prevent init race with static objects
    
    [ Upstream commit 63a759694eed61025713b3e14dd827c8548daadc ]
    
    Statically initialized objects are usually not initialized via the init()
    function of the subsystem. They are special cased and the subsystem
    provides a function to validate whether an object which is not yet tracked
    by debugobjects is statically initialized. This means the object is started
    to be tracked on first use, e.g. activation.
    
    This works perfectly fine, unless there are two concurrent operations on
    that object. Schspa decoded the problem:
    
    T0                                  T1
    
    debug_object_assert_init(addr)
      lock_hash_bucket()
      obj = lookup_object(addr);
      if (!obj) {
            unlock_hash_bucket();
            - > preemption
                                        lock_subsytem_object(addr);
                                          activate_object(addr)
                                          lock_hash_bucket();
                                          obj = lookup_object(addr);
                                          if (!obj) {
                                            unlock_hash_bucket();
                                            if (is_static_object(addr))
                                               init_and_track(addr);
                                          lock_hash_bucket();
                                          obj = lookup_object(addr);
                                          obj->state = ACTIVATED;
                                          unlock_hash_bucket();
    
                                        subsys function modifies content of addr,
                                        so static object detection does
                                        not longer work.
    
                                        unlock_subsytem_object(addr);
    
            if (is_static_object(addr)) <- Fails
    
              debugobject emits a warning and invokes the fixup function which
              reinitializes the already active object in the worst case.
    
    This race exists forever, but was never observed until mod_timer() got a
    debug_object_assert_init() added which is outside of the timer base lock
    held section right at the beginning of the function to cover the lockless
    early exit points too.
    
    Rework the code so that the lookup, the static object check and the
    tracking object association happens atomically under the hash bucket
    lock. This prevents the issue completely as all callers are serialized on
    the hash bucket lock and therefore cannot observe inconsistent state.
    
    Fixes: 3ac7fe5a4aab ("infrastructure to debug (dynamic) objects")
    Reported-by: [email protected]
    Debugged-by: Schspa Shi <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Link: https://syzkaller.appspot.com/bug?id=22c8a5938eab640d1c6bcc0e3dc7be519d878462
    Link: https://lore.kernel.org/lkml/20230303161906.8316[email protected]
    Link: https://lore.kernel.org/r/87zg7dzgao.ffs@tglx
    Signed-off-by: Sasha Levin <[email protected]>

 
dm clone: call kmem_cache_destroy() in dm_clone_init() error path [+ + +]
Author: Mike Snitzer <[email protected]>
Date:   Tue Apr 4 11:59:00 2023 -0400

    dm clone: call kmem_cache_destroy() in dm_clone_init() error path
    
    commit 6827af4a9a9f5bb664c42abf7c11af4978d72201 upstream.
    
    Otherwise the _hydration_cache will leak if dm_register_target() fails.
    
    Cc: [email protected]
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm flakey: fix a crash with invalid table line [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Tue Apr 18 15:57:47 2023 -0400

    dm flakey: fix a crash with invalid table line
    
    commit 98dba02d9a93eec11bffbb93c7c51624290702d2 upstream.
    
    This command will crash with NULL pointer dereference:
     dmsetup create flakey --table \
      "0 `blockdev --getsize /dev/ram0` flakey /dev/ram0 0 0 1 2 corrupt_bio_byte 512"
    
    Fix the crash by checking if arg_name is non-NULL before comparing it.
    
    Cc: [email protected]
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path [+ + +]
Author: Mike Snitzer <[email protected]>
Date:   Tue Apr 4 13:34:28 2023 -0400

    dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path
    
    commit 6b79a428c02769f2a11f8ae76bf866226d134887 upstream.
    
    Otherwise the journal_io_cache will leak if dm_register_target() fails.
    
    Cc: [email protected]
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm ioctl: fix nested locking in table_clear() to remove deadlock concern [+ + +]
Author: Mike Snitzer <[email protected]>
Date:   Mon Apr 17 11:59:56 2023 -0400

    dm ioctl: fix nested locking in table_clear() to remove deadlock concern
    
    commit 3d32aaa7e66d5c1479a3c31d6c2c5d45dd0d3b89 upstream.
    
    syzkaller found the following problematic rwsem locking (with write
    lock already held):
    
     down_read+0x9d/0x450 kernel/locking/rwsem.c:1509
     dm_get_inactive_table+0x2b/0xc0 drivers/md/dm-ioctl.c:773
     __dev_status+0x4fd/0x7c0 drivers/md/dm-ioctl.c:844
     table_clear+0x197/0x280 drivers/md/dm-ioctl.c:1537
    
    In table_clear, it first acquires a write lock
    https://elixir.bootlin.com/linux/v6.2/source/drivers/md/dm-ioctl.c#L1520
    down_write(&_hash_lock);
    
    Then before the lock is released at L1539, there is a path shown above:
    table_clear -> __dev_status -> dm_get_inactive_table ->  down_read
    https://elixir.bootlin.com/linux/v6.2/source/drivers/md/dm-ioctl.c#L773
    down_read(&_hash_lock);
    
    It tries to acquire the same read lock again, resulting in the deadlock
    problem.
    
    Fix this by moving table_clear()'s __dev_status() call to after its
    up_write(&_hash_lock);
    
    Cc: [email protected]
    Reported-by: Zheng Zhang <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm verity: fix error handling for check_at_most_once on FEC [+ + +]
Author: Yeongjin Gil <[email protected]>
Date:   Mon Mar 20 15:59:32 2023 +0900

    dm verity: fix error handling for check_at_most_once on FEC
    
    [ Upstream commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3 ]
    
    In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return
    directly. But if FEC configured, it is desired to correct the data page
    through verity_verify_io. And the return value will be converted to
    blk_status and passed to verity_finish_io().
    
    BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips
    verification regardless of I/O error for the corresponding bio. In this
    case, the I/O error could not be returned properly, and as a result,
    there is a problem that abnormal data could be read for the
    corresponding block.
    
    To fix this problem, when an I/O error occurs, do not skip verification
    even if the bit related is set in v->validated_blocks.
    
    Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once")
    Cc: [email protected]
    Reviewed-by: Sungjong Seo <[email protected]>
    Signed-off-by: Yeongjin Gil <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dm verity: skip redundant verity_handle_err() on I/O errors [+ + +]
Author: Akilesh Kailash <[email protected]>
Date:   Mon Sep 13 09:26:42 2021 +0000

    dm verity: skip redundant verity_handle_err() on I/O errors
    
    [ Upstream commit 2c0468e054c0adb660ac055fc396622ec7235df9 ]
    
    Without FEC, dm-verity won't call verity_handle_err() when I/O fails,
    but with FEC enabled, it currently does even if an I/O error has
    occurred.
    
    If there is an I/O error and FEC correction fails, return the error
    instead of calling verity_handle_err() again.
    
    Suggested-by: Sami Tolvanen <[email protected]>
    Signed-off-by: Akilesh Kailash <[email protected]>
    Reviewed-by: Sami Tolvanen <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Stable-dep-of: e8c5d45f82ce ("dm verity: fix error handling for check_at_most_once on FEC")
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: at_xdmac: do not enable all cyclic channels [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Feb 14 17:18:25 2023 +0200

    dmaengine: at_xdmac: do not enable all cyclic channels
    
    [ Upstream commit f8435befd81dd85b7b610598551fadf675849bc1 ]
    
    Do not global enable all the cyclic channels in at_xdmac_resume(). Instead
    save the global status in at_xdmac_suspend() and re-enable the cyclic
    channel only if it was active before suspend.
    
    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver")
    Signed-off-by: Claudiu Beznea <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: dw-edma: Fix to change for continuous transfer [+ + +]
Author: Shunsuke Mie <[email protected]>
Date:   Tue Apr 11 19:17:57 2023 +0900

    dmaengine: dw-edma: Fix to change for continuous transfer
    
    [ Upstream commit a251994a441ee0a69ba7062c8cd2d08ead3db379 ]
    
    The dw-edma driver stops after processing a DMA request even if a request
    remains in the issued queue, which is not the expected behavior. The DMA
    engine API requires continuous processing.
    
    Add a trigger to start after one processing finished if there are requests
    remain.
    
    Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
    Signed-off-by: Shunsuke Mie <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: dw-edma: Fix to enable to issue dma request on DMA processing [+ + +]
Author: Shunsuke Mie <[email protected]>
Date:   Tue Apr 11 19:17:58 2023 +0900

    dmaengine: dw-edma: Fix to enable to issue dma request on DMA processing
    
    [ Upstream commit 970b17dfe264a9085ba4e593730ecfd496b950ab ]
    
    The issue_pending request is ignored while driver is processing a DMA
    request. Fix to issue the pending requests on any dma channel status.
    
    Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
    Signed-off-by: Shunsuke Mie <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: mv_xor_v2: Fix an error code. [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Mar 26 09:06:37 2023 +0200

    dmaengine: mv_xor_v2: Fix an error code.
    
    [ Upstream commit 827026ae2e56ec05ef1155661079badbbfc0b038 ]
    
    If the probe is deferred, -EPROBE_DEFER should be returned, not
    +EPROBE_DEFER.
    
    Fixes: 3cd2c313f1d6 ("dmaengine: mv_xor_v2: Fix clock resource by adding a register clock")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/201170dff832a3c496d125772e10070cd834ebf2.1679814350.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drbd: correctly submit flush bio on barrier [+ + +]
Author: Christoph Böhmwalder <[email protected]>
Date:   Wed May 3 14:19:37 2023 +0200

    drbd: correctly submit flush bio on barrier
    
    commit 3899d94e3831ee07ea6821c032dc297aec80586a upstream.
    
    When we receive a flush command (or "barrier" in DRBD), we currently use
    a REQ_OP_FLUSH with the REQ_PREFLUSH flag set.
    
    The correct way to submit a flush bio is by using a REQ_OP_WRITE without
    any data, and set the REQ_PREFLUSH flag.
    
    Since commit b4a6bb3a67aa ("block: add a sanity check for non-write
    flush/fua bios"), this triggers a warning in the block layer, but this
    has been broken for quite some time before that.
    
    So use the correct set of flags to actually make the flush happen.
    
    Cc: Christoph Hellwig <[email protected]>
    Cc: [email protected]
    Fixes: f9ff0da56437 ("drbd: allow parallel flushes for multi-volume resources")
    Reported-by: Thomas Voegtle <[email protected]>
    Signed-off-by: Christoph Böhmwalder <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
driver core: Don't require dynamic_debug for initcall_debug probe timing [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Wed Apr 12 15:58:42 2023 -0700

    driver core: Don't require dynamic_debug for initcall_debug probe timing
    
    commit e2f06aa885081e1391916367f53bad984714b4db upstream.
    
    Don't require the use of dynamic debug (or modification of the kernel to
    add a #define DEBUG to the top of this file) to get the printk message
    about driver probe timing. This printk is only emitted when
    initcall_debug is enabled on the kernel commandline, and it isn't
    immediately obvious that you have to do something else to debug boot
    timing issues related to driver probe. Add a comment too so it doesn't
    get converted back to pr_debug().
    
    Fixes: eb7fbc9fb118 ("driver core: Add missing '\n' in log messages")
    Cc: stable <[email protected]>
    Cc: Christophe JAILLET <[email protected]>
    Cc: Brian Norris <[email protected]>
    Reviewed-by: Brian Norris <[email protected]>
    Acked-by: Randy Dunlap <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd/display: Fix hang when skipping modeset [+ + +]
Author: Aurabindo Pillai <[email protected]>
Date:   Fri Mar 24 10:42:37 2023 -0400

    drm/amd/display: Fix hang when skipping modeset
    
    commit da5e14909776edea4462672fb4a3007802d262e7 upstream.
    
    [Why&How]
    
    When skipping full modeset since the only state change was a front porch
    change, the DC commit sequence requires extra checks to handle non
    existant plane states being asked to be removed from context.
    
    Reviewed-by: Alvin Lee <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras [+ + +]
Author: Guchun Chen <[email protected]>
Date:   Sat May 6 20:06:45 2023 +0800

    drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras
    
    commit 4a76680311330aefe5074bed8f06afa354b85c48 upstream.
    
    gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.
    So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq
    should be executed under such condition, otherwise, an amdgpu_irq_put
    calltrace will occur.
    
    [ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
    [ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246
    [ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000
    [ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000
    [ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006
    [ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050
    [ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
    [ 7283.170978] FS:  0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
    [ 7283.170981] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
    [ 7283.170986] Call Trace:
    [ 7283.170988]  <TASK>
    [ 7283.170989]  gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu]
    [ 7283.171655]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
    [ 7283.172245]  amdgpu_device_suspend+0x103/0x180 [amdgpu]
    [ 7283.172823]  amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
    [ 7283.173412]  pci_pm_freeze+0x54/0xc0
    [ 7283.173419]  ? __pfx_pci_pm_freeze+0x10/0x10
    [ 7283.173425]  dpm_run_callback+0x98/0x200
    [ 7283.173430]  __device_suspend+0x164/0x5f0
    
    v2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking)
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2522
    Signed-off-by: Guchun Chen <[email protected]>
    Reviewed-by: Tao Zhou <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: add a missing lock for AMDGPU_SCHED [+ + +]
Author: Chia-I Wu <[email protected]>
Date:   Wed Apr 26 15:54:55 2023 -0700

    drm/amdgpu: add a missing lock for AMDGPU_SCHED
    
    [ Upstream commit 2397e3d8d2e120355201a8310b61929f5a8bd2c0 ]
    
    mgr->ctx_handles should be protected by mgr->lock.
    
    v2: improve commit message
    v3: add a Fixes tag
    
    Signed-off-by: Chia-I Wu <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Fixes: 52c6a62c64fa ("drm/amdgpu: add interface for editing a foreign process's priority v3")
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend [+ + +]
Author: Guchun Chen <[email protected]>
Date:   Sat May 6 16:52:59 2023 +0800

    drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend
    
    commit 8b229ada2669b74fdae06c83fbfda5a5a99fc253 upstream.
    
    sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,
    driver unconditionally disables ecc_irq which is only enabled on
    those asics enabling sdma ecc. This will introduce a warning in
    suspend cycle on those chips with sdma ip v4.0, while without
    sdma ecc. So this patch correct this.
    
    [ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
    [ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246
    [ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000
    [ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000
    [ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006
    [ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390
    [ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
    [ 7283.167032] FS:  0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
    [ 7283.167036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
    [ 7283.167041] Call Trace:
    [ 7283.167046]  <TASK>
    [ 7283.167048]  sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu]
    [ 7283.167704]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
    [ 7283.168296]  amdgpu_device_suspend+0x103/0x180 [amdgpu]
    [ 7283.168875]  amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
    [ 7283.169464]  pci_pm_freeze+0x54/0xc0
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2522
    Signed-off-by: Guchun Chen <[email protected]>
    Reviewed-by: Tao Zhou <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini() [+ + +]
Author: Hamza Mahfooz <[email protected]>
Date:   Tue May 2 11:59:08 2023 -0400

    drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini()
    
    commit 922a76ba31adf84e72bc947267385be420c689ee upstream.
    
    As made mention of in commit 08c677cb0b43 ("drm/amdgpu: fix
    amdgpu_irq_put call trace in gmc_v10_0_hw_fini") and commit 13af556104fa
    ("drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini"). It
    is meaningless to call amdgpu_irq_put() for gmc.ecc_irq. So, remove it
    from gmc_v9_0_hw_fini().
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2522
    Fixes: 3029c855d79f ("drm/amdgpu: Fix desktop freezed after gpu-reset")
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/bridge: adv7533: Fix adv7533_mode_valid for adv7533 and adv7535 [+ + +]
Author: Adam Ford <[email protected]>
Date:   Sun Mar 19 07:55:24 2023 -0500

    drm/bridge: adv7533: Fix adv7533_mode_valid for adv7533 and adv7535
    
    [ Upstream commit ee0285e13455fdbce5de315bdbe91b5f198a2a06 ]
    
    When dynamically switching lanes was removed, the intent of the code
    was to check to make sure that higher speed items used 4 lanes, but
    it had the unintended consequence of removing the slower speeds for
    4-lane users.
    
    This attempts to remedy this by doing a check to see that the
    max frequency doesn't exceed the chip limit, and a second
    check to make sure that the max bit-rate doesn't exceed the
    number of lanes * max bit rate / lane.
    
    Fixes: 9a0cdcd6649b ("drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge")
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Adam Ford <[email protected]>
    Signed-off-by: Robert Foss <rfos[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/exynos: move to use request_irq by IRQF_NO_AUTOEN flag [+ + +]
Author: Tian Tao <[email protected]>
Date:   Mon Mar 15 19:49:37 2021 +0800

    drm/exynos: move to use request_irq by IRQF_NO_AUTOEN flag
    
    commit a4e5eed2c6a689ef2b6ad8d7ae86665c69039379 upstream.
    
    After this patch cbe16f35bee68 genirq: Add IRQF_NO_AUTOEN for
    request_irq/nmi() is merged. request_irq() after setting
    IRQ_NOAUTOEN as below
    
    irq_set_status_flags(irq, IRQ_NOAUTOEN);
    request_irq(dev, irq...);
    can be replaced by request_irq() with IRQF_NO_AUTOEN flag.
    
    v2:
    Fix the problem of using wrong flags
    
    Signed-off-by: Tian Tao <[email protected]>
    Signed-off-by: Inki Dae <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var [+ + +]
Author: Daniel Vetter <[email protected]>
Date:   Tue Apr 4 21:40:36 2023 +0200

    drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
    
    commit 1935f0deb6116dd785ea64d8035eab0ff441255b upstream.
    
    Drivers are supposed to fix this up if needed if they don't outright
    reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
    sizes in fb_set_var()").
    
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc
    Cc: [email protected] # v5.4+
    Cc: Daniel Vetter <[email protected]>
    Cc: Javier Martinez Canillas <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915: Make intel_get_crtc_new_encoder() less oopsy [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Thu Apr 13 23:06:02 2023 +0300

    drm/i915: Make intel_get_crtc_new_encoder() less oopsy
    
    [ Upstream commit 631420b06597a33c72b6dcef78d1c2dea17f452d ]
    
    The point of the WARN was to print something, not oops
    straight up. Currently that is precisely what happens
    if we can't find the connector for the crtc in the atomic
    state. Get the dev pointer from the atomic state instead
    of the potentially NULL encoder to avoid that.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Fixes: 3a47ae201e07 ("drm/i915/display: Make WARN* drm specific where encoder ptr is available")
    Reviewed-by: Jani Nikula <[email protected]>
    (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/lima/lima_drv: Add missing unwind goto in lima_pdev_probe() [+ + +]
Author: Harshit Mogalapalli <[email protected]>
Date:   Mon Mar 13 22:27:11 2023 -0700

    drm/lima/lima_drv: Add missing unwind goto in lima_pdev_probe()
    
    [ Upstream commit c5647cae2704e58d1c4e5fedbf63f11bca6376c9 ]
    
    Smatch reports:
    drivers/gpu/drm/lima/lima_drv.c:396 lima_pdev_probe() warn:
            missing unwind goto?
    
    Store return value in err and goto 'err_out0' which has
    lima_sched_slab_fini() before returning.
    
    Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
    Signed-off-by: Harshit Mogalapalli <[email protected]>
    Signed-off-by: Qiang Yu <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/adreno: Defer enabling runpm until hw_init() [+ + +]
Author: Rob Clark <[email protected]>
Date:   Mon Jun 13 11:20:30 2022 -0700

    drm/msm/adreno: Defer enabling runpm until hw_init()
    
    [ Upstream commit 4b18299b33655fa9672b774b6df774dc03d6aee8 ]
    
    To avoid preventing the display from coming up before the rootfs is
    mounted, without resorting to packing fw in the initrd, the GPU has
    this limbo state where the device is probed, but we aren't ready to
    start sending commands to it.  This is particularly problematic for
    a6xx, since the GMU (which requires fw to be loaded) is the one that
    is controlling the power/clk/icc votes.
    
    So defer enabling runpm until we are ready to call gpu->hw_init(),
    as that is a point where we know we have all the needed fw and are
    ready to start sending commands to the coproc's.
    
    Signed-off-by: Rob Clark <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/489337/
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: db7662d076c9 ("drm/msm/adreno: drop bogus pm_runtime_set_active()")
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/adreno: drop bogus pm_runtime_set_active() [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Fri Mar 3 17:48:06 2023 +0100

    drm/msm/adreno: drop bogus pm_runtime_set_active()
    
    [ Upstream commit db7662d076c973072d788bd0e8130e04430307a1 ]
    
    The runtime PM status can only be updated while runtime PM is disabled.
    
    Drop the bogus pm_runtime_set_active() call that was made after enabling
    runtime PM and which (incidentally but correctly) left the runtime PM
    status set to 'suspended'.
    
    Fixes: 2c087a336676 ("drm/msm/adreno: Load the firmware before bringing up the hardware")
    Signed-off-by: Johan Hovold <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/524972/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/disp/dpu: check for crtc enable rather than crtc active to release shared resources [+ + +]
Author: Vinod Polimera <[email protected]>
Date:   Thu Mar 2 22:03:07 2023 +0530

    drm/msm/disp/dpu: check for crtc enable rather than crtc active to release shared resources
    
    [ Upstream commit b6975693846b562c4d3e0e60cc884affc5bdac00 ]
    
    According to KMS documentation, The driver must not release any shared
    resources if active is set to false but enable still true.
    
    Fixes: ccc862b957c6 ("drm/msm/dpu: Fix reservation failures in modeset")
    Signed-off-by: Vinod Polimera <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/524726/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel: otm8009a: Set backlight parent to panel device [+ + +]
Author: James Cowgill <[email protected]>
Date:   Wed Apr 12 17:35:07 2023 +0000

    drm/panel: otm8009a: Set backlight parent to panel device
    
    commit ab4f869fba6119997f7630d600049762a2b014fa upstream.
    
    This is the logical place to put the backlight device, and it also
    fixes a kernel crash if the MIPI host is removed. Previously the
    backlight device would be unregistered twice when this happened - once
    as a child of the MIPI host through `mipi_dsi_host_unregister`, and
    once when the panel device is destroyed.
    
    Fixes: 12a6cbd4f3f1 ("drm/panel: otm8009a: Use new backlight API")
    Signed-off-by: James Cowgill <[email protected]>
    Cc: [email protected]
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230412173450.199592-1-james.cowgil[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/probe-helper: Cancel previous job before starting new one [+ + +]
Author: Dom Cobley <[email protected]>
Date:   Fri Jan 27 16:40:52 2023 +0100

    drm/probe-helper: Cancel previous job before starting new one
    
    [ Upstream commit a8e47884f1906cd7440fafa056adc8817568e73e ]
    
    Currently we schedule a call to output_poll_execute from
    drm_kms_helper_poll_enable for 10s in future. Later we try to replace
    that in drm_helper_probe_single_connector_modes with a 0s schedule with
    delayed_event set.
    
    But as there is already a job in the queue this fails, and the immediate
    job we wanted with delayed_event set doesn't occur until 10s later.
    
    And that call acts as if connector state has changed, reprobing modes.
    This has a side effect of waking up a display that has been blanked.
    
    Make sure we cancel the old job before submitting the immediate one.
    
    Fixes: 162b6a57ac50 ("drm/probe-helper: don't lose hotplug event")
    Acked-by: Daniel Vetter <dani[email protected]>
    Signed-off-by: Dom Cobley <[email protected]>
    [Maxime: Switched to mod_delayed_work]
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/rockchip: Drop unbalanced obj unref [+ + +]
Author: Rob Clark <[email protected]>
Date:   Thu Jan 19 15:17:34 2023 -0800

    drm/rockchip: Drop unbalanced obj unref
    
    [ Upstream commit 8ee3b0e85f6ccd9e6c527bc50eaba774c3bb18d0 ]
    
    In the error path, rockchip_drm_gem_object_mmap() is dropping an obj
    reference that it doesn't own.
    
    Fixes: 41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers")
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vgem: add missing mutex_destroy [+ + +]
Author: Maíra Canal <[email protected]>
Date:   Thu Feb 2 09:55:17 2023 -0300

    drm/vgem: add missing mutex_destroy
    
    [ Upstream commit 7c18189b14b33c1fbf76480b1bd217877c086e67 ]
    
    vgem_fence_open() instantiates a mutex for a particular fence
    instance, but never destroys it by calling mutex_destroy() in
    vgem_fence_close().
    
    So, add the missing mutex_destroy() to guarantee proper resource
    destruction.
    
    Fixes: 407779848445 ("drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)")
    Signed-off-by: Maíra Canal <[email protected]>
    Reviewed-by: Stanislaw Gruszka <[email protected]>
    Signed-off-by: Maíra Canal <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm: msm: adreno: Disable preemption on Adreno 510 [+ + +]
Author: Adam Skladowski <[email protected]>
Date:   Tue Mar 14 23:17:17 2023 +0100

    drm: msm: adreno: Disable preemption on Adreno 510
    
    [ Upstream commit 010c8bbad2cb8c33c47963e29f051f1e917e45a5 ]
    
    Downstream driver appears to not support preemption on A510 target,
    trying to use one make device slow and fill log with rings related errors.
    Set num_rings to 1 to disable preemption.
    
    Suggested-by: Dmitry Baryshkov <[email protected]>
    Fixes: e20c9284c8f2 ("drm/msm/adreno: Add support for Adreno 510 GPU")
    Signed-off-by: Adam Skladowski <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/526898/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
EDAC/skx: Fix overflows on the DRAM row address mapping arrays [+ + +]
Author: Qiuxu Zhuo <[email protected]>
Date:   Sat Feb 11 09:17:28 2023 +0800

    EDAC/skx: Fix overflows on the DRAM row address mapping arrays
    
    [ Upstream commit 71b1e3ba3fed5a34c5fac6d3a15c2634b04c1eb7 ]
    
    The current DRAM row address mapping arrays skx_{open,close}_row[]
    only support ranks with sizes up to 16G. Decoding a rank address
    to a DRAM row address for a 32G rank by using either one of the
    above arrays by the skx_edac driver, will result in an overflow on
    the array.
    
    For a 32G rank, the most significant DRAM row address bit (the
    bit17) is mapped from the bit34 of the rank address. Add this new
    mapping item to both arrays to fix the overflow issue.
    
    Fixes: 4ec656bdf43a ("EDAC, skx_edac: Add EDAC driver for Skylake")
    Reported-by: Feng Xu <[email protected]>
    Tested-by: Feng Xu <[email protected]>
    Signed-off-by: Qiuxu Zhuo <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
erofs: fix potential overflow calculating xattr_isize [+ + +]
Author: Jingbo Xu <[email protected]>
Date:   Fri Apr 14 14:18:10 2023 +0800

    erofs: fix potential overflow calculating xattr_isize
    
    [ Upstream commit 1b3567a1969b26f709d82a874498c0754ea841c3 ]
    
    Given on-disk i_xattr_icount is 16 bits and xattr_isize is calculated
    from i_xattr_icount multiplying 4, xattr_isize has a theoretical maximum
    of 256K (64K * 4).
    
    Thus declare xattr_isize as unsigned int to avoid the potential overflow.
    
    Fixes: bfb8674dc044 ("staging: erofs: add erofs in-memory stuffs")
    Signed-off-by: Jingbo Xu <[email protected]>
    Reviewed-by: Gao Xiang <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

erofs: stop parsing non-compact HEAD index if clusterofs is invalid [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Apr 11 01:37:14 2023 +0800

    erofs: stop parsing non-compact HEAD index if clusterofs is invalid
    
    [ Upstream commit cc4efd3dd2ac9f89143e5d881609747ecff04164 ]
    
    Syzbot generated a crafted image [1] with a non-compact HEAD index of
    clusterofs 33024 while valid numbers should be 0 ~ lclustersize-1,
    which causes the following unexpected behavior as below:
    
     BUG: unable to handle page fault for address: fffff52101a3fff9
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 23ffed067 P4D 23ffed067 PUD 0
     Oops: 0000 [#1] PREEMPT SMP KASAN
     CPU: 1 PID: 4398 Comm: kworker/u5:1 Not tainted 6.3.0-rc6-syzkaller-g09a9639e56c0 #0
     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
     Workqueue: erofs_worker z_erofs_decompressqueue_work
     RIP: 0010:z_erofs_decompress_queue+0xb7e/0x2b40
     ...
     Call Trace:
      <TASK>
      z_erofs_decompressqueue_work+0x99/0xe0
      process_one_work+0x8f6/0x1170
      worker_thread+0xa63/0x1210
      kthread+0x270/0x300
      ret_from_fork+0x1f/0x30
    
    Note that normal images or images using compact indexes are not
    impacted.  Let's fix this now.
    
    [1] https://lore.kernel.org/r/000000000000ec75b005[email protected]
    
    Reported-and-tested-by: [email protected]
    Fixes: 02827e1796b3 ("staging: erofs: add erofs_map_blocks_iter")
    Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes support")
    Signed-off-by: Gao Xiang <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: add bounds checking in get_max_inline_xattr_value_size() [+ + +]
Author: Theodore Ts'o <[email protected]>
Date:   Fri May 12 15:11:02 2023 -0400

    ext4: add bounds checking in get_max_inline_xattr_value_size()
    
    commit 2220eaf90992c11d888fe771055d4de330385f01 upstream.
    
    Normally the extended attributes in the inode body would have been
    checked when the inode is first opened, but if someone is writing to
    the block device while the file system is mounted, it's possible for
    the inode table to get corrupted.  Add bounds checking to avoid
    reading beyond the end of allocated memory if this happens.
    
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?extid=1966db24521e5f6e23f7
    Cc: [email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csum [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Thu May 4 12:15:25 2023 +0000

    ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csum
    
    commit 4f04351888a83e595571de672e0a4a8b74f4fb31 upstream.
    
    When modifying the block device while it is mounted by the filesystem,
    syzbot reported the following:
    
    BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58
    Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586
    
    CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc96618275234 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
     print_address_description+0x74/0x340 mm/kasan/report.c:306
     print_report+0x107/0x1f0 mm/kasan/report.c:417
     kasan_report+0xcd/0x100 mm/kasan/report.c:517
     crc16+0x206/0x280 lib/crc16.c:58
     ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187
     ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210
     ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline]
     ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173
     ext4_remove_blocks fs/ext4/extents.c:2527 [inline]
     ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline]
     ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958
     ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416
     ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342
     ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622
     notify_change+0xe50/0x1100 fs/attr.c:482
     do_truncate+0x200/0x2f0 fs/open.c:65
     handle_truncate fs/namei.c:3216 [inline]
     do_open fs/namei.c:3561 [inline]
     path_openat+0x272b/0x2dd0 fs/namei.c:3714
     do_filp_open+0x264/0x4f0 fs/namei.c:3741
     do_sys_openat2+0x124/0x4e0 fs/open.c:1310
     do_sys_open fs/open.c:1326 [inline]
     __do_sys_creat fs/open.c:1402 [inline]
     __se_sys_creat fs/open.c:1396 [inline]
     __x64_sys_creat+0x11f/0x160 fs/open.c:1396
     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
    RIP: 0033:0x7f72f8a8c0c9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
    RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280
    RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000
    
    Replace
            le16_to_cpu(sbi->s_es->s_desc_size)
    with
            sbi->s_desc_size
    
    It reduces ext4's compiled text size, and makes the code more efficient
    (we remove an extra indirect reference and a potential byte
    swap on big endian systems), and there is no downside. It also avoids the
    potential KASAN / syzkaller failure, as a bonus.
    
    Reported-by: [email protected]
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?id=70d28d11ab14bd7938f3e088365252aa923cff42
    Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30f3
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: 717d50e4971b ("Ext4: Uninitialized Block Groups")
    Cc: [email protected]
    Signed-off-by: Tudor Ambarus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: bail out of ext4_xattr_ibody_get() fails for any reason [+ + +]
Author: Theodore Ts'o <[email protected]>
Date:   Fri May 12 15:16:27 2023 -0400

    ext4: bail out of ext4_xattr_ibody_get() fails for any reason
    
    commit 2a534e1d0d1591e951f9ece2fb460b2ff92edabd upstream.
    
    In ext4_update_inline_data(), if ext4_xattr_ibody_get() fails for any
    reason, it's best if we just fail as opposed to stumbling on,
    especially if the failure is EFSCORRUPTED.
    
    Cc: [email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: check iomap type only if ext4_iomap_begin() does not fail [+ + +]
Author: Baokun Li <[email protected]>
Date:   Fri May 5 21:24:29 2023 +0800

    ext4: check iomap type only if ext4_iomap_begin() does not fail
    
    commit fa83c34e3e56b3c672af38059e066242655271b1 upstream.
    
    When ext4_iomap_overwrite_begin() calls ext4_iomap_begin() map blocks may
    fail for some reason (e.g. memory allocation failure, bare disk write), and
    later because "iomap->type ! = IOMAP_MAPPED" triggers WARN_ON(). When ext4
    iomap_begin() returns an error, it is normal that the type of iomap->type
    may not match the expectation. Therefore, we only determine if iomap->type
    is as expected when ext4_iomap_begin() is executed successfully.
    
    Cc: [email protected]
    Reported-by: [email protected]
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix data races when using cached status extents [+ + +]
Author: Jan Kara <[email protected]>
Date:   Thu May 4 14:55:24 2023 +0200

    ext4: fix data races when using cached status extents
    
    commit 492888df0c7b42fc0843631168b0021bc4caee84 upstream.
    
    When using cached extent stored in extent status tree in tree->cache_es
    another process holding ei->i_es_lock for reading can be racing with us
    setting new value of tree->cache_es. If the compiler would decide to
    refetch tree->cache_es at an unfortunate moment, it could result in a
    bogus in_range() check. Fix the possible race by using READ_ONCE() when
    using tree->cache_es only under ei->i_es_lock for reading.
    
    Cc: [email protected]
    Reported-by: [email protected]
    Link: https://lore.kernel.org/all/[email protected]
    Suggested-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix deadlock when converting an inline directory in nojournal mode [+ + +]
Author: Theodore Ts'o <[email protected]>
Date:   Sat May 6 21:04:01 2023 -0400

    ext4: fix deadlock when converting an inline directory in nojournal mode
    
    commit f4ce24f54d9cca4f09a395f3eecce20d6bec4663 upstream.
    
    In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock
    by calling ext4_handle_dirty_dirblock() when it already has taken the
    directory lock.  There is a similar self-deadlock in
    ext4_incvert_inline_data_nolock() for data files which we'll fix at
    the same time.
    
    A simple reproducer demonstrating the problem:
    
        mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64
        mount -t ext4 -o dirsync /dev/vdc /vdc
        cd /vdc
        mkdir file0
        cd file0
        touch file0
        touch file1
        attr -s BurnSpaceInEA -V abcde .
        touch supercalifragilisticexpialidocious
    
    Cc: [email protected]
    Link: https://lore.kernel.org/r/2023050702160[email protected]
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?id=ba84cc80a9491d65416bc7877e1650c87530fe8a
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix invalid free tracking in ext4_xattr_move_to_block() [+ + +]
Author: Theodore Ts'o <[email protected]>
Date:   Sun Apr 30 03:04:13 2023 -0400

    ext4: fix invalid free tracking in ext4_xattr_move_to_block()
    
    commit b87c7cdf2bed4928b899e1ce91ef0d147017ba45 upstream.
    
    In ext4_xattr_move_to_block(), the value of the extended attribute
    which we need to move to an external block may be allocated by
    kvmalloc() if the value is stored in an external inode.  So at the end
    of the function the code tried to check if this was the case by
    testing entry->e_value_inum.
    
    However, at this point, the pointer to the xattr entry is no longer
    valid, because it was removed from the original location where it had
    been stored.  So we could end up calling kvfree() on a pointer which
    was not allocated by kvmalloc(); or we could also potentially leak
    memory by not freeing the buffer when it should be freed.  Fix this by
    storing whether it should be freed in a separate variable.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://syzkaller.appspot.com/bug?id=5c2aee8256e30b55ccf57312c16d88417adbd5e1
    Link: https://syzkaller.appspot.com/bug?id=41a6b5d4917c0412eb3b3c3c604965bed7d7420b
    Reported-by: [email protected]
    Reported-by: [email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix use-after-free read in ext4_find_extent for bigalloc + inline [+ + +]
Author: Ye Bin <[email protected]>
Date:   Thu Apr 6 11:16:27 2023 +0000

    ext4: fix use-after-free read in ext4_find_extent for bigalloc + inline
    
    [ Upstream commit 835659598c67907b98cd2aa57bb951dfaf675c69 ]
    
    Syzbot found the following issue:
    loop0: detected capacity change from 0 to 2048
    EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
    ==================================================================
    BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]
    BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931
    Read of size 4 at addr ffff888073644750 by task syz-executor420/5067
    
    CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
     print_address_description+0x74/0x340 mm/kasan/report.c:306
     print_report+0x107/0x1f0 mm/kasan/report.c:417
     kasan_report+0xcd/0x100 mm/kasan/report.c:517
     ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]
     ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931
     ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809
     ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline]
     ext4_da_map_blocks fs/ext4/inode.c:1806 [inline]
     ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870
     ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098
     ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082
     generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
     ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285
     ext4_file_write_iter+0x1d0/0x18f0
     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
    RIP: 0033:0x7f4b7a9737b9
    RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9
    RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004
    RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000
    R10: 000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    
    Above issue is happens when enable bigalloc and inline data feature. As
    commit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped for
    bigalloc + inline. But it only resolved issue when has inline data, if
    inline data has been converted to extent(ext4_da_convert_inline_data_to_extent)
    before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. However
    i_data is still store inline data in this scene. Then will trigger UAF
    when find extent.
    To resolve above issue, there is need to add judge "ext4_has_inline_data(inode)"
    in ext4_clu_mapped().
    
    Fixes: 131294c35ed6 ("ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline")
    Reported-by: [email protected]
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ye Bin <[email protected]>
    Reviewed-by: Tudor Ambarus <[email protected]>
    Tested-by: Tudor Ambarus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix WARNING in mb_find_extent [+ + +]
Author: Ye Bin <[email protected]>
Date:   Mon Jan 16 10:00:15 2023 +0800

    ext4: fix WARNING in mb_find_extent
    
    commit fa08a7b61dff8a4df11ff1e84abfc214b487caf7 upstream.
    
    Syzbot found the following issue:
    
    EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
    EXT4-fs (loop0): orphan cleanup on readonly fs
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
    Modules linked in:
    CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
    RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
    RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
    RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
    RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
    R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
    R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
    FS:  0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307
     ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735
     ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605
     ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286
     ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651
     ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864
     ext4_bread+0x2a/0x170 fs/ext4/inode.c:920
     ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105
     write_blk fs/quota/quota_tree.c:64 [inline]
     get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130
     do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340
     do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
     do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
     do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
     dq_insert_tree fs/quota/quota_tree.c:401 [inline]
     qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420
     v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358
     dquot_acquire+0x348/0x670 fs/quota/dquot.c:444
     ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740
     dqget+0x999/0xdc0 fs/quota/dquot.c:914
     __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492
     ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329
     ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
     __ext4_fill_super fs/ext4/super.c:5516 [inline]
     ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
     get_tree_bdev+0x400/0x620 fs/super.c:1282
     vfs_get_tree+0x88/0x270 fs/super.c:1489
     do_new_mount+0x289/0xad0 fs/namespace.c:3145
     do_mount fs/namespace.c:3488 [inline]
     __do_sys_mount fs/namespace.c:3697 [inline]
     __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
     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
    
    Add some debug information:
    mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/[email protected] 64 64 7
    block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    
    Acctually, blocks per group is 64, but block bitmap indicate at least has
    128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's
    bitmap if set.
    To resolve above issue, add check like fsck "Padding at end of block bitmap is
    not set".
    
    Cc: [email protected]
    Reported-by: [email protected]
    Signed-off-by: Ye Bin <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: improve error recovery code paths in __ext4_remount() [+ + +]
Author: Theodore Ts'o <[email protected]>
Date:   Fri May 5 22:20:29 2023 -0400

    ext4: improve error recovery code paths in __ext4_remount()
    
    commit 4c0b4818b1f636bc96359f7817a2d8bab6370162 upstream.
    
    If there are failures while changing the mount options in
    __ext4_remount(), we need to restore the old mount options.
    
    This commit fixes two problem.  The first is there is a chance that we
    will free the old quota file names before a potential failure leading
    to a use-after-free.  The second problem addressed in this commit is
    if there is a failed read/write to read-only transition, if the quota
    has already been suspended, we need to renable quota handling.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: remove a BUG_ON in ext4_mb_release_group_pa() [+ + +]
Author: Theodore Ts'o <[email protected]>
Date:   Sat Apr 29 16:14:46 2023 -0400

    ext4: remove a BUG_ON in ext4_mb_release_group_pa()
    
    commit 463808f237cf73e98a1a45ff7460c2406a150a0b upstream.
    
    If a malicious fuzzer overwrites the ext4 superblock while it is
    mounted such that the s_first_data_block is set to a very large
    number, the calculation of the block group can underflow, and trigger
    a BUG_ON check.  Change this to be an ext4_warning so that we don't
    crash the kernel.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: use ext4_journal_start/stop for fast commit transactions [+ + +]
Author: Harshad Shirwadkar <[email protected]>
Date:   Thu Dec 23 12:21:37 2021 -0800

    ext4: use ext4_journal_start/stop for fast commit transactions
    
    commit 2729cfdcfa1cc49bef5a90d046fa4a187fdfcc69 upstream.
    
    This patch drops all calls to ext4_fc_start_update() and
    ext4_fc_stop_update(). To ensure that there are no ongoing journal
    updates during fast commit, we also make jbd2_fc_begin_commit() lock
    journal for updates. This way we don't have to maintain two different
    transaction start stop APIs for fast commit and full commit. This
    patch doesn't remove the functions altogether since in future we want
    to have inode level locking for fast commits.
    
    Signed-off-by: Harshad Shirwadkar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
f2fs: apply zone capacity to all zone type [+ + +]
Author: Jaegeuk Kim <[email protected]>
Date:   Tue Mar 21 15:58:04 2023 -0700

    f2fs: apply zone capacity to all zone type
    
    [ Upstream commit 0b37ed21e3367539b79284e0b0af2246ffcf0dca ]
    
    If we manage the zone capacity per zone type, it'll break the GC assumption.
    And, the current logic complains valid block count mismatch.
    Let's apply zone capacity to all zone type, if specified.
    
    Fixes: de881df97768 ("f2fs: support zone capacity less than zone size")
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages() [+ + +]
Author: Yangtao Li <[email protected]>
Date:   Tue Mar 21 01:22:18 2023 +0800

    f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()
    
    [ Upstream commit babedcbac164cec970872b8097401ca913a80e61 ]
    
    BUG_ON() will be triggered when writing files concurrently,
    because the same page is writtenback multiple times.
    
    1597 void folio_end_writeback(struct folio *folio)
    1598 {
                    ......
    1618     if (!__folio_end_writeback(folio))
    1619         BUG();
                    ......
    1625 }
    
    kernel BUG at mm/filemap.c:1619!
    Call Trace:
     <TASK>
     f2fs_write_end_io+0x1a0/0x370
     blk_update_request+0x6c/0x410
     blk_mq_end_request+0x15/0x130
     blk_complete_reqs+0x3c/0x50
     __do_softirq+0xb8/0x29b
     ? sort_range+0x20/0x20
     run_ksoftirqd+0x19/0x20
     smpboot_thread_fn+0x10b/0x1d0
     kthread+0xde/0x110
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x22/0x30
     </TASK>
    
    Below is the concurrency scenario:
    
    [Process A]             [Process B]             [Process C]
    f2fs_write_raw_pages()
      - redirty_page_for_writepage()
      - unlock page()
                            f2fs_do_write_data_page()
                              - lock_page()
                              - clear_page_dirty_for_io()
                              - set_page_writeback() [1st writeback]
                                .....
                                - unlock page()
    
                                                    generic_perform_write()
                                                      - f2fs_write_begin()
                                                        - wait_for_stable_page()
    
                                                      - f2fs_write_end()
                                                        - set_page_dirty()
    
      - lock_page()
        - f2fs_do_write_data_page()
          - set_page_writeback() [2st writeback]
    
    This problem was introduced by the previous commit 7377e853967b ("f2fs:
    compress: fix potential deadlock of compress file"). All pagelocks were
    released in f2fs_write_raw_pages(), but whether the page was
    in the writeback state was ignored in the subsequent writing process.
    Let's fix it by waiting for the page to writeback before writing.
    
    Cc: Christoph Hellwig <[email protected]>
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Fixes: 7377e853967b ("f2fs: compress: fix potential deadlock of compress file")
    Signed-off-by: Qi Han <[email protected]>
    Signed-off-by: Yangtao Li <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: enforce single zone capacity [+ + +]
Author: Jaegeuk Kim <[email protected]>
Date:   Tue Jun 28 10:57:24 2022 -0700

    f2fs: enforce single zone capacity
    
    [ Upstream commit b771aadc6e4c221a468fe4a2dfcfffec01a06722 ]
    
    In order to simplify the complicated per-zone capacity, let's support
    only one capacity for entire zoned device.
    
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 0b37ed21e336 ("f2fs: apply zone capacity to all zone type")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix potential corruption when moving a directory [+ + +]
Author: Jaegeuk Kim <[email protected]>
Date:   Thu Apr 6 11:18:48 2023 -0700

    f2fs: fix potential corruption when moving a directory
    
    commit d94772154e524b329a168678836745d2773a6e02 upstream.
    
    F2FS has the same issue in ext4_rename causing crash revealed by
    xfstests/generic/707.
    
    See also commit 0813299c586b ("ext4: Fix possible corruption when moving a directory")
    
    CC: [email protected]
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: fix to avoid use-after-free for cached IPU bio [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Apr 10 10:14:02 2023 +0800

    f2fs: fix to avoid use-after-free for cached IPU bio
    
    [ Upstream commit 5cdb422c839134273866208dad5360835ddb9794 ]
    
    xfstest generic/019 reports a bug:
    
    kernel BUG at mm/filemap.c:1619!
    RIP: 0010:folio_end_writeback+0x8a/0x90
    Call Trace:
     end_page_writeback+0x1c/0x60
     f2fs_write_end_io+0x199/0x420
     bio_endio+0x104/0x180
     submit_bio_noacct+0xa5/0x510
     submit_bio+0x48/0x80
     f2fs_submit_write_bio+0x35/0x300
     f2fs_submit_merged_ipu_write+0x2a0/0x2b0
     f2fs_write_single_data_page+0x838/0x8b0
     f2fs_write_cache_pages+0x379/0xa30
     f2fs_write_data_pages+0x30c/0x340
     do_writepages+0xd8/0x1b0
     __writeback_single_inode+0x44/0x370
     writeback_sb_inodes+0x233/0x4d0
     __writeback_inodes_wb+0x56/0xf0
     wb_writeback+0x1dd/0x2d0
     wb_workfn+0x367/0x4a0
     process_one_work+0x21d/0x430
     worker_thread+0x4e/0x3c0
     kthread+0x103/0x130
     ret_from_fork+0x2c/0x50
    
    The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()
    in f2fs_write_single_data_page() tries to flush IPU bio in cache, however
    f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,
    result in submitting random cached bio which belong to other IO context,
    then it will cause use-after-free issue, fix it by adding additional
    validity check.
    
    Fixes: 0b20fcec8651 ("f2fs: cache global IPU bio")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: handle dqget error in f2fs_transfer_project_quota() [+ + +]
Author: Yangtao Li <[email protected]>
Date:   Tue Feb 21 22:45:50 2023 +0800

    f2fs: handle dqget error in f2fs_transfer_project_quota()
    
    [ Upstream commit 8051692f5f23260215bfe9a72e712d93606acc5f ]
    
    We should set the error code when dqget() failed.
    
    Fixes: 2c1d03056991 ("f2fs: support F2FS_IOC_FS{GET,SET}XATTR")
    Signed-off-by: Yangtao Li <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: qcom_scm: Clear download bit during reboot [+ + +]
Author: Mukesh Ojha <[email protected]>
Date:   Thu Mar 16 20:44:26 2023 +0530

    firmware: qcom_scm: Clear download bit during reboot
    
    [ Upstream commit 781d32d1c9709fd25655c4e3e3e15370ae4ae4db ]
    
    During normal restart of a system download bit should
    be cleared irrespective of whether download mode is
    set or not.
    
    Fixes: 8c1b7dc9ba22 ("firmware: qcom: scm: Expose download-mode control")
    Signed-off-by: Mukesh Ojha <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

firmware: raspberrypi: Introduce devm_rpi_firmware_get() [+ + +]
Author: Nicolas Saenz Julienne <[email protected]>
Date:   Mon Jan 18 13:32:35 2021 +0100

    firmware: raspberrypi: Introduce devm_rpi_firmware_get()
    
    [ Upstream commit f663204c9a1f8d6fcc590667d9d7a9f44e064644 ]
    
    It'll simplify the firmware handling for most consumers.
    
    Suggested-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Nicolas Saenz Julienne <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Reviewed-by: Bartosz Golaszewski <[email protected]>
    Stable-dep-of: 5bca3688bdbc ("Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe")
    Signed-off-by: Sasha Levin <[email protected]>

firmware: stratix10-svc: Fix an NULL vs IS_ERR() bug in probe [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Apr 19 17:27:03 2023 +0300

    firmware: stratix10-svc: Fix an NULL vs IS_ERR() bug in probe
    
    [ Upstream commit e1d6ca042e62c2a69513235f8629eb6e62ca79c5 ]
    
    The svc_create_memory_pool() function returns error pointers.  It never
    returns NULL.  Fix the check.
    
    Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fpga: bridge: fix kernel-doc parameter description [+ + +]
Author: Marco Pagani <[email protected]>
Date:   Wed Mar 1 15:03:08 2023 +0100

    fpga: bridge: fix kernel-doc parameter description
    
    [ Upstream commit 7ef1a2c1c9dffa177ecc3ea50b7f5ee63a621137 ]
    
    Fix the kernel-doc description for the "struct fpga_image_info *info"
    parameter of the fpga_bridge_get() function.
    
    Fixes: 060ac5c8fa7b ("fpga: bridge: kernel-doc fixes")
    Signed-off-by: Marco Pagani <[email protected]>
    Reviewed-by: Tom Rix <[email protected]>
    Acked-by: Xu Yilun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: wacom: insert timestamp to packed Bluetooth (BT) events [+ + +]
Author: Ping Cheng <[email protected]>
Date:   Fri Feb 24 08:26:43 2023 -0800

    HID: wacom: insert timestamp to packed Bluetooth (BT) events
    
    commit 17d793f3ed53080dab6bbeabfc82de890c901001 upstream.
    
    To fully utilize the BT polling/refresh rate, a few input events
    are sent together to reduce event delay. This causes issue to the
    timestamp generated by input_sync since all the events in the same
    packet would pretty much have the same timestamp. This patch inserts
    time interval to the events by averaging the total time used for
    sending the packet.
    
    This decision was mainly based on observing the actual time interval
    between each BT polling. The interval doesn't seem to be constant,
    due to the network and system environment. So, using solutions other
    than averaging doesn't end up with valid timestamps.
    
    Signed-off-by: Ping Cheng <[email protected]>
    Reviewed-by: Jason Gerecke <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: Set a default resolution for older tablets [+ + +]
Author: Ping Cheng <[email protected]>
Date:   Sun Apr 9 09:42:29 2023 -0700

    HID: wacom: Set a default resolution for older tablets
    
    commit 08a46b4190d345544d04ce4fe2e1844b772b8535 upstream.
    
    Some older tablets may not report physical maximum for X/Y
    coordinates. Set a default to prevent undefined resolution.
    
    Signed-off-by: Ping Cheng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwmon: (adt7475) Use device_property APIs when configuring polarity [+ + +]
Author: Chris Packham <[email protected]>
Date:   Wed Apr 19 11:36:55 2023 +1200

    hwmon: (adt7475) Use device_property APIs when configuring polarity
    
    commit 2a8e41ad337508fc5d598c0f9288890214f8e318 upstream.
    
    On DT unaware platforms of_property_read_u32_array() returns -ENOSYS
    which wasn't handled by the code treating adi,pwm-active-state as
    optional. Update the code to use device_property_read_u32_array() which
    deals gracefully with DT unaware platforms.
    
    Fixes: 86da28eed4fb ("hwmon: (adt7475) Add support for inverting pwm output")
    Reported-by: Mariusz Białończyk <[email protected]>
    Link: https://lore.kernel.org/linux-hwmon/[email protected]/T/#mdd0505801e0a4e72340de009a47c0fca4f771ed3
    Signed-off-by: Chris Packham <[email protected]>
    Link: https://lore.kernel.org/r/20230418233656.869055-2-chris.[email protected]
    Cc: [email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

hwmon: (k10temp) Check range scale when CUR_TEMP register is read-write [+ + +]
Author: Babu Moger <[email protected]>
Date:   Thu Apr 13 16:39:58 2023 -0500

    hwmon: (k10temp) Check range scale when CUR_TEMP register is read-write
    
    commit 0c072385348e3ac5229145644055d3e2afb5b3db upstream.
    
    Spec says, when CUR_TEMP_TJ_SEL == 3 and CUR_TEMP_RANGE_SEL == 0,
    it should use RangeUnadjusted is 0, which is (CurTmp*0.125 -49) C. The
    CUR_TEMP register is read-write when CUR_TEMP_TJ_SEL == 3 (bit 17-16).
    
    Add the check to detect it.
    
    Sensors command's output before the patch.
    $sensors
     k10temp-pci-00c3
     Adapter: PCI adapter
     Tctl:         +76.6°C <- Wrong value
     Tccd1:        +26.5°C
     Tccd2:        +27.5°C
     Tccd3:        +27.2°C
     Tccd4:        +27.5°C
     Tccd5:        +26.0°C
     Tccd6:        +26.2°C
     Tccd7:        +25.0°C
     Tccd8:        +26.5°C
    
    Sensors command's output after the patch.
    $sensors
     k10temp-pci-00c3
     Adapter: PCI adapter
     Tctl:         +28.8°C <- corrected value
     Tccd1:        +27.5°C
     Tccd2:        +28.5°C
     Tccd3:        +28.5°C
     Tccd4:        +28.5°C
     Tccd5:        +27.0°C
     Tccd6:        +27.5°C
     Tccd7:        +27.0°C
     Tccd8:        +27.5°C
    
    Signed-off-by: Babu Moger <[email protected]>
    Fixes: 1b59788979ac ("hwmon: (k10temp) Add temperature offset for Ryzen 2700X")
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path [+ + +]
Author: Lars-Peter Clausen <[email protected]>
Date:   Thu Apr 13 19:10:21 2023 -0700

    i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path
    
    [ Upstream commit ae1664f04f504a998737f5bb563f16b44357bcca ]
    
    The cdns_i2c_master_xfer() function gets a runtime PM reference when the
    function is entered. This reference is released when the function is
    exited. There is currently one error path where the function exits
    directly, which leads to a leak of the runtime PM reference.
    
    Make sure that this error path also releases the runtime PM reference.
    
    Fixes: 1a351b10b967 ("i2c: cadence: Added slave support")
    Signed-off-by: Lars-Peter Clausen <[email protected]>
    Reviewed-by: Michal Simek <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: omap: Fix standard mode false ACK readings [+ + +]
Author: Reid Tonking <[email protected]>
Date:   Wed Apr 26 14:49:56 2023 -0500

    i2c: omap: Fix standard mode false ACK readings
    
    commit c770657bd2611b077ec1e7b1fe6aa92f249399bd upstream.
    
    Using standard mode, rare false ACK responses were appearing with
    i2cdetect tool. This was happening due to NACK interrupt triggering
    ISR thread before register access interrupt was ready. Removing the
    NACK interrupt's ability to trigger ISR thread lets register access
    ready interrupt do this instead.
    
    Cc: <[email protected]> # v3.7+
    Fixes: 3b2f8f82dad7 ("i2c: omap: switch to threaded IRQ support")
    Signed-off-by: Reid Tonking <[email protected]>
    Acked-by: Vignesh Raghavendra <[email protected]>
    Reviewed-by: Tony Lindgren <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ia64: fix an addr to taddr in huge_pte_offset() [+ + +]
Author: Hugh Dickins <[email protected]>
Date:   Sun Apr 16 22:17:05 2023 -0700

    ia64: fix an addr to taddr in huge_pte_offset()
    
    commit 3647ebcfbfca384840231fe13fae665453238a61 upstream.
    
    I know nothing of ia64 htlbpage_to_page(), but guess that the p4d
    line should be using taddr rather than addr, like everywhere else.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: c03ab9e32a2c ("ia64: add support for folded p4d page tables")
    Signed-off-by: Hugh Dickins <[email protected]
    Acked-by: Mike Kravetz <[email protected]>
    Acked-by: Mike Rapoport (IBM) <[email protected]>
    Cc: Ard Biesheuvel <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ia64: mm/contig: fix section mismatch warning/error [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 22 19:42:58 2023 -0800

    ia64: mm/contig: fix section mismatch warning/error
    
    [ Upstream commit 58deeb4ef3b054498747d0929d94ac53ab90981f ]
    
    alloc_per_cpu_data() is called by find_memory(), which is marked as
    __init.  Therefore alloc_per_cpu_data() can also be marked as __init to
    remedy this modpost problem.
    
    WARNING: modpost: vmlinux.o: section mismatch in reference: alloc_per_cpu_data (section: .text) -> memblock_alloc_try_nid (section: .init.text)
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 4b9ddc7cf272 ("[IA64] Fix section mismatch in contig.c version of per_cpu_init()")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ia64: salinfo: placate defined-but-not-used warning [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 22 19:43:09 2023 -0800

    ia64: salinfo: placate defined-but-not-used warning
    
    [ Upstream commit 0de155752b152d6bcd96b5b5bf20af336abd183a ]
    
    When CONFIG_PROC_FS is not set, proc_salinfo_show() is not used.  Mark the
    function as __maybe_unused to quieten the warning message.
    
    ../arch/ia64/kernel/salinfo.c:584:12: warning: 'proc_salinfo_show' defined but not used [-Wunused-function]
      584 | static int proc_salinfo_show(struct seq_file *m, void *v)
          |            ^~~~~~~~~~~~~~~~~
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3f3942aca6da ("proc: introduce proc_create_single{,_data}")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
IB/hfi1: Add additional usdma traces [+ + +]
Author: Mike Marciniszyn <[email protected]>
Date:   Mon Mar 29 09:54:13 2021 -0400

    IB/hfi1: Add additional usdma traces
    
    [ Upstream commit 6b13215df1d37f5be23fc4a01a915a287b25ce15 ]
    
    Add traces that were vital in isolating an issue with pq waitlist in
    commit fa8dac396863 ("IB/hfi1: Fix another case where pq is left on
    waitlist")
    
    Link: https://lore.kernel.org/r/1617026056-50483-8-git-send-email-dennis.dalessandro@cornelisnetworks.com
    Reviewed-by: Kaike Wan <[email protected]>
    Signed-off-by: Mike Marciniszyn <[email protected]>
    Signed-off-by: Dennis Dalessandro <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Stable-dep-of: 00cbce5cbf88 ("IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests")
    Signed-off-by: Sasha Levin <[email protected]>

IB/hfi1: Add AIP tx traces [+ + +]
Author: Mike Marciniszyn <[email protected]>
Date:   Mon Mar 29 09:54:07 2021 -0400

    IB/hfi1: Add AIP tx traces
    
    [ Upstream commit 4bd00b55c978017aad10f0ff3e45525cd62cca07 ]
    
    Add traces to allow for debugging issues with AIP tx.
    
    Link: https://lore.kernel.org/r/1617026056-50483-2-git-send-email-dennis.dalessandro@cornelisnetworks.com
    Reviewed-by: Kaike Wan <[email protected]>
    Signed-off-by: Mike Marciniszyn <[email protected]>
    Signed-off-by: Dennis Dalessandro <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Stable-dep-of: 00cbce5cbf88 ("IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests")
    Signed-off-by: Sasha Levin <[email protected]>

IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests [+ + +]
Author: Patrick Kelsey <[email protected]>
Date:   Fri Apr 7 12:52:44 2023 -0400

    IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests
    
    [ Upstream commit 00cbce5cbf88459cd1aa1d60d0f1df15477df127 ]
    
    hfi1 user SDMA request processing has two bugs that can cause data
    corruption for user SDMA requests that have multiple payload iovecs
    where an iovec other than the tail iovec does not run up to the page
    boundary for the buffer pointed to by that iovec.a
    
    Here are the specific bugs:
    1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len.
       Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec
       to the packet, even if some of those bytes are past
       iovec->iov.iov_len and are thus not intended to be in the packet.
    2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the
       next iovec in user_sdma_request->iovs when the current iovec
       is not PAGE_SIZE and does not contain enough data to complete the
       packet. The transmitted packet will contain the wrong data from the
       iovec pages.
    
    This has not been an issue with SDMA packets from hfi1 Verbs or PSM2
    because they only produce iovecs that end short of PAGE_SIZE as the tail
    iovec of an SDMA request.
    
    Fixing these bugs exposes other bugs with the SDMA pin cache
    (struct mmu_rb_handler) that get in way of supporting user SDMA requests
    with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So
    this commit fixes those issues as well.
    
    Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
    payload user SDMA requests can hit:
    1. Overlapping memory ranges in mmu_rb_handler will result in duplicate
       pinnings.
    2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),
       the mmu_rb code (1) removes the existing entry under a lock, (2)
       releases that lock, pins the new pages, (3) then reacquires the lock
       to insert the extended mmu_rb_node.
    
       If someone else comes in and inserts an overlapping entry between (2)
       and (3), insert in (3) will fail.
    
       The failure path code in this case unpins _all_ pages in either the
       original mmu_rb_node or the new mmu_rb_node that was inserted between
       (2) and (3).
    3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is
       incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node
       could be evicted by another thread that gets mmu_rb_handler->lock and
       checks mmu_rb_node->refcount before mmu_rb_node->refcount is
       incremented.
    4. Related to #2 above, SDMA request submission failure path does not
       check mmu_rb_node->refcount before freeing mmu_rb_node object.
    
       If there are other SDMA requests in progress whose iovecs have
       pointers to the now-freed mmu_rb_node(s), those pointers to the
       now-freed mmu_rb nodes will be dereferenced when those SDMA requests
       complete.
    
    Fixes: 7be85676f1d1 ("IB/hfi1: Don't remove RB entry when not needed.")
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Signed-off-by: Brendan Cunningham <[email protected]>
    Signed-off-by: Patrick Kelsey <[email protected]>
    Signed-off-by: Dennis Dalessandro <[email protected]>
    Link: https://lore.kernel.org/r/168088636445.3027109.10054635277810177889.stgit@252.162.96.66.static.eigbox.net
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

IB/hfi1: Fix SDMA mmu_rb_node not being evicted in LRU order [+ + +]
Author: Patrick Kelsey <[email protected]>
Date:   Fri Apr 7 12:52:39 2023 -0400

    IB/hfi1: Fix SDMA mmu_rb_node not being evicted in LRU order
    
    [ Upstream commit 9fe8fec5e43d5a80f43cbf61aaada1b047a1eb61 ]
    
    hfi1_mmu_rb_remove_unless_exact() did not move mmu_rb_node objects in
    mmu_rb_handler->lru_list after getting a cache hit on an mmu_rb_node.
    
    As a result, hfi1_mmu_rb_evict() was not guaranteed to evict truly
    least-recently used nodes.
    
    This could be a performance issue for an application when that
    application:
    - Uses some long-lived buffers frequently.
    - Uses a large number of buffers once.
    - Hits the mmu_rb_handler cache size or pinned-page limits, forcing
      mmu_rb_handler cache entries to be evicted.
    
    In this case, the one-time use buffers cause the long-lived buffer
    entries to eventually filter to the end of the LRU list where
    hfi1_mmu_rb_evict() will consider evicting a frequently-used long-lived
    entry instead of evicting one of the one-time use entries.
    
    Fix this by inserting new mmu_rb_node at the tail of
    mmu_rb_handler->lru_list and move mmu_rb_ndoe to the tail of
    mmu_rb_handler->lru_list when the mmu_rb_node is a hit in
    hfi1_mmu_rb_remove_unless_exact(). Change hfi1_mmu_rb_evict() to evict
    from the head of mmu_rb_handler->lru_list instead of the tail.
    
    Fixes: 0636e9ab8355 ("IB/hfi1: Add cache evict LRU list")
    Signed-off-by: Brendan Cunningham <[email protected]>
    Signed-off-by: Patrick Kelsey <[email protected]>
    Signed-off-by: Dennis Dalessandro <[email protected]>
    Link: https://lore.kernel.org/r/168088635931.3027109.10423156330761536044.stgit@252.162.96.66.static.eigbox.net
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: adc: palmas_gpadc: fix NULL dereference on rmmod [+ + +]
Author: Patrik Dahlström <[email protected]>
Date:   Mon Mar 13 21:50:29 2023 +0100

    iio: adc: palmas_gpadc: fix NULL dereference on rmmod
    
    [ Upstream commit 49f76c499d38bf67803438eee88c8300d0f6ce09 ]
    
    Calling dev_to_iio_dev() on a platform device pointer is undefined and
    will make adc NULL.
    
    Signed-off-by: Patrik Dahlström <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: light: max44009: add missing OF device matching [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Mar 12 16:34:28 2023 +0100

    iio: light: max44009: add missing OF device matching
    
    [ Upstream commit b29c49026c3c05a11f845dba17cad0b3ba06836d ]
    
    The driver currently matches only via i2c_device_id, but also has
    of_device_id table:
    
      drivers/iio/light/max44009.c:545:34: error: ‘max44009_of_match’ defined but not used [-Werror=unused-const-variable=]
    
    Fixes: 6aef699a7d7e ("iio: light: add driver for MAX44009")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
inotify: Avoid reporting event with invalid wd [+ + +]
Author: Jan Kara <[email protected]>
Date:   Mon Apr 24 18:32:19 2023 +0200

    inotify: Avoid reporting event with invalid wd
    
    commit c915d8f5918bea7c3962b09b8884ca128bfd9b0c upstream.
    
    When inotify_freeing_mark() races with inotify_handle_inode_event() it
    can happen that inotify_handle_inode_event() sees that i_mark->wd got
    already reset to -1 and reports this value to userspace which can
    confuse the inotify listener. Avoid the problem by validating that wd is
    sensible (and pretend the mark got removed before the event got
    generated otherwise).
    
    CC: [email protected]
    Fixes: 7e790dd5fc93 ("inotify: fix error paths in inotify_update_watch")
    Message-Id: <20230424163219.925[email protected]>
    Reported-by: [email protected]
    Reviewed-by: Amir Goldstein <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Thu Apr 13 23:05:20 2023 -0700

    Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe
    
    [ Upstream commit 5bca3688bdbc3b58a2894b8671a8e2378efe28bd ]
    
    rpi_firmware_get() take reference, we need to release it in error paths
    as well. Use devm_rpi_firmware_get() helper to handling the resources.
    Also remove the existing rpi_firmware_put().
    
    Fixes: 0b9f28fed3f7 ("Input: add official Raspberry Pi's touchscreen driver")
    Fixes: 3b8ddff780b7 ("input: raspberrypi-ts: Release firmware handle when not needed")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Mattijs Korpershoek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
input: raspberrypi-ts: Release firmware handle when not needed [+ + +]
Author: Nicolas Saenz Julienne <[email protected]>
Date:   Mon Jan 18 13:32:41 2021 +0100

    input: raspberrypi-ts: Release firmware handle when not needed
    
    [ Upstream commit 3b8ddff780b7d12e99ae39177f84b9003097777a ]
    
    There is no use for the firmware interface after getting the touch
    buffer address, so release it.
    
    Signed-off-by: Nicolas Saenz Julienne <[email protected]>
    Acked-by: Dmitry Torokhov <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Stable-dep-of: 5bca3688bdbc ("Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe")
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/amd: Fix "Guest Virtual APIC Table Root Pointer" configuration in IRTE [+ + +]
Author: Kishon Vijay Abraham I <[email protected]>
Date:   Wed Apr 5 13:03:17 2023 +0000

    iommu/amd: Fix "Guest Virtual APIC Table Root Pointer" configuration in IRTE
    
    commit ccc62b827775915a9b82db42a29813d04f92df7a upstream.
    
    commit b9c6ff94e43a ("iommu/amd: Re-factor guest virtual APIC
    (de-)activation code") while refactoring guest virtual APIC
    activation/de-activation code, stored information for activate/de-activate
    in "struct amd_ir_data". It used 32-bit integer data type for storing the
    "Guest Virtual APIC Table Root Pointer" (ga_root_ptr), though the
    "ga_root_ptr" is actually a 40-bit field in IRTE (Interrupt Remapping
    Table Entry).
    
    This causes interrupts from PCIe devices to not reach the guest in the case
    of PCIe passthrough with SME (Secure Memory Encryption) enabled as _SME_
    bit in the "ga_root_ptr" is lost before writing it to the IRTE.
    
    Fix it by using 64-bit data type for storing the "ga_root_ptr". While at
    that also change the data type of "ga_tag" to u32 in order to match
    the IOMMU spec.
    
    Fixes: b9c6ff94e43a ("iommu/amd: Re-factor guest virtual APIC (de-)activation code")
    Cc: [email protected] # v5.4+
    Reported-by: Alejandro Jimenez <[email protected]>
    Reviewed-by: Suravee Suthikulpanit <[email protected]>
    Signed-off-by: Kishon Vijay Abraham I <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ionic: remove noise from ethtool rxnfc error msg [+ + +]
Author: Shannon Nelson <[email protected]>
Date:   Tue May 2 11:47:40 2023 -0700

    ionic: remove noise from ethtool rxnfc error msg
    
    [ Upstream commit 3711d44fac1f80ea69ecb7315fed05b3812a7401 ]
    
    It seems that ethtool is calling into .get_rxnfc more often with
    ETHTOOL_GRXCLSRLCNT which ionic doesn't know about.  We don't
    need to log a message about it, just return not supported.
    
    Fixes: aa3198819bea6 ("ionic: Add RSS support")
    Signed-off-by: Shannon Nelson <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipmi: ASPEED_BT_IPMI_BMC: select REGMAP_MMIO instead of depending on it [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sat Feb 25 21:39:46 2023 -0800

    ipmi: ASPEED_BT_IPMI_BMC: select REGMAP_MMIO instead of depending on it
    
    [ Upstream commit 2a587b9ad052e7e92e508aea90c1e2ae433c1908 ]
    
    REGMAP is a hidden (not user visible) symbol. Users cannot set it
    directly thru "make *config", so drivers should select it instead of
    depending on it if they need it.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on REGMAP_MMIO" to
    "select REGMAP_MMIO", which will also set REGMAP.
    
    Fixes: eb994594bc22 ("ipmi: bt-bmc: Use a regmap for register access")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Andrew Jeffery <[email protected]>
    Cc: Corey Minyard <[email protected]>
    Cc: [email protected]
    Cc: Arnd Bergmann <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Corey Minyard <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipmi: fix SSIF not responding under certain cond. [+ + +]
Author: Zhang Yuchen <[email protected]>
Date:   Wed Apr 12 15:49:07 2023 +0800

    ipmi: fix SSIF not responding under certain cond.
    
    commit 6d2555cde2918409b0331560e66f84a0ad4849c6 upstream.
    
    The ipmi communication is not restored after a specific version of BMC is
    upgraded on our server.
    The ipmi driver does not respond after printing the following log:
    
        ipmi_ssif: Invalid response getting flags: 1c 1
    
    I found that after entering this branch, ssif_info->ssif_state always
    holds SSIF_GETTING_FLAGS and never return to IDLE.
    
    As a result, the driver cannot be loaded, because the driver status is
    checked during the unload process and must be IDLE in shutdown_ssif():
    
            while (ssif_info->ssif_state != SSIF_IDLE)
                    schedule_timeout(1);
    
    The process trigger this problem is:
    
    1. One msg timeout and next msg start send, and call
    ssif_set_need_watch().
    
    2. ssif_set_need_watch()->watch_timeout()->start_flag_fetch() change
    ssif_state to SSIF_GETTING_FLAGS.
    
    3. In msg_done_handler() ssif_state == SSIF_GETTING_FLAGS, if an error
    message is received, the second branch does not modify the ssif_state.
    
    4. All retry action need IS_SSIF_IDLE() == True. Include retry action in
    watch_timeout(), msg_done_handler(). Sending msg does not work either.
    SSIF_IDLE is also checked in start_next_msg().
    
    5. The only thing that can be triggered in the SSIF driver is
    watch_timeout(), after destory_user(), this timer will stop too.
    
    So, if enter this branch, the ssif_state will remain SSIF_GETTING_FLAGS
    and can't send msg, no timer started, can't unload.
    
    We did a comparative test before and after adding this patch, and the
    result is effective.
    
    Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF)")
    
    Cc: [email protected]
    Signed-off-by: Zhang Yuchen <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Corey Minyard <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: ipmi:ssif: Add send_retries increment [+ + +]
Author: Corey Minyard <[email protected]>
Date:   Tue Apr 4 12:09:14 2023 +0000

    ipmi:ssif: Add send_retries increment
    
    commit 6ce7995a43febe693d4894033c6e29314970646a upstream.
    
    A recent change removed an increment of send_retries, re-add it.
    
    Fixes: 95767ed78a18 ipmi:ssif: resend_msg() cannot fail
    Reported-by: Pavel Machek <[email protected]>
    Cc: [email protected]
    Signed-off-by: Corey Minyard <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ipv4: Fix potential uninit variable access bug in __ip_make_skb() [+ + +]
Author: Ziyang Xuan <[email protected]>
Date:   Thu Apr 20 20:40:35 2023 +0800

    ipv4: Fix potential uninit variable access bug in __ip_make_skb()
    
    [ Upstream commit 99e5acae193e369b71217efe6f1dad42f3f18815 ]
    
    Like commit ea30388baebc ("ipv6: Fix an uninit variable access bug in
    __ip6_make_skb()"). icmphdr does not in skb linear region under the
    scenario of SOCK_RAW socket. Access icmp_hdr(skb)->type directly will
    trigger the uninit variable access bug.
    
    Use a local variable icmp_type to carry the correct value in different
    scenarios.
    
    Fixes: 96793b482540 ("[IPV4]: Add ICMPMsgStats MIB (RFC 4293)")
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Ziyang Xuan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ixgbe: Allow flow hash to be set via ethtool [+ + +]
Author: Joe Damato <[email protected]>
Date:   Sun Apr 16 19:12:22 2023 +0000

    ixgbe: Allow flow hash to be set via ethtool
    
    [ Upstream commit 4f3ed1293feb9502dc254b05802faf1ad3317ac6 ]
    
    ixgbe currently returns `EINVAL` whenever the flowhash it set by ethtool
    because the ethtool code in the kernel passes a non-zero value for hfunc
    that ixgbe should allow.
    
    When ethtool is called with `ETHTOOL_SRXFHINDIR`,
    `ethtool_set_rxfh_indir` will call ixgbe's set_rxfh function
    with `ETH_RSS_HASH_NO_CHANGE`. This value should be accepted.
    
    When ethtool is called with `ETHTOOL_SRSSH`, `ethtool_set_rxfh` will
    call ixgbe's set_rxfh function with `rxfh.hfunc`, which appears to be
    hardcoded in ixgbe to always be `ETH_RSS_HASH_TOP`. This value should
    also be accepted.
    
    Before this patch:
    
    $ sudo ethtool -L eth1 combined 10
    $ sudo ethtool -X eth1 default
    Cannot set RX flow hash configuration: Invalid argument
    
    After this patch:
    
    $ sudo ethtool -L eth1 combined 10
    $ sudo ethtool -X eth1 default
    $ sudo ethtool -x eth1
    RX flow hash indirection table for eth1 with 10 RX ring(s):
        0:      0     1     2     3     4     5     6     7
        8:      8     9     0     1     2     3     4     5
       16:      6     7     8     9     0     1     2     3
       24:      4     5     6     7     8     9     0     1
       ...
    
    Fixes: 1c7cf0784e4d ("ixgbe: support for ethtool set_rxfh")
    Signed-off-by: Joe Damato <[email protected]>
    Reviewed-by: Sridhar Samudrala <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ixgbe: Enable setting RSS table to default values [+ + +]
Author: Joe Damato <[email protected]>
Date:   Sun Apr 16 19:12:23 2023 +0000

    ixgbe: Enable setting RSS table to default values
    
    [ Upstream commit e85d3d55875f7a1079edfbc4e4e98d6f8aea9ac7 ]
    
    ethtool uses `ETHTOOL_GRXRINGS` to compute how many queues are supported
    by RSS. The driver should return the smaller of either:
      - The maximum number of RSS queues the device supports, OR
      - The number of RX queues configured
    
    Prior to this change, running `ethtool -X $iface default` fails if the
    number of queues configured is larger than the number supported by RSS,
    even though changing the queue count correctly resets the flowhash to
    use all supported queues.
    
    Other drivers (for example, i40e) will succeed but the flow hash will
    reset to support the maximum number of queues supported by RSS, even if
    that amount is smaller than the configured amount.
    
    Prior to this change:
    
    $ sudo ethtool -L eth1 combined 20
    $ sudo ethtool -x eth1
    RX flow hash indirection table for eth1 with 20 RX ring(s):
        0:      0     1     2     3     4     5     6     7
        8:      8     9    10    11    12    13    14    15
       16:      0     1     2     3     4     5     6     7
       24:      8     9    10    11    12    13    14    15
       32:      0     1     2     3     4     5     6     7
    ...
    
    You can see that the flowhash was correctly set to use the maximum
    number of queues supported by the driver (16).
    
    However, asking the NIC to reset to "default" fails:
    
    $ sudo ethtool -X eth1 default
    Cannot set RX flow hash configuration: Invalid argument
    
    After this change, the flowhash can be reset to default which will use
    all of the available RSS queues (16) or the configured queue count,
    whichever is smaller.
    
    Starting with eth1 which has 10 queues and a flowhash distributing to
    all 10 queues:
    
    $ sudo ethtool -x eth1
    RX flow hash indirection table for eth1 with 10 RX ring(s):
        0:      0     1     2     3     4     5     6     7
        8:      8     9     0     1     2     3     4     5
       16:      6     7     8     9     0     1     2     3
    ...
    
    Increasing the queue count to 48 resets the flowhash to distribute to 16
    queues, as it did before this patch:
    
    $ sudo ethtool -L eth1 combined 48
    $ sudo ethtool -x eth1
    RX flow hash indirection table for eth1 with 16 RX ring(s):
        0:      0     1     2     3     4     5     6     7
        8:      8     9    10    11    12    13    14    15
       16:      0     1     2     3     4     5     6     7
    ...
    
    Due to the other bugfix in this series, the flowhash can be set to use
    queues 0-5:
    
    $ sudo ethtool -X eth1 equal 5
    $ sudo ethtool -x eth1
    RX flow hash indirection table for eth1 with 16 RX ring(s):
        0:      0     1     2     3     4     0     1     2
        8:      3     4     0     1     2     3     4     0
       16:      1     2     3     4     0     1     2     3
    ...
    
    Due to this bugfix, the flowhash can be reset to default and use 16
    queues:
    
    $ sudo ethtool -X eth1 default
    $ sudo ethtool -x eth1
    RX flow hash indirection table for eth1 with 16 RX ring(s):
        0:      0     1     2     3     4     5     6     7
        8:      8     9    10    11    12    13    14    15
       16:      0     1     2     3     4     5     6     7
    ...
    
    Fixes: 91cd94bfe4f0 ("ixgbe: add basic support for setting and getting nfc controls")
    Signed-off-by: Joe Damato <[email protected]>
    Reviewed-by: Sridhar Samudrala <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
jdb2: Don't refuse invalidation of already invalidated buffers [+ + +]
Author: Jan Kara <[email protected]>
Date:   Wed Mar 29 17:49:32 2023 +0200

    jdb2: Don't refuse invalidation of already invalidated buffers
    
    [ Upstream commit bd159398a2d2234de07d310132865706964aaaa7 ]
    
    When invalidating buffers under the partial tail page,
    jbd2_journal_invalidate_folio() returns -EBUSY if the buffer is part of
    the committing transaction as we cannot safely modify buffer state.
    However if the buffer is already invalidated (due to previous
    invalidation attempts from ext4_wait_for_tail_page_commit()), there's
    nothing to do and there's no point in returning -EBUSY. This fixes
    occasional warnings from ext4_journalled_invalidate_folio() triggered by
    generic/051 fstest when blocksize < pagesize.
    
    Fixes: 53e872681fed ("ext4: fix deadlock in journal_unmap_buffer()")
    Signed-off-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kheaders: Use array declaration instead of char [+ + +]
Author: Kees Cook <[email protected]>
Date:   Thu Mar 2 14:49:50 2023 -0800

    kheaders: Use array declaration instead of char
    
    commit b69edab47f1da8edd8e7bfdf8c70f51a2a5d89fb upstream.
    
    Under CONFIG_FORTIFY_SOURCE, memcpy() will check the size of destination
    and source buffers. Defining kernel_headers_data as "char" would trip
    this check. Since these addresses are treated as byte arrays, define
    them as arrays (as done everywhere else).
    
    This was seen with:
    
      $ cat /sys/kernel/kheaders.tar.xz >> /dev/null
    
      detected buffer overflow in memcpy
      kernel BUG at lib/string_helpers.c:1027!
      ...
      RIP: 0010:fortify_panic+0xf/0x20
      [...]
      Call Trace:
       <TASK>
       ikheaders_read+0x45/0x50 [kheaders]
       kernfs_fop_read_iter+0x1a4/0x2f0
      ...
    
    Reported-by: Jakub Kicinski <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]/
    Acked-by: Joel Fernandes (Google) <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Tested-by: Jakub Kicinski <[email protected]>
    Fixes: 43d8ce9d65a5 ("Provide in-kernel headers to make extending kernel easier")
    Cc: [email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/20230302224946.never.243-kees@kernel.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Apr 19 13:16:13 2023 +0300

    KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
    
    commit a25bc8486f9c01c1af6b6c5657234b2eee2c39d6 upstream.
    
    The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
    between 0-32768 but if it is more than sizeof(long) this will corrupt
    memory.
    
    Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Reviewed-by: Eric Auger <[email protected]>
    Reviewed-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Oliver Upton <[email protected]>
    [will: kvm_arm_set_fw_reg() lives in psci.c not hypercalls.c]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: Fix steal time asm constraints [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:41 2023 +0000

    KVM: Fix steal time asm constraints
    
    From: David Woodhouse <[email protected]>
    
    commit 964b7aa0b040bdc6ec1c543ee620cda3f8b4c68a upstream.
    
    In 64-bit mode, x86 instruction encoding allows us to use the low 8 bits
    of any GPR as an 8-bit operand. In 32-bit mode, however, we can only use
    the [abcd] registers. For which, GCC has the "q" constraint instead of
    the less restrictive "r".
    
    Also fix st->preempted, which is an input/output operand rather than an
    input.
    
    Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: nVMX: Emulate NOPs in L2, and PAUSE if it's not intercepted [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Tue Apr 4 17:23:59 2023 -0700

    KVM: nVMX: Emulate NOPs in L2, and PAUSE if it's not intercepted
    
    commit 4984563823f0034d3533854c1b50e729f5191089 upstream.
    
    Extend VMX's nested intercept logic for emulated instructions to handle
    "pause" interception, in quotes because KVM's emulator doesn't filter out
    NOPs when checking for nested intercepts.  Failure to allow emulation of
    NOPs results in KVM injecting a #UD into L2 on any NOP that collides with
    the emulator's definition of PAUSE, i.e. on all single-byte NOPs.
    
    For PAUSE itself, honor L1's PAUSE-exiting control, but ignore PLE to
    avoid unnecessarily injecting a #UD into L2.  Per the SDM, the first
    execution of PAUSE after VM-Entry is treated as the beginning of a new
    loop, i.e. will never trigger a PLE VM-Exit, and so L1 can't expect any
    given execution of PAUSE to deterministically exit.
    
      ... the processor considers this execution to be the first execution of
      PAUSE in a loop. (It also does so for the first execution of PAUSE at
      CPL 0 after VM entry.)
    
    All that said, the PLE side of things is currently a moot point, as KVM
    doesn't expose PLE to L1.
    
    Note, vmx_check_intercept() is still wildly broken when L1 wants to
    intercept an instruction, as KVM injects a #UD instead of synthesizing a
    nested VM-Exit.  That issue extends far beyond NOP/PAUSE and needs far
    more effort to fix, i.e. is a problem for the future.
    
    Fixes: 07721feee46b ("KVM: nVMX: Don't emulate instructions in guest mode")
    Cc: Mathias Krause <[email protected]>
    Cc: [email protected]
    Reviewed-by: Paolo Bonzini <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: do not report a vCPU as preempted outside instruction boundaries [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Tue Jun 7 10:09:03 2022 -0400

    KVM: x86: do not report a vCPU as preempted outside instruction boundaries
    
    commit 6cd88243c7e03845a450795e134b488fc2afb736 upstream.
    
    If a vCPU is outside guest mode and is scheduled out, it might be in the
    process of making a memory access.  A problem occurs if another vCPU uses
    the PV TLB flush feature during the period when the vCPU is scheduled
    out, and a virtual address has already been translated but has not yet
    been accessed, because this is equivalent to using a stale TLB entry.
    
    To avoid this, only report a vCPU as preempted if sure that the guest
    is at an instruction boundary.  A rescheduling request will be delivered
    to the host physical CPU as an external interrupt, so for simplicity
    consider any vmexit *not* instruction boundary except for external
    interrupts.
    
    It would in principle be okay to report the vCPU as preempted also
    if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
    vmentry/vmexit overhead unnecessarily, and optimistic spinning is
    also unlikely to succeed.  However, leave it for later because right
    now kvm_vcpu_check_block() is doing memory accesses.  Even
    though the TLB flush issue only applies to virtual memory address,
    it's very much preferrable to be conservative.
    
    Reported-by: Jann Horn <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    [OP: use VCPU_STAT() for debugfs entries]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: do not report preemption if the steal time cache is stale [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:46 2023 +0000

    KVM: x86: do not report preemption if the steal time cache is stale
    
    From: Paolo Bonzini <[email protected]>
    
    commit c3c28d24d910a746b02f496d190e0e8c6560224b upstream.
    
    Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time
    / preempted status", 2021-11-11) open coded the previous call to
    kvm_map_gfn, but in doing so it dropped the comparison between the cached
    guest physical address and the one in the MSR.  This cause an incorrect
    cache hit if the guest modifies the steal time address while the memslots
    remain the same.  This can happen with kexec, in which case the preempted
    bit is written at the address used by the old kernel instead of
    the old one.
    
    Cc: David Woodhouse <[email protected]>
    Cc: [email protected]
    Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: do not set st->preempted when going back to user space [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:43 2023 +0000

    KVM: x86: do not set st->preempted when going back to user space
    
    From: Paolo Bonzini <[email protected]>
    
    commit 54aa83c90198e68eee8b0850c749bc70efb548da upstream.
    
    Similar to the Xen path, only change the vCPU's reported state if the vCPU
    was actually preempted.  The reason for KVM's behavior is that for example
    optimistic spinning might not be a good idea if the guest is doing repeated
    exits to userspace; however, it is confusing and unlikely to make a difference,
    because well-tuned guests will hardly ever exit KVM_RUN in the first place.
    
    Suggested-by: Sean Christopherson <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    [[email protected]: Don't check for xen msr as support is not available
    and skip the SEV-ES condition]
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Ensure PV TLB flush tracepoint reflects KVM behavior [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:39 2023 +0000

    KVM: x86: Ensure PV TLB flush tracepoint reflects KVM behavior
    
    From: Lai Jiangshan <[email protected]>
    
    commit af3511ff7fa2107d6410831f3d71030f5e8d2b25 upstream.
    
    In record_steal_time(), st->preempted is read twice, and
    trace_kvm_pv_tlb_flush() might output result inconsistent if
    kvm_vcpu_flush_tlb_guest() see a different st->preempted later.
    
    It is a very trivial problem and hardly has actual harm and can be
    avoided by reseting and reading st->preempted in atomic way via xchg().
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Fix recording of guest steal time / preempted status [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:40 2023 +0000

    KVM: x86: Fix recording of guest steal time / preempted status
    
    From: David Woodhouse <[email protected]>
    
    commit 7e2175ebd695f17860c5bd4ad7616cce12ed4591 upstream.
    
    In commit b043138246a4 ("x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is
    not missed") we switched to using a gfn_to_pfn_cache for accessing the
    guest steal time structure in order to allow for an atomic xchg of the
    preempted field. This has a couple of problems.
    
    Firstly, kvm_map_gfn() doesn't work at all for IOMEM pages when the
    atomic flag is set, which it is in kvm_steal_time_set_preempted(). So a
    guest vCPU using an IOMEM page for its steal time would never have its
    preempted field set.
    
    Secondly, the gfn_to_pfn_cache is not invalidated in all cases where it
    should have been. There are two stages to the GFN->PFN conversion;
    first the GFN is converted to a userspace HVA, and then that HVA is
    looked up in the process page tables to find the underlying host PFN.
    Correct invalidation of the latter would require being hooked up to the
    MMU notifiers, but that doesn't happen---so it just keeps mapping and
    unmapping the *wrong* PFN after the userspace page tables change.
    
    In the !IOMEM case at least the stale page *is* pinned all the time it's
    cached, so it won't be freed and reused by anyone else while still
    receiving the steal time updates. The map/unmap dance only takes care
    of the KVM administrivia such as marking the page dirty.
    
    Until the gfn_to_pfn cache handles the remapping automatically by
    integrating with the MMU notifiers, we might as well not get a
    kernel mapping of it, and use the perfectly serviceable userspace HVA
    that we already have.  We just need to implement the atomic xchg on
    the userspace address with appropriate exception handling, which is
    fairly trivial.
    
    Cc: [email protected]
    Fixes: b043138246a4 ("x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is not missed")
    Signed-off-by: David Woodhouse <[email protected]>
    Message-Id: <[email protected]>
    [I didn't entirely agree with David's assessment of the
     usefulness of the gfn_to_pfn cache, and integrated the outcome
     of the discussion in the above commit message. - Paolo]
    Signed-off-by: Paolo Bonzini <[email protected]>
    [[email protected]: Use the older mark_page_dirty_in_slot api without
    kvm argument]
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: hyper-v: Avoid calling kvm_make_vcpus_request_mask() with vcpu_mask==NULL [+ + +]
Author: Vitaly Kuznetsov <[email protected]>
Date:   Fri Sep 3 09:51:36 2021 +0200

    KVM: x86: hyper-v: Avoid calling kvm_make_vcpus_request_mask() with vcpu_mask==NULL
    
    commit 6470accc7ba948b0b3aca22b273fe84ec638a116 upstream.
    
    In preparation to making kvm_make_vcpus_request_mask() use for_each_set_bit()
    switch kvm_hv_flush_tlb() to calling kvm_make_all_cpus_request() for 'all cpus'
    case.
    
    Note: kvm_make_all_cpus_request() (unlike kvm_make_vcpus_request_mask())
    currently dynamically allocates cpumask on each call and this is suboptimal.
    Both kvm_make_all_cpus_request() and kvm_make_vcpus_request_mask() are
    going to be switched to using pre-allocated per-cpu masks.
    
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Message-Id: <20210903075141.403[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Fixes: 6100066358ee ("KVM: Optimize kvm_make_vcpus_request_mask() a bit")
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: move guest_pv_has out of user_access section [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:47 2023 +0000

    KVM: x86: move guest_pv_has out of user_access section
    
    From: Paolo Bonzini <[email protected]>
    
    commit 3e067fd8503d6205aa0c1c8f48f6b209c592d19c upstream.
    
    When UBSAN is enabled, the code emitted for the call to guest_pv_has
    includes a call to __ubsan_handle_load_invalid_value.  objtool
    complains that this call happens with UACCESS enabled; to avoid
    the warning, pull the calls to user_access_begin into both arms
    of the "if" statement, after the check for guest_pv_has.
    
    Reported-by: Stephen Rothwell <[email protected]>
    Cc: David Woodhouse <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Remove obsolete disabling of page faults in kvm_arch_vcpu_put() [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:42 2023 +0000

    KVM: x86: Remove obsolete disabling of page faults in kvm_arch_vcpu_put()
    
    From: Sean Christopherson <[email protected]>
    
    commit 19979fba9bfaeab427a8e106d915f0627c952828 upstream.
    
    Remove the disabling of page faults across kvm_steal_time_set_preempted()
    as KVM now accesses the steal time struct (shared with the guest) via a
    cached mapping (see commit b043138246a4, "x86/KVM: Make sure
    KVM_VCPU_FLUSH_TLB flag is not missed".)  The cache lookup is flagged as
    atomic, thus it would be a bug if KVM tried to resolve a new pfn, i.e.
    we want the splat that would be reached via might_fault().
    
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: revalidate steal time cache if MSR value changes [+ + +]
Author: Rishabh Bhatnagar <[email protected]>
Date:   Wed May 10 18:15:45 2023 +0000

    KVM: x86: revalidate steal time cache if MSR value changes
    
    From: Paolo Bonzini <[email protected]>
    
    commit 901d3765fa804ce42812f1d5b1f3de2dfbb26723 upstream.
    
    Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time
    / preempted status", 2021-11-11) open coded the previous call to
    kvm_map_gfn, but in doing so it dropped the comparison between the cached
    guest physical address and the one in the MSR.  This cause an incorrect
    cache hit if the guest modifies the steal time address while the memslots
    remain the same.  This can happen with kexec, in which case the steal
    time data is written at the address used by the old kernel instead of
    the old one.
    
    While at it, rename the variable from gfn to gpa since it is a plain
    physical address and not a right-shifted one.
    
    Reported-by: Dave Young <[email protected]>
    Reported-by: Xiaoying Yan  <[email protected]>
    Analyzed-by: Dr. David Alan Gilbert <[email protected]>
    Cc: David Woodhouse <[email protected]>
    Cc: [email protected]
    Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Rishabh Bhatnagar <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
leds: tca6507: Fix error handling of using fwnode_property_read_string [+ + +]
Author: H. Nikolaus Schaller <[email protected]>
Date:   Sun Apr 2 13:12:59 2023 +0200

    leds: tca6507: Fix error handling of using fwnode_property_read_string
    
    [ Upstream commit c1087c29e96a48e9080377e168d35dcb52fb068b ]
    
    Commit 96f524105b9c ("leds: tca6507: use fwnode API instead of OF")
    
    changed to fwnode API but did not take into account that a missing property
    "linux,default-trigger" now seems to return an error and as a side effect
    sets value to -1. This seems to be different from of_get_property() which
    always returned NULL in any case of error.
    
    Neglecting this side-effect leads to
    
    [   11.201965] Unable to handle kernel paging request at virtual address ffffffff when read
    
    in the strcmp() of led_trigger_set_default() if there is no led-trigger
    defined in the DTS.
    
    I don't know if this was recently introduced somewhere in the fwnode lib
    or if the effect was missed in initial testing. Anyways it seems to be a
    bug to ignore the error return value of an optional value here in the
    driver.
    
    Fixes: 96f524105b9c ("leds: tca6507: use fwnode API instead of OF")
    Signed-off-by: H. Nikolaus Schaller <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Reviewed-by: Marek Behún <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/cbae7617db83113de726fcc423a805ebaa1bfca6.1680433978.git.hns@goldelico.com
    Signed-off-by: Sasha Levin <[email protected]>

leds: TI_LMU_COMMON: select REGMAP instead of depending on it [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sat Feb 25 21:39:49 2023 -0800

    leds: TI_LMU_COMMON: select REGMAP instead of depending on it
    
    [ Upstream commit a61079efc87888587e463afaed82417b162fbd69 ]
    
    REGMAP is a hidden (not user visible) symbol. Users cannot set it
    directly thru "make *config", so drivers should select it instead of
    depending on it if they need it.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on REGMAP" to "select REGMAP".
    
    Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices")
    Signed-off-by: Randy Dunlap <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 5.10.180 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed May 17 11:48:20 2023 +0200

    Linux 5.10.180
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Chris Paterson (CIP) <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
linux/vt_buffer.h: allow either builtin or modular for macros [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Tue Mar 28 19:15:29 2023 -0700

    linux/vt_buffer.h: allow either builtin or modular for macros
    
    [ Upstream commit 2b76ffe81e32afd6d318dc4547e2ba8c46207b77 ]
    
    Fix build errors on ARCH=alpha when CONFIG_MDA_CONSOLE=m.
    This allows the ARCH macros to be the only ones defined.
    
    In file included from ../drivers/video/console/mdacon.c:37:
    ../arch/alpha/include/asm/vga.h:17:40: error: expected identifier or '(' before 'volatile'
       17 | static inline void scr_writew(u16 val, volatile u16 *addr)
          |                                        ^~~~~~~~
    ../include/linux/vt_buffer.h:24:34: note: in definition of macro 'scr_writew'
       24 | #define scr_writew(val, addr) (*(addr) = (val))
          |                                  ^~~~
    ../include/linux/vt_buffer.h:24:40: error: expected ')' before '=' token
       24 | #define scr_writew(val, addr) (*(addr) = (val))
          |                                        ^
    ../arch/alpha/include/asm/vga.h:17:20: note: in expansion of macro 'scr_writew'
       17 | static inline void scr_writew(u16 val, volatile u16 *addr)
          |                    ^~~~~~~~~~
    ../arch/alpha/include/asm/vga.h:25:29: error: expected identifier or '(' before 'volatile'
       25 | static inline u16 scr_readw(volatile const u16 *addr)
          |                             ^~~~~~~~
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Jiri Slaby <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
macintosh/windfarm_smu_sat: Add missing of_node_put() [+ + +]
Author: Liang He <[email protected]>
Date:   Thu Mar 30 11:35:58 2023 +0800

    macintosh/windfarm_smu_sat: Add missing of_node_put()
    
    [ Upstream commit 631cf002826007ab7415258ee647dcaf8845ad5a ]
    
    We call of_node_get() in wf_sat_probe() after sat is created,
    so we need the of_node_put() before *kfree(sat)*.
    
    Fixes: ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s")
    Signed-off-by: Liang He <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
macintosh: via-pmu-led: requires ATA to be set [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 22 17:42:41 2023 -0800

    macintosh: via-pmu-led: requires ATA to be set
    
    [ Upstream commit 05dce4ba125336875cd3eed3c1503fa81cd2f691 ]
    
    LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK
    when ATA is not set/enabled causes a Kconfig warning:
    
    WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK
      Depends on [n]: NEW_LEDS [=y] && LEDS_TRIGGERS [=y] && ATA [=n]
      Selected by [y]:
      - ADB_PMU_LED_DISK [=y] && MACINTOSH_DRIVERS [=y] && ADB_PMU_LED [=y] && LEDS_CLASS [=y]
    
    Fix this by making ADB_PMU_LED_DISK depend on ATA.
    
    Seen on both PPC32 and PPC64.
    
    Fixes: 0e865a80c135 ("macintosh: Remove dependency on IDE_GD_ATA if ADB_PMU_LED_DISK is selected")
    Signed-off-by: Randy Dunlap <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
mailbox: zynq: Switch to flexible array to simplify code [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Nov 20 09:25:54 2022 +0100

    mailbox: zynq: Switch to flexible array to simplify code
    
    [ Upstream commit 043f85ce81cb1714e14d31c322c5646513dde3fb ]
    
    Using flexible array is more straight forward. It
      - saves 1 pointer in the 'zynqmp_ipi_pdata' structure
      - saves an indirection when using this array
      - saves some LoC and avoids some always spurious pointer arithmetic
    
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Jassi Brar <[email protected]>
    Stable-dep-of: f72f805e7288 ("mailbox: zynqmp: Fix counts of child nodes")
    Signed-off-by: Sasha Levin <[email protected]>

mailbox: zynqmp: Fix counts of child nodes [+ + +]
Author: Tanmay Shah <[email protected]>
Date:   Fri Mar 10 17:24:04 2023 -0800

    mailbox: zynqmp: Fix counts of child nodes
    
    [ Upstream commit f72f805e72882c361e2a612c64a6e549f3da7152 ]
    
    If child mailbox node status is disabled it causes
    crash in interrupt handler. Fix this by assigning
    only available child node during driver probe.
    
    Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
    Signed-off-by: Tanmay Shah <[email protected]>
    Acked-by: Michal Simek <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mailbox: zynqmp: Fix IPI isr handling [+ + +]
Author: Tanmay Shah <[email protected]>
Date:   Fri Mar 10 17:24:05 2023 -0800

    mailbox: zynqmp: Fix IPI isr handling
    
    commit 74ad37a30ffee3643bc34f9ca7225b20a66abaaf upstream.
    
    Multiple IPI channels are mapped to same interrupt handler.
    Current isr implementation handles only one channel per isr.
    Fix this behavior by checking isr status bit of all child
    mailbox nodes.
    
    Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
    Signed-off-by: Tanmay Shah <[email protected]>
    Acked-by: Michal Simek <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mailbox: zynqmp: Fix typo in IPI documentation [+ + +]
Author: Tanmay Shah <[email protected]>
Date:   Fri Mar 10 17:24:06 2023 -0800

    mailbox: zynqmp: Fix typo in IPI documentation
    
    commit 79963fbfc233759bd8a43462f120d15a1bd4f4fa upstream.
    
    Xilinx IPI message buffers allows 32-byte data transfer.
    Fix documentation that says 12 bytes
    
    Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
    Signed-off-by: Tanmay Shah <[email protected]>
    Acked-by: Michal Simek <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
md/raid10: fix leak of 'r10bio->remaining' for recovery [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Fri Mar 10 15:38:53 2023 +0800

    md/raid10: fix leak of 'r10bio->remaining' for recovery
    
    [ Upstream commit 26208a7cffd0c7cbf14237ccd20c7270b3ffeb7e ]
    
    raid10_sync_request() will add 'r10bio->remaining' for both rdev and
    replacement rdev. However, if the read io fails, recovery_request_write()
    returns without issuing the write io, in this case, end_sync_request()
    is only called once and 'remaining' is leaked, cause an io hang.
    
    Fix the problem by decreasing 'remaining' according to if 'bio' and
    'repl_bio' is valid.
    
    Fixes: 24afd80d99f8 ("md/raid10: handle recovery of replacement devices.")
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

md/raid10: fix memleak for 'conf->bio_split' [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Fri Mar 10 15:38:54 2023 +0800

    md/raid10: fix memleak for 'conf->bio_split'
    
    [ Upstream commit c9ac2acde53f5385de185bccf6aaa91cf9ac1541 ]
    
    In the error path of raid10_run(), 'conf' need be freed, however,
    'conf->bio_split' is missed and memory will be leaked.
    
    Since there are 3 places to free 'conf', factor out a helper to fix the
    problem.
    
    Fixes: fc9977dd069e ("md/raid10: simplify the splitting of requests.")
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

md/raid10: fix memleak of md thread [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Fri Mar 10 15:38:55 2023 +0800

    md/raid10: fix memleak of md thread
    
    [ Upstream commit f0ddb83da3cbbf8a1f9087a642c448ff52ee9abd ]
    
    In raid10_run(), if setup_conf() succeed and raid10_run() failed before
    setting 'mddev->thread', then in the error path 'conf->thread' is not
    freed.
    
    Fix the problem by setting 'mddev->thread' right after setup_conf().
    
    Fixes: 43a521238aca ("md-cluster: choose correct label when clustered layout is not supported")
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

md/raid10: fix null-ptr-deref in raid10_sync_request [+ + +]
Author: Li Nan <[email protected]>
Date:   Wed Feb 22 12:10:00 2023 +0800

    md/raid10: fix null-ptr-deref in raid10_sync_request
    
    commit a405c6f0229526160aa3f177f65e20c86fce84c5 upstream.
    
    init_resync() inits mempool and sets conf->have_replacemnt at the beginning
    of sync, close_sync() frees the mempool when sync is completed.
    
    After [1] recovery might be skipped and init_resync() is called but
    close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.
    
    The following is one way to reproduce the issue.
    
      1) create a array, wait for resync to complete, mddev->recovery_cp is set
         to MaxSector.
      2) recovery is woken and it is skipped. conf->have_replacement is set to
         0 in init_resync(). close_sync() not called.
      3) some io errors and rdev A is set to WantReplacement.
      4) a new device is added and set to A's replacement.
      5) recovery is woken, A have replacement, but conf->have_replacemnt is
         0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref
         occurs.
    
    Fix it by not calling init_resync() if recovery skipped.
    
    [1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
    Fixes: 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
    Cc: [email protected]
    Signed-off-by: Li Nan <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
media: bdisp: Add missing check for create_workqueue [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Wed Feb 8 08:14:42 2023 +0100

    media: bdisp: Add missing check for create_workqueue
    
    [ Upstream commit 2371adeab717d8fe32144a84f3491a03c5838cfb ]
    
    Add the check for the return value of the create_workqueue
    in order to avoid NULL pointer dereference.
    
    Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework")
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dm1105: Fix use after free bug in dm1105_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Sat Mar 18 16:15:06 2023 +0800

    media: dm1105: Fix use after free bug in dm1105_remove due to race condition
    
    [ Upstream commit 5abda7a16698d4d1f47af1168d8fa2c640116b4a ]
    
    In dm1105_probe, it called dm1105_ir_init and bound
    &dm1105->ir.work with dm1105_emit_key.
    When it handles IRQ request with dm1105_irq,
    it may call schedule_work to start the work.
    
    When we call dm1105_remove to remove the driver, there
    may be a sequence as follows:
    
    Fix it by finishing the work before cleanup in dm1105_remove
    
    CPU0                  CPU1
    
                        |dm1105_emit_key
    dm1105_remove      |
      dm1105_ir_exit       |
        rc_unregister_device |
        rc_free_device  |
        rc_dev_release  |
        kfree(dev);     |
                        |
                        | rc_keydown
                        |   //use
    
    Fixes: 34d2f9bf189c ("V4L/DVB: dm1105: use dm1105_dev & dev instead of dm1105dvb")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: max9286: Free control handler [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Sat Jan 14 22:46:50 2023 +0100

    media: max9286: Free control handler
    
    [ Upstream commit bfce6a12e5ba1edde95126aa06778027f16115d4 ]
    
    The control handler is leaked in some probe-time error paths, as well as
    in the remove path. Fix it.
    
    Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver")
    Signed-off-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Niklas Söderlund <[email protected]>
    Reviewed-by: Jacopo Mondi <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rc: gpio-ir-recv: Fix support for wake-up [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Fri Mar 24 13:38:33 2023 -0700

    media: rc: gpio-ir-recv: Fix support for wake-up
    
    [ Upstream commit 9c592f8ab114875fdb3b2040f01818e53de44991 ]
    
    The driver was intended from the start to be a wake-up source for the
    system, however due to the absence of a suitable call to
    device_set_wakeup_capable(), the device_may_wakeup() call used to decide
    whether to enable the GPIO interrupt as a wake-up source would never
    happen. Lookup the DT standard "wakeup-source" property and call
    device_init_wakeup() to ensure the device is flagged as being wakeup
    capable.
    
    Reported-by: Matthew Lear <[email protected]>
    Fixes: fd0f6851eb46 ("[media] rc: Add support for GPIO based IR Receiver driver")
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sean Young <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rcar_fdp1: fix pm_runtime_get_sync() usage count [+ + +]
Author: Mauro Carvalho Chehab <[email protected]>
Date:   Fri Apr 23 16:59:34 2021 +0200

    media: rcar_fdp1: fix pm_runtime_get_sync() usage count
    
    [ Upstream commit 45e75a8c6fa455a5909ac04db76a4b15d6bb8368 ]
    
    The pm_runtime_get_sync() internally increments the
    dev->power.usage_count without decrementing it, even on errors.
    Replace it by the new pm_runtime_resume_and_get(), introduced by:
    commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
    in order to properly decrement the usage counter, avoiding
    a potential PM usage counter leak.
    
    Also, right now, the driver is ignoring any troubles when
    trying to do PM resume. So, add the proper error handling
    for the code.
    
    Reviewed-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: c766c90faf93 ("media: rcar_fdp1: Fix refcount leak in probe and remove function")
    Signed-off-by: Sasha Levin <[email protected]>

media: rcar_fdp1: Fix refcount leak in probe and remove function [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Fri Jan 6 11:58:09 2023 +0400

    media: rcar_fdp1: Fix refcount leak in probe and remove function
    
    [ Upstream commit c766c90faf93897b77c9c5daa603cffab85ba907 ]
    
    rcar_fcp_get() take reference, which should be balanced with
    rcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove and
    the error paths of fdp1_probe() to fix this.
    
    Fixes: 4710b752e029 ("[media] v4l: Add Renesas R-Car FDP1 Driver")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    [hverkuil: resolve merge conflict, remove() is now void]
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rcar_fdp1: Fix the correct variable assignments [+ + +]
Author: Tang Bin <[email protected]>
Date:   Thu Oct 21 05:09:38 2021 +0200

    media: rcar_fdp1: Fix the correct variable assignments
    
    [ Upstream commit af88c2adbb72a09ab1bb5c37ba388c98fecca69b ]
    
    In the function fdp1_probe(), when get irq failed, the
    function platform_get_irq() log an error message, so
    remove redundant message here. And the variable type
    of "ret" is int, the "fdp1->irq" is unsigned int, when
    irq failed, this place maybe wrong, thus fix it.
    
    Signed-off-by: Tang Bin <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Kieran Bingham <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: c766c90faf93 ("media: rcar_fdp1: Fix refcount leak in probe and remove function")
    Signed-off-by: Sasha Levin <[email protected]>

media: rcar_fdp1: Make use of the helper function devm_platform_ioremap_resource() [+ + +]
Author: Cai Huoqing <[email protected]>
Date:   Wed Sep 1 07:55:24 2021 +0200

    media: rcar_fdp1: Make use of the helper function devm_platform_ioremap_resource()
    
    [ Upstream commit 736cce12fa630e28705de06570d74f0513d948d5 ]
    
    Use the devm_platform_ioremap_resource() helper instead of
    calling platform_get_resource() and devm_ioremap_resource()
    separately
    
    Signed-off-by: Cai Huoqing <[email protected]>
    Reviewed-by: Kieran Bingham <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: c766c90faf93 ("media: rcar_fdp1: Fix refcount leak in probe and remove function")
    Signed-off-by: Sasha Levin <[email protected]>

media: rcar_fdp1: simplify error check logic at fdp_open() [+ + +]
Author: Mauro Carvalho Chehab <[email protected]>
Date:   Fri Apr 23 16:59:34 2021 +0200

    media: rcar_fdp1: simplify error check logic at fdp_open()
    
    [ Upstream commit fa9f443f7c962d072d150472e2bb77de39817a9a ]
    
    Avoid some code duplication by moving the common error path
    logic at fdp_open().
    
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: c766c90faf93 ("media: rcar_fdp1: Fix refcount leak in probe and remove function")
    Signed-off-by: Sasha Levin <[email protected]>

media: rkvdec: fix use after free bug in rkvdec_remove [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Mon Mar 13 16:42:20 2023 +0000

    media: rkvdec: fix use after free bug in rkvdec_remove
    
    [ Upstream commit 3228cec23b8b29215e18090c6ba635840190993d ]
    
    In rkvdec_probe, rkvdec->watchdog_work is bound with
    rkvdec_watchdog_func. Then rkvdec_vp9_run may
    be called to start the work.
    
    If we remove the module which will call rkvdec_remove
     to make cleanup, there may be a unfinished work.
     The possible sequence is as follows, which will
     cause a typical UAF bug.
    
    Fix it by canceling the work before cleanup in rkvdec_remove.
    
    CPU0                  CPU1
    
                        |rkvdec_watchdog_func
    rkvdec_remove       |
     rkvdec_v4l2_cleanup|
      v4l2_m2m_release  |
        kfree(m2m_dev); |
                        |
                        | v4l2_m2m_get_curr_priv
                        |   m2m_dev->curr_ctx //use
    
    Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: saa7134: fix use after free bug in saa7134_finidev due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Sat Mar 18 16:50:23 2023 +0800

    media: saa7134: fix use after free bug in saa7134_finidev due to race condition
    
    [ Upstream commit 30cf57da176cca80f11df0d9b7f71581fe601389 ]
    
    In saa7134_initdev, it will call saa7134_hwinit1. There are three
    function invoking here: saa7134_video_init1, saa7134_ts_init1
    and saa7134_vbi_init1.
    
    All of them will init a timer with same function. Take
    saa7134_video_init1 as an example. It'll bound &dev->video_q.timeout
    with saa7134_buffer_timeout.
    
    In buffer_activate, the timer funtcion is started.
    
    If we remove the module or device which will call saa7134_finidev
    to make cleanup, there may be a unfinished work. The
    possible sequence is as follows, which will cause a
    typical UAF bug.
    
    Fix it by canceling the timer works accordingly before cleanup in
    saa7134_finidev.
    
    CPU0                  CPU1
    
                        |saa7134_buffer_timeout
    saa7134_finidev     |
      kfree(dev);       |
                        |
                        | saa7134_buffer_next
                        | //use dev
    
    Fixes: 1e7126b4a86a ("media: saa7134: Convert timers to use timer_setup()")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: venus: dec: Fix handling of the start cmd [+ + +]
Author: Michał Krawczyk <[email protected]>
Date:   Mon Jan 30 13:54:18 2023 +0000

    media: venus: dec: Fix handling of the start cmd
    
    [ Upstream commit 50248ad9f190d527cbd578190ca769729518b703 ]
    
    The decoder driver should clear the last_buffer_dequeued flag of the
    capture queue upon receiving V4L2_DEC_CMD_START.
    
    The last_buffer_dequeued flag is set upon receiving EOS (which always
    happens upon receiving V4L2_DEC_CMD_STOP).
    
    Without this patch, after issuing the V4L2_DEC_CMD_STOP and
    V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if
    the buffers are completed by the hardware.
    
    Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API")
    
    Signed-off-by: Michał Krawczyk <[email protected]>
    Signed-off-by: Stanimir Varbanov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: venus: preserve DRC state across seeks [+ + +]
Author: Alexandre Courbot <[email protected]>
Date:   Wed Dec 2 06:34:24 2020 +0100

    media: venus: preserve DRC state across seeks
    
    [ Upstream commit d5ee32d7e5929592ad9b6e7a919dcdf89d05221b ]
    
    DRC events can happen virtually at anytime, including when we are
    starting a seek. Should this happen, we must make sure to return to the
    DRC state, otherwise the firmware will expect buffers of the new
    resolution whereas userspace will still work with the old one.
    
    Returning to the DRC state upon resume for seeking makes sure that the
    client will get the DRC event and will reallocate the buffers to fit the
    firmware's expectations.
    
    Signed-off-by: Alexandre Courbot <[email protected]>
    Signed-off-by: Stanimir Varbanov <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 50248ad9f190 ("media: venus: dec: Fix handling of the start cmd")
    Signed-off-by: Sasha Levin <[email protected]>

media: venus: vdec: Fix non reliable setting of LAST flag [+ + +]
Author: Stanimir Varbanov <[email protected]>
Date:   Mon Sep 28 18:44:29 2020 +0200

    media: venus: vdec: Fix non reliable setting of LAST flag
    
    [ Upstream commit acf8a57d8caf5ceabbe50774953fe04745ad1a50 ]
    
    In real use of dynamic-resolution-change it is observed that the
    LAST buffer flag (which marks the last decoded buffer with the
    resolution before the resolution-change event) is not reliably set.
    
    Fix this by set the LAST buffer flag on next queued capture buffer
    after the resolution-change event.
    
    Signed-off-by: Stanimir Varbanov <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 50248ad9f190 ("media: venus: dec: Fix handling of the start cmd")
    Signed-off-by: Sasha Levin <[email protected]>

media: venus: vdec: Handle DRC after drain [+ + +]
Author: Fritz Koenig <[email protected]>
Date:   Tue Dec 1 05:23:23 2020 +0100

    media: venus: vdec: Handle DRC after drain
    
    [ Upstream commit c8e8dabcd1a8c7aaedc514052d383a8152119084 ]
    
    If the DRC is near the end of the stream the client
    may send a V4L2_DEC_CMD_STOP before the DRC occurs.
    V4L2_DEC_CMD_STOP puts the driver into the
    VENUS_DEC_STATE_DRAIN state.  DRC must be aware so
    that after the DRC event the state can be restored
    correctly.
    
    Signed-off-by: Fritz Koenig <[email protected]>
    Signed-off-by: Stanimir Varbanov <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 50248ad9f190 ("media: venus: dec: Fix handling of the start cmd")
    Signed-off-by: Sasha Levin <[email protected]>

media: venus: vdec: Make decoder return LAST flag for sufficient event [+ + +]
Author: Stanimir Varbanov <[email protected]>
Date:   Mon Sep 28 18:44:30 2020 +0200

    media: venus: vdec: Make decoder return LAST flag for sufficient event
    
    [ Upstream commit a4ca67af8b831a781ac53060c5d5c3dccaf7676e ]
    
    This makes the decoder to behaives equally for sufficient and
    insufficient events. After this change the LAST buffer flag will be set
    when the new resolution (in dynamic-resolution-change state) is smaller
    then the old bitstream resolution.
    
    Signed-off-by: Stanimir Varbanov <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 50248ad9f190 ("media: venus: dec: Fix handling of the start cmd")
    Signed-off-by: Sasha Levin <[email protected]>

 
mfd: tqmx86: Add support for TQMx110EB and TQMxE40x [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Fri Jul 16 12:00:51 2021 +0200

    mfd: tqmx86: Add support for TQMx110EB and TQMxE40x
    
    [ Upstream commit 3da48ccb1d0f3b53b1e8c9022edbedc2a6e3f50a ]
    
    Add the board IDs for the TQMx110EB and the TQMxE40x family. All use a
    24MHz LPC clock.
    
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Stable-dep-of: 051c69ff4f60 ("mfd: tqmx86: Specify IO port register range more precisely")
    Signed-off-by: Sasha Levin <[email protected]>

mfd: tqmx86: Correct board names for TQMxE39x [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Mon Feb 20 12:25:46 2023 +0100

    mfd: tqmx86: Correct board names for TQMxE39x
    
    [ Upstream commit f376c479668557bcc2fd9e9fbc0f53e7819a11cd ]
    
    It seems that this driver was developed based on preliminary documentation.
    Report the correct names for all TQMxE39x variants, as they are used by
    the released hardware revisions:
    
    - Fix names for TQMxE39C1/C2 board IDs
    - Distinguish TQMxE39M and TQMxE39S, which use the same board ID
    
    The TQMxE39M/S are distinguished using the SAUC (Sanctioned Alternate
    Uses Configuration) register of the GPIO controller. This also prepares
    for the correct handling of the differences between the GPIO controllers
    of our COMe and SMARC modules.
    
    Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO")
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/aca9a7cb42a85181bcb456c437554d2728e708ec.1676892223.git.matthias.schiffer@ew.tq-group.com
    Signed-off-by: Sasha Levin <[email protected]>

mfd: tqmx86: Do not access I2C_DETECT register through io_base [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Mon Feb 20 12:25:44 2023 +0100

    mfd: tqmx86: Do not access I2C_DETECT register through io_base
    
    [ Upstream commit 1be1b23696b3d4b0231c694f5e0767b4471d33a9 ]
    
    The I2C_DETECT register is at IO port 0x1a7, which is outside the range
    passed to devm_ioport_map() for io_base, and was only working because
    there aren't actually any bounds checks for IO port accesses.
    
    Extending the range does not seem like a good solution here, as it would
    then conflict with the IO resource assigned to the I2C controller. As
    this is just a one-off access during probe, use a simple inb() instead.
    
    While we're at it, drop the unused define TQMX86_REG_I2C_INT_EN.
    
    Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO")
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/e8300a30f0791afb67d79db8089fb6004855f378.1676892223.git.matthias.schiffer@ew.tq-group.com
    Signed-off-by: Sasha Levin <[email protected]>

mfd: tqmx86: Remove incorrect TQMx90UC board ID [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Fri Jul 16 12:00:49 2021 +0200

    mfd: tqmx86: Remove incorrect TQMx90UC board ID
    
    [ Upstream commit 16b2ad150f74db0eb91f445061f16140b5aaa650 ]
    
    No TQMx90UC exists at the moment, and it is undecided whether ID 10 will
    be used eventually (and if it is, how that SoM will be named).
    
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Stable-dep-of: 051c69ff4f60 ("mfd: tqmx86: Specify IO port register range more precisely")
    Signed-off-by: Sasha Levin <[email protected]>

mfd: tqmx86: Specify IO port register range more precisely [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Mon Feb 20 12:25:45 2023 +0100

    mfd: tqmx86: Specify IO port register range more precisely
    
    [ Upstream commit 051c69ff4f607aa114c7bbdd7c41ed881367aeee ]
    
    Registers 0x160..0x17f are unassigned. Use 0x180 as base register and
    update offets accordingly.
    
    Also change the size of the range to include 0x19f. While 0x19f is
    currently reserved for future extensions, so are several of the previous
    registers up to 0x19e, and it is weird to leave out just the last one.
    
    Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO")
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/db4677ac318b1283c8956f637f409995a30a31c3.1676892223.git.matthias.schiffer@ew.tq-group.com
    Signed-off-by: Sasha Levin <[email protected]>

 
MIPS: fw: Allow firmware to pass a empty env [+ + +]
Author: Jiaxun Yang <[email protected]>
Date:   Tue Apr 11 12:14:26 2023 +0100

    MIPS: fw: Allow firmware to pass a empty env
    
    commit ee1809ed7bc456a72dc8410b475b73021a3a68d5 upstream.
    
    fw_getenv will use env entry to determine style of env,
    however it is legal for firmware to just pass a empty list.
    
    Check if first entry exist before running strchr to avoid
    null pointer dereference.
    
    Cc: [email protected]
    Link: https://github.com/clbr/n64bootloader/issues/5
    Signed-off-by: Jiaxun Yang <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock [+ + +]
Author: Tetsuo Handa <[email protected]>
Date:   Tue Apr 4 23:31:58 2023 +0900

    mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock
    
    commit 1007843a91909a4995ee78a538f62d8665705b66 upstream.
    
    syzbot is reporting circular locking dependency which involves
    zonelist_update_seq seqlock [1], for this lock is checked by memory
    allocation requests which do not need to be retried.
    
    One deadlock scenario is kmalloc(GFP_ATOMIC) from an interrupt handler.
    
      CPU0
      ----
      __build_all_zonelists() {
        write_seqlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount odd
        // e.g. timer interrupt handler runs at this moment
          some_timer_func() {
            kmalloc(GFP_ATOMIC) {
              __alloc_pages_slowpath() {
                read_seqbegin(&zonelist_update_seq) {
                  // spins forever because zonelist_update_seq.seqcount is odd
                }
              }
            }
          }
        // e.g. timer interrupt handler finishes
        write_sequnlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount even
      }
    
    This deadlock scenario can be easily eliminated by not calling
    read_seqbegin(&zonelist_update_seq) from !__GFP_DIRECT_RECLAIM allocation
    requests, for retry is applicable to only __GFP_DIRECT_RECLAIM allocation
    requests.  But Michal Hocko does not know whether we should go with this
    approach.
    
    Another deadlock scenario which syzbot is reporting is a race between
    kmalloc(GFP_ATOMIC) from tty_insert_flip_string_and_push_buffer() with
    port->lock held and printk() from __build_all_zonelists() with
    zonelist_update_seq held.
    
      CPU0                                   CPU1
      ----                                   ----
      pty_write() {
        tty_insert_flip_string_and_push_buffer() {
                                             __build_all_zonelists() {
                                               write_seqlock(&zonelist_update_seq);
                                               build_zonelists() {
                                                 printk() {
                                                   vprintk() {
                                                     vprintk_default() {
                                                       vprintk_emit() {
                                                         console_unlock() {
                                                           console_flush_all() {
                                                             console_emit_next_record() {
                                                               con->write() = serial8250_console_write() {
          spin_lock_irqsave(&port->lock, flags);
          tty_insert_flip_string() {
            tty_insert_flip_string_fixed_flag() {
              __tty_buffer_request_room() {
                tty_buffer_alloc() {
                  kmalloc(GFP_ATOMIC | __GFP_NOWARN) {
                    __alloc_pages_slowpath() {
                      zonelist_iter_begin() {
                        read_seqbegin(&zonelist_update_seq); // spins forever because zonelist_update_seq.seqcount is odd
                                                                 spin_lock_irqsave(&port->lock, flags); // spins forever because port->lock is held
                        }
                      }
                    }
                  }
                }
              }
            }
          }
          spin_unlock_irqrestore(&port->lock, flags);
                                                                 // message is printed to console
                                                                 spin_unlock_irqrestore(&port->lock, flags);
                                                               }
                                                             }
                                                           }
                                                         }
                                                       }
                                                     }
                                                   }
                                                 }
                                               }
                                               write_sequnlock(&zonelist_update_seq);
                                             }
        }
      }
    
    This deadlock scenario can be eliminated by
    
      preventing interrupt context from calling kmalloc(GFP_ATOMIC)
    
    and
    
      preventing printk() from calling console_flush_all()
    
    while zonelist_update_seq.seqcount is odd.
    
    Since Petr Mladek thinks that __build_all_zonelists() can become a
    candidate for deferring printk() [2], let's address this problem by
    
      disabling local interrupts in order to avoid kmalloc(GFP_ATOMIC)
    
    and
    
      disabling synchronous printk() in order to avoid console_flush_all()
    
    .
    
    As a side effect of minimizing duration of zonelist_update_seq.seqcount
    being odd by disabling synchronous printk(), latency at
    read_seqbegin(&zonelist_update_seq) for both !__GFP_DIRECT_RECLAIM and
    __GFP_DIRECT_RECLAIM allocation requests will be reduced.  Although, from
    lockdep perspective, not calling read_seqbegin(&zonelist_update_seq) (i.e.
    do not record unnecessary locking dependency) from interrupt context is
    still preferable, even if we don't allow calling kmalloc(GFP_ATOMIC)
    inside
    write_seqlock(&zonelist_update_seq)/write_sequnlock(&zonelist_update_seq)
    section...
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3d36424b3b58 ("mm/page_alloc: fix race condition between build_all_zonelists and page allocation")
    Link: https://lkml.kernel.org/r/[email protected] [2]
    Reported-by: syzbot <[email protected]>
      Link: https://syzkaller.appspot.com/bug?extid=223c7461c58c58a4cb10 [1]
    Signed-off-by: Tetsuo Handa <[email protected]>
    Acked-by: Michal Hocko <[email protected]>
    Acked-by: Mel Gorman <[email protected]>
    Cc: Petr Mladek <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Ilpo Järvinen <[email protected]>
    Cc: John Ogness <[email protected]>
    Cc: Patrick Daly <[email protected]>
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmc: sdhci-of-esdhc: fix quirk to ignore command inhibit for data [+ + +]
Author: Georgii Kruglov <[email protected]>
Date:   Tue Mar 21 23:37:15 2023 +0300

    mmc: sdhci-of-esdhc: fix quirk to ignore command inhibit for data
    
    [ Upstream commit 0dd8316037a2a6d85b2be208bef9991de7b42170 ]
    
    If spec_reg is equal to 'SDHCI_PRESENT_STATE', esdhc_readl_fixup()
    fixes up register value and returns it immediately. As a result, the
    further block
    (spec_reg == SDHCI_PRESENT_STATE)
        &&(esdhc->quirk_ignore_data_inhibit == true),
    is never executed.
    
    The patch merges the second block into the first one.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 1f1929f3f2fa ("mmc: sdhci-of-esdhc: add quirk to ignore command inhibit for data")
    Signed-off-by: Georgii Kruglov <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/ncsi: clear Tx enable mode when handling a Config required AEN [+ + +]
Author: Cosmo Chou <[email protected]>
Date:   Wed Apr 26 16:13:50 2023 +0800

    net/ncsi: clear Tx enable mode when handling a Config required AEN
    
    [ Upstream commit 6f75cd166a5a3c0bc50441faa8b8304f60522fdd ]
    
    ncsi_channel_is_tx() determines whether a given channel should be
    used for Tx or not. However, when reconfiguring the channel by
    handling a Configuration Required AEN, there is a misjudgment that
    the channel Tx has already been enabled, which results in the Enable
    Channel Network Tx command not being sent.
    
    Clear the channel Tx enable flag before reconfiguring the channel to
    avoid the misjudgment.
    
    Fixes: 8d951a75d022 ("net/ncsi: Configure multi-package, multi-channel modes with failover")
    Signed-off-by: Cosmo Chou <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/packet: annotate accesses to po->xmit [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 16 01:10:06 2023 +0000

    net/packet: annotate accesses to po->xmit
    
    [ Upstream commit b9d83ab8a708f23a4001d60e9d8d0b3be3d9f607 ]
    
    po->xmit can be set from setsockopt(PACKET_QDISC_BYPASS),
    while read locklessly.
    
    Use READ_ONCE()/WRITE_ONCE() to avoid potential load/store
    tearing issues.
    
    Fixes: d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option")
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/packet: convert po->auxdata to an atomic flag [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 16 01:10:08 2023 +0000

    net/packet: convert po->auxdata to an atomic flag
    
    [ Upstream commit fd53c297aa7b077ae98a3d3d2d3aa278a1686ba6 ]
    
    po->auxdata can be read while another thread
    is changing its value, potentially raising KCSAN splat.
    
    Convert it to PACKET_SOCK_AUXDATA flag.
    
    Fixes: 8dc419447415 ("[PACKET]: Add optional checksum computation for recvmsg")
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/packet: convert po->origdev to an atomic flag [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 16 01:10:07 2023 +0000

    net/packet: convert po->origdev to an atomic flag
    
    [ Upstream commit ee5675ecdf7a4e713ed21d98a70c2871d6ebed01 ]
    
    syzbot/KCAN reported that po->origdev can be read
    while another thread is changing its value.
    
    We can avoid this splat by converting this field
    to an actual bit.
    
    Following patches will convert remaining 1bit fields.
    
    Fixes: 80feaacb8a64 ("[AF_PACKET]: Add option to return orig_dev to userspace.")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sched: act_mirred: Add carrier check [+ + +]
Author: Victor Nogueira <[email protected]>
Date:   Wed Apr 26 15:19:40 2023 +0000

    net/sched: act_mirred: Add carrier check
    
    [ Upstream commit 526f28bd0fbdc699cda31426928802650c1528e5 ]
    
    There are cases where the device is adminstratively UP, but operationally
    down. For example, we have a physical device (Nvidia ConnectX-6 Dx, 25Gbps)
    who's cable was pulled out, here is its ip link output:
    
    5: ens2f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
        link/ether b8:ce:f6:4b:68:35 brd ff:ff:ff:ff:ff:ff
        altname enp179s0f1np1
    
    As you can see, it's administratively UP but operationally down.
    In this case, sending a packet to this port caused a nasty kernel hang (so
    nasty that we were unable to capture it). Aborting a transmit based on
    operational status (in addition to administrative status) fixes the issue.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Acked-by: Jamal Hadi Salim <[email protected]>
    Signed-off-by: Victor Nogueira <[email protected]>
    v1->v2: Add fixes tag
    v2->v3: Remove blank line between tags + add change log, suggested by Leon
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/sched: cls_api: remove block_cb from driver_list before freeing [+ + +]
Author: Vlad Buslov <[email protected]>
Date:   Wed Apr 26 14:31:11 2023 +0200

    net/sched: cls_api: remove block_cb from driver_list before freeing
    
    [ Upstream commit da94a7781fc3c92e7df7832bc2746f4d39bc624e ]
    
    Error handler of tcf_block_bind() frees the whole bo->cb_list on error.
    However, by that time the flow_block_cb instances are already in the driver
    list because driver ndo_setup_tc() callback is called before that up the
    call chain in tcf_block_offload_cmd(). This leaves dangling pointers to
    freed objects in the list and causes use-after-free[0]. Fix it by also
    removing flow_block_cb instances from driver_list before deallocating them.
    
    [0]:
    [  279.868433] ==================================================================
    [  279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0
    [  279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963
    
    [  279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4
    [  279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [  279.876295] Call Trace:
    [  279.876882]  <TASK>
    [  279.877413]  dump_stack_lvl+0x33/0x50
    [  279.878198]  print_report+0xc2/0x610
    [  279.878987]  ? flow_block_cb_setup_simple+0x631/0x7c0
    [  279.879994]  kasan_report+0xae/0xe0
    [  279.880750]  ? flow_block_cb_setup_simple+0x631/0x7c0
    [  279.881744]  ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core]
    [  279.883047]  flow_block_cb_setup_simple+0x631/0x7c0
    [  279.884027]  tcf_block_offload_cmd.isra.0+0x189/0x2d0
    [  279.885037]  ? tcf_block_setup+0x6b0/0x6b0
    [  279.885901]  ? mutex_lock+0x7d/0xd0
    [  279.886669]  ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0
    [  279.887844]  ? ingress_init+0x1c0/0x1c0 [sch_ingress]
    [  279.888846]  tcf_block_get_ext+0x61c/0x1200
    [  279.889711]  ingress_init+0x112/0x1c0 [sch_ingress]
    [  279.890682]  ? clsact_init+0x2b0/0x2b0 [sch_ingress]
    [  279.891701]  qdisc_create+0x401/0xea0
    [  279.892485]  ? qdisc_tree_reduce_backlog+0x470/0x470
    [  279.893473]  tc_modify_qdisc+0x6f7/0x16d0
    [  279.894344]  ? tc_get_qdisc+0xac0/0xac0
    [  279.895213]  ? mutex_lock+0x7d/0xd0
    [  279.896005]  ? __mutex_lock_slowpath+0x10/0x10
    [  279.896910]  rtnetlink_rcv_msg+0x5fe/0x9d0
    [  279.897770]  ? rtnl_calcit.isra.0+0x2b0/0x2b0
    [  279.898672]  ? __sys_sendmsg+0xb5/0x140
    [  279.899494]  ? do_syscall_64+0x3d/0x90
    [  279.900302]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [  279.901337]  ? kasan_save_stack+0x2e/0x40
    [  279.902177]  ? kasan_save_stack+0x1e/0x40
    [  279.903058]  ? kasan_set_track+0x21/0x30
    [  279.903913]  ? kasan_save_free_info+0x2a/0x40
    [  279.904836]  ? ____kasan_slab_free+0x11a/0x1b0
    [  279.905741]  ? kmem_cache_free+0x179/0x400
    [  279.906599]  netlink_rcv_skb+0x12c/0x360
    [  279.907450]  ? rtnl_calcit.isra.0+0x2b0/0x2b0
    [  279.908360]  ? netlink_ack+0x1550/0x1550
    [  279.909192]  ? rhashtable_walk_peek+0x170/0x170
    [  279.910135]  ? kmem_cache_alloc_node+0x1af/0x390
    [  279.911086]  ? _copy_from_iter+0x3d6/0xc70
    [  279.912031]  netlink_unicast+0x553/0x790
    [  279.912864]  ? netlink_attachskb+0x6a0/0x6a0
    [  279.913763]  ? netlink_recvmsg+0x416/0xb50
    [  279.914627]  netlink_sendmsg+0x7a1/0xcb0
    [  279.915473]  ? netlink_unicast+0x790/0x790
    [  279.916334]  ? iovec_from_user.part.0+0x4d/0x220
    [  279.917293]  ? netlink_unicast+0x790/0x790
    [  279.918159]  sock_sendmsg+0xc5/0x190
    [  279.918938]  ____sys_sendmsg+0x535/0x6b0
    [  279.919813]  ? import_iovec+0x7/0x10
    [  279.920601]  ? kernel_sendmsg+0x30/0x30
    [  279.921423]  ? __copy_msghdr+0x3c0/0x3c0
    [  279.922254]  ? import_iovec+0x7/0x10
    [  279.923041]  ___sys_sendmsg+0xeb/0x170
    [  279.923854]  ? copy_msghdr_from_user+0x110/0x110
    [  279.924797]  ? ___sys_recvmsg+0xd9/0x130
    [  279.925630]  ? __perf_event_task_sched_in+0x183/0x470
    [  279.926656]  ? ___sys_sendmsg+0x170/0x170
    [  279.927529]  ? ctx_sched_in+0x530/0x530
    [  279.928369]  ? update_curr+0x283/0x4f0
    [  279.929185]  ? perf_event_update_userpage+0x570/0x570
    [  279.930201]  ? __fget_light+0x57/0x520
    [  279.931023]  ? __switch_to+0x53d/0xe70
    [  279.931846]  ? sockfd_lookup_light+0x1a/0x140
    [  279.932761]  __sys_sendmsg+0xb5/0x140
    [  279.933560]  ? __sys_sendmsg_sock+0x20/0x20
    [  279.934436]  ? fpregs_assert_state_consistent+0x1d/0xa0
    [  279.935490]  do_syscall_64+0x3d/0x90
    [  279.936300]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [  279.937311] RIP: 0033:0x7f21c814f887
    [  279.938085] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
    [  279.941448] RSP: 002b:00007fff11efd478 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [  279.942964] RAX: ffffffffffffffda RBX: 0000000064401979 RCX: 00007f21c814f887
    [  279.944337] RDX: 0000000000000000 RSI: 00007fff11efd4e0 RDI: 0000000000000003
    [  279.945660] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
    [  279.947003] R10: 00007f21c8008708 R11: 0000000000000246 R12: 0000000000000001
    [  279.948345] R13: 0000000000409980 R14: 000000000047e538 R15: 0000000000485400
    [  279.949690]  </TASK>
    
    [  279.950706] Allocated by task 2960:
    [  279.951471]  kasan_save_stack+0x1e/0x40
    [  279.952338]  kasan_set_track+0x21/0x30
    [  279.953165]  __kasan_kmalloc+0x77/0x90
    [  279.954006]  flow_block_cb_setup_simple+0x3dd/0x7c0
    [  279.955001]  tcf_block_offload_cmd.isra.0+0x189/0x2d0
    [  279.956020]  tcf_block_get_ext+0x61c/0x1200
    [  279.956881]  ingress_init+0x112/0x1c0 [sch_ingress]
    [  279.957873]  qdisc_create+0x401/0xea0
    [  279.958656]  tc_modify_qdisc+0x6f7/0x16d0
    [  279.959506]  rtnetlink_rcv_msg+0x5fe/0x9d0
    [  279.960392]  netlink_rcv_skb+0x12c/0x360
    [  279.961216]  netlink_unicast+0x553/0x790
    [  279.962044]  netlink_sendmsg+0x7a1/0xcb0
    [  279.962906]  sock_sendmsg+0xc5/0x190
    [  279.963702]  ____sys_sendmsg+0x535/0x6b0
    [  279.964534]  ___sys_sendmsg+0xeb/0x170
    [  279.965343]  __sys_sendmsg+0xb5/0x140
    [  279.966132]  do_syscall_64+0x3d/0x90
    [  279.966908]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [  279.968407] Freed by task 2960:
    [  279.969114]  kasan_save_stack+0x1e/0x40
    [  279.969929]  kasan_set_track+0x21/0x30
    [  279.970729]  kasan_save_free_info+0x2a/0x40
    [  279.971603]  ____kasan_slab_free+0x11a/0x1b0
    [  279.972483]  __kmem_cache_free+0x14d/0x280
    [  279.973337]  tcf_block_setup+0x29d/0x6b0
    [  279.974173]  tcf_block_offload_cmd.isra.0+0x226/0x2d0
    [  279.975186]  tcf_block_get_ext+0x61c/0x1200
    [  279.976080]  ingress_init+0x112/0x1c0 [sch_ingress]
    [  279.977065]  qdisc_create+0x401/0xea0
    [  279.977857]  tc_modify_qdisc+0x6f7/0x16d0
    [  279.978695]  rtnetlink_rcv_msg+0x5fe/0x9d0
    [  279.979562]  netlink_rcv_skb+0x12c/0x360
    [  279.980388]  netlink_unicast+0x553/0x790
    [  279.981214]  netlink_sendmsg+0x7a1/0xcb0
    [  279.982043]  sock_sendmsg+0xc5/0x190
    [  279.982827]  ____sys_sendmsg+0x535/0x6b0
    [  279.983703]  ___sys_sendmsg+0xeb/0x170
    [  279.984510]  __sys_sendmsg+0xb5/0x140
    [  279.985298]  do_syscall_64+0x3d/0x90
    [  279.986076]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [  279.987532] The buggy address belongs to the object at ffff888147e2bf00
                    which belongs to the cache kmalloc-192 of size 192
    [  279.989747] The buggy address is located 32 bytes inside of
                    freed 192-byte region [ffff888147e2bf00, ffff888147e2bfc0)
    
    [  279.992367] The buggy address belongs to the physical page:
    [  279.993430] page:00000000550f405c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147e2a
    [  279.995182] head:00000000550f405c order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    [  279.996713] anon flags: 0x200000000010200(slab|head|node=0|zone=2)
    [  279.997878] raw: 0200000000010200 ffff888100042a00 0000000000000000 dead000000000001
    [  279.999384] raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
    [  280.000894] page dumped because: kasan: bad access detected
    
    [  280.002386] Memory state around the buggy address:
    [  280.003338]  ffff888147e2be00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  280.004781]  ffff888147e2be80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [  280.006224] >ffff888147e2bf00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  280.007700]                                ^
    [  280.008592]  ffff888147e2bf80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [  280.010035]  ffff888147e2c000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  280.011564] ==================================================================
    
    Fixes: 59094b1e5094 ("net: sched: use flow block API")
    Signed-off-by: Vlad Buslov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/sched: sch_fq: fix integer overflow of "credit" [+ + +]
Author: Davide Caratti <[email protected]>
Date:   Thu Apr 20 16:59:46 2023 +0200

    net/sched: sch_fq: fix integer overflow of "credit"
    
    [ Upstream commit 7041101ff6c3073fd8f2e99920f535b111c929cb ]
    
    if sch_fq is configured with "initial quantum" having values greater than
    INT_MAX, the first assignment of "credit" does signed integer overflow to
    a very negative value.
    In this situation, the syzkaller script provided by Cristoph triggers the
    CPU soft-lockup warning even with few sockets. It's not an infinite loop,
    but "credit" wasn't probably meant to be minus 2Gb for each new flow.
    Capping "initial quantum" to INT_MAX proved to fix the issue.
    
    v2: validation of "initial quantum" is done in fq_policy, instead of open
        coding in fq_change() _ suggested by Jakub Kicinski
    
    Reported-by: Christoph Paasch <[email protected]>
    Link: https://github.com/multipath-tcp/mptcp_net-next/issues/377
    Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler")
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: Davide Caratti <[email protected]>
    Link: https://lore.kernel.org/r/7b3a3c7e36d03068707a021760a194a8eb5ad41a.1682002300.git.dcaratti@redhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: amd: Fix link leak when verifying config failed [+ + +]
Author: Gencen Gan <[email protected]>
Date:   Mon Apr 24 23:28:01 2023 +0800

    net: amd: Fix link leak when verifying config failed
    
    [ Upstream commit d325c34d9e7e38d371c0a299d415e9b07f66a1fb ]
    
    After failing to verify configuration, it returns directly without
    releasing link, which may cause memory leak.
    
    Paolo Abeni thinks that the whole code of this driver is quite
    "suboptimal" and looks unmainatained since at least ~15y, so he
    suggests that we could simply remove the whole driver, please
    take it into consideration.
    
    Simon Horman suggests that the fix label should be set to
    "Linux-2.6.12-rc2" considering that the problem has existed
    since the driver was introduced and the commit above doesn't
    seem to exist in net/net-next.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Gan Gecen <[email protected]>
    Reviewed-by: Dongliang Mu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: fix corrupt frames using trgmii on 40 MHz XTAL MT7621 [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Wed May 3 00:09:46 2023 +0300

    net: dsa: mt7530: fix corrupt frames using trgmii on 40 MHz XTAL MT7621
    
    [ Upstream commit 37c218d8021e36e226add4bab93d071d30fe0704 ]
    
    The multi-chip module MT7530 switch with a 40 MHz oscillator on the
    MT7621AT, MT7621DAT, and MT7621ST SoCs forwards corrupt frames using
    trgmii.
    
    This is caused by the assumption that MT7621 SoCs have got 150 MHz PLL,
    hence using the ncpo1 value, 0x0780.
    
    My testing shows this value works on Unielec U7621-06, Bartel's testing
    shows it won't work on Hi-Link HLK-MT7621A and Netgear WAC104. All devices
    tested have got 40 MHz oscillators.
    
    Using the value for 125 MHz PLL, 0x0640, works on all boards at hand. The
    definitions for 125 MHz PLL exist on the Banana Pi BPI-R2 BSP source code
    whilst 150 MHz PLL don't.
    
    Forwarding frames using trgmii on the MCM MT7530 switch with a 25 MHz
    oscillator on the said MT7621 SoCs works fine because the ncpo1 value
    defined for it is for 125 MHz PLL.
    
    Change the 150 MHz PLL comment to 125 MHz PLL, and use the 125 MHz PLL
    ncpo1 values for both oscillator frequencies.
    
    Link: https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/81d24bbce7d99524d0771a8bdb2d6663e4eb4faa/u-boot-mt/drivers/net/rt2880_eth.c#L2195
    Fixes: 7ef6f6f8d237 ("net: dsa: mt7530: Add MT7621 TRGMII mode support")
    Tested-by: Bartel Eerdekens <[email protected]>
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mv88e6xxx: add mv88e6321 rsvd2cpu [+ + +]
Author: Angelo Dureghello <[email protected]>
Date:   Wed Apr 26 22:28:15 2023 +0200

    net: dsa: mv88e6xxx: add mv88e6321 rsvd2cpu
    
    [ Upstream commit 6686317855c6997671982d4489ccdd946f644957 ]
    
    Add rsvd2cpu capability for mv88e6321 model, to allow proper bpdu
    processing.
    
    Signed-off-by: Angelo Dureghello <[email protected]>
    Fixes: 51c901a775621 ("net: dsa: mv88e6xxx: distinguish Global 2 Rsvd2CPU")
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: enetc: check the index of the SFI rather than the handle [+ + +]
Author: Wei Fang <[email protected]>
Date:   Thu May 4 16:03:59 2023 +0800

    net: enetc: check the index of the SFI rather than the handle
    
    [ Upstream commit 299efdc2380aac588557f4d0b2ce7bee05bd0cf2 ]
    
    We should check whether the current SFI (Stream Filter Instance) table
    is full before creating a new SFI entry. However, the previous logic
    checks the handle by mistake and might lead to unpredictable behavior.
    
    Fixes: 888ae5a3952b ("net: enetc: add tc flower psfp offload driver")
    Signed-off-by: Wei Fang <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: stmmac: dwmac-rk: fix optional phy regulator handling [+ + +]
Author: Sebastian Reichel <[email protected]>
Date:   Fri Apr 7 18:11:29 2023 +0200

    net: ethernet: stmmac: dwmac-rk: fix optional phy regulator handling
    
    [ Upstream commit db21973263f8c56750cb610f1d5e8bee00a513b9 ]
    
    The usual devm_regulator_get() call already handles "optional"
    regulators by returning a valid dummy and printing a warning
    that the dummy regulator should be described properly. This
    code open coded the same behaviour, but masked any errors that
    are not -EPROBE_DEFER and is quite noisy.
    
    This change effectively unmasks and propagates regulators errors
    not involving -ENODEV, downgrades the error print to warning level
    if no regulator is specified and captures the probe defer message
    for /sys/kernel/debug/devices_deferred.
    
    Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qrtr: correct types of trace event parameters [+ + +]
Author: Simon Horman <[email protected]>
Date:   Mon Apr 3 17:43:16 2023 +0200

    net: qrtr: correct types of trace event parameters
    
    [ Upstream commit 054fbf7ff8143d35ca7d3bb5414bb44ee1574194 ]
    
    The arguments passed to the trace events are of type unsigned int,
    however the signature of the events used __le32 parameters.
    
    I may be missing the point here, but sparse flagged this and it
    does seem incorrect to me.
    
      net/qrtr/ns.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, include/trace/events/qrtr.h):
      ./include/trace/events/qrtr.h:11:1: warning: cast to restricted __le32
      ./include/trace/events/qrtr.h:11:1: warning: restricted __le32 degrades to integer
      ./include/trace/events/qrtr.h:11:1: warning: restricted __le32 degrades to integer
      ... (a lot more similar warnings)
      net/qrtr/ns.c:115:47:    expected restricted __le32 [usertype] service
      net/qrtr/ns.c:115:47:    got unsigned int service
      net/qrtr/ns.c:115:61: warning: incorrect type in argument 2 (different base types)
      ... (a lot more similar warnings)
    
    Fixes: dfddb54043f0 ("net: qrtr: Add tracepoint support")
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nf_tables: deactivate anonymous set from preparation phase [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 2 10:25:24 2023 +0200

    netfilter: nf_tables: deactivate anonymous set from preparation phase
    
    commit c1592a89942e9678f7d9c8030efa777c0d57edab upstream.
    
    Toggle deleted anonymous sets as inactive in the next generation, so
    users cannot perform any update on it. Clear the generation bitmask
    in case the transaction is aborted.
    
    The following KASAN splat shows a set element deletion for a bound
    anonymous set that has been already removed in the same transaction.
    
    [   64.921510] ==================================================================
    [   64.923123] BUG: KASAN: wild-memory-access in nf_tables_commit+0xa24/0x1490 [nf_tables]
    [   64.924745] Write of size 8 at addr dead000000000122 by task test/890
    [   64.927903] CPU: 3 PID: 890 Comm: test Not tainted 6.3.0+ #253
    [   64.931120] Call Trace:
    [   64.932699]  <TASK>
    [   64.934292]  dump_stack_lvl+0x33/0x50
    [   64.935908]  ? nf_tables_commit+0xa24/0x1490 [nf_tables]
    [   64.937551]  kasan_report+0xda/0x120
    [   64.939186]  ? nf_tables_commit+0xa24/0x1490 [nf_tables]
    [   64.940814]  nf_tables_commit+0xa24/0x1490 [nf_tables]
    [   64.942452]  ? __kasan_slab_alloc+0x2d/0x60
    [   64.944070]  ? nf_tables_setelem_notify+0x190/0x190 [nf_tables]
    [   64.945710]  ? kasan_set_track+0x21/0x30
    [   64.947323]  nfnetlink_rcv_batch+0x709/0xd90 [nfnetlink]
    [   64.948898]  ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink]
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

netfilter: nf_tables: don't write table validation state without mutex [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Thu Apr 13 17:13:19 2023 +0200

    netfilter: nf_tables: don't write table validation state without mutex
    
    [ Upstream commit 9a32e9850686599ed194ccdceb6cd3dd56b2d9b9 ]
    
    The ->cleanup callback needs to be removed, this doesn't work anymore as
    the transaction mutex is already released in the ->abort function.
    
    Just do it after a successful validation pass, this either happens
    from commit or abort phases where transaction mutex is held.
    
    Fixes: f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netlink: Use copy_to_user() for optval in netlink_getsockopt(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri Apr 21 11:52:55 2023 -0700

    netlink: Use copy_to_user() for optval in netlink_getsockopt().
    
    [ Upstream commit d913d32cc2707e9cd24fe6fa6d7d470e9c728980 ]
    
    Brad Spencer provided a detailed report [0] that when calling getsockopt()
    for AF_NETLINK, some SOL_NETLINK options set only 1 byte even though such
    options require at least sizeof(int) as length.
    
    The options return a flag value that fits into 1 byte, but such behaviour
    confuses users who do not initialise the variable before calling
    getsockopt() and do not strictly check the returned value as char.
    
    Currently, netlink_getsockopt() uses put_user() to copy data to optlen and
    optval, but put_user() casts the data based on the pointer, char *optval.
    As a result, only 1 byte is set to optval.
    
    To avoid this behaviour, we need to use copy_to_user() or cast optval for
    put_user().
    
    Note that this changes the behaviour on big-endian systems, but we document
    that the size of optval is int in the man page.
    
      $ man 7 netlink
      ...
      Socket options
           To set or get a netlink socket option, call getsockopt(2) to read
           or setsockopt(2) to write the option with the option level argument
           set to SOL_NETLINK.  Unless otherwise noted, optval is a pointer to
           an int.
    
    Fixes: 9a4595bc7e67 ("[NETLINK]: Add set/getsockopt options to support more than 32 groups")
    Fixes: be0c22a46cfb ("netlink: add NETLINK_BROADCAST_ERROR socket option")
    Fixes: 38938bfe3489 ("netlink: add NETLINK_NO_ENOBUFS socket flag")
    Fixes: 0a6a3a23ea6e ("netlink: add NETLINK_CAP_ACK socket option")
    Fixes: 2d4bc93368f5 ("netlink: extended ACK reporting")
    Fixes: 89d35528d17d ("netlink: Add new socket option to enable strict checking on dumps")
    Reported-by: Brad Spencer <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.1: Always send a RECLAIM_COMPLETE after establishing lease [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Mon Mar 13 18:45:53 2023 -0400

    NFSv4.1: Always send a RECLAIM_COMPLETE after establishing lease
    
    [ Upstream commit 40882deb83c29d8df4470d4e5e7f137b6acf7ad1 ]
    
    The spec requires that we always at least send a RECLAIM_COMPLETE when
    we're done establishing the lease and recovering any state.
    
    Fixes: fce5c838e133 ("nfs41: RECLAIM_COMPLETE functionality")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: do not write dirty data after degenerating to read-only [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Thu Apr 27 10:15:26 2023 +0900

    nilfs2: do not write dirty data after degenerating to read-only
    
    commit 28a65b49eb53e172d23567005465019658bfdb4d upstream.
    
    According to syzbot's report, mark_buffer_dirty() called from
    nilfs_segctor_do_construct() outputs a warning with some patterns after
    nilfs2 detects metadata corruption and degrades to read-only mode.
    
    After such read-only degeneration, page cache data may be cleared through
    nilfs_clear_dirty_page() which may also clear the uptodate flag for their
    buffer heads.  However, even after the degeneration, log writes are still
    performed by unmount processing etc., which causes mark_buffer_dirty() to
    be called for buffer heads without the "uptodate" flag and causes the
    warning.
    
    Since any writes should not be done to a read-only file system in the
    first place, this fixes the warning in mark_buffer_dirty() by letting
    nilfs_segctor_do_construct() abort early if in read-only mode.
    
    This also changes the retry check of nilfs_segctor_write_out() to avoid
    unnecessary log write retries if it detects -EROFS that
    nilfs_segctor_do_construct() returned.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Tested-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
      Link: https://syzkaller.appspot.com/bug?extid=2af3bc9585be7f23f290
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix infinite loop in nilfs_mdt_get_block() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Mon May 1 04:30:46 2023 +0900

    nilfs2: fix infinite loop in nilfs_mdt_get_block()
    
    commit a6a491c048882e7e424d407d32cba0b52d9ef2bf upstream.
    
    If the disk image that nilfs2 mounts is corrupted and a virtual block
    address obtained by block lookup for a metadata file is invalid,
    nilfs_bmap_lookup_at_level() may return the same internal return code as
    -ENOENT, meaning the block does not exist in the metadata file.
    
    This duplication of return codes confuses nilfs_mdt_get_block(), causing
    it to read and create a metadata block indefinitely.
    
    In particular, if this happens to the inode metadata file, ifile,
    semaphore i_rwsem can be left held, causing task hangs in lock_mount.
    
    Fix this issue by making nilfs_bmap_lookup_at_level() treat virtual block
    address translation failures with -ENOENT as metadata corruption instead
    of returning the error code.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Tested-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
      Link: https://syzkaller.appspot.com/bug?extid=221d75710bde87fa0e97
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvme-fcloop: fix "inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage" [+ + +]
Author: Ming Lei <[email protected]>
Date:   Wed Apr 12 16:49:04 2023 +0800

    nvme-fcloop: fix "inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage"
    
    [ Upstream commit 4f86a6ff6fbd891232dda3ca97fd1b9630b59809 ]
    
    fcloop_fcp_op() could be called from flush request's ->end_io(flush_end_io) in
    which the spinlock of fq->mq_flush_lock is grabbed with irq saved/disabled.
    
    So fcloop_fcp_op() can't call spin_unlock_irq(&tfcp_req->reqlock) simply
    which enables irq unconditionally.
    
    Fixes the warning by switching to spin_lock_irqsave()/spin_unlock_irqrestore()
    
    Fixes: c38dbbfab1bc ("nvme-fcloop: fix inconsistent lock state warnings")
    Reported-by: Yi Zhang <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Reviewed-by: Ewan D. Milne <[email protected]>
    Tested-by: Yi Zhang <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: fix async event trace event [+ + +]
Author: Keith Busch <[email protected]>
Date:   Wed Apr 5 14:57:20 2023 -0700

    nvme: fix async event trace event
    
    [ Upstream commit 6622b76fe922b94189499a90ccdb714a4a8d0773 ]
    
    Mixing AER Event Type and Event Info has masking clashes. Just print the
    event type, but also include the event info of the AER result in the
    trace.
    
    Fixes: 09bd1ff4b15143b ("nvme-core: add async event trace helper")
    Reported-by: Nate Thornton <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Minwoo Im <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvme: handle the persistent internal error AER [+ + +]
Author: Michael Kelley <[email protected]>
Date:   Wed Jun 8 11:52:21 2022 -0700

    nvme: handle the persistent internal error AER
    
    [ Upstream commit 2c61c97fb12b806e1c8eb15f04c277ad097ec95e ]
    
    In the NVM Express Revision 1.4 spec, Figure 145 describes possible
    values for an AER with event type "Error" (value 000b). For a
    Persistent Internal Error (value 03h), the host should perform a
    controller reset.
    
    Add support for this error using code that already exists for
    doing a controller reset. As part of this support, introduce
    two utility functions for parsing the AER type and subtype.
    
    This new support was tested in a lab environment where we can
    generate the persistent internal error on demand, and observe
    both the Linux side and NVMe controller side to see that the
    controller reset has been done.
    
    Signed-off-by: Michael Kelley <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 6622b76fe922 ("nvme: fix async event trace event")
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-pf: Disable packet I/O for graceful exit [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Wed May 3 12:39:43 2023 +0530

    octeontx2-pf: Disable packet I/O for graceful exit
    
    [ Upstream commit c926252205c424c4842dbdbe02f8e3296f623204 ]
    
    At the stage of enabling packet I/O in otx2_open, If mailbox
    timeout occurs then interface ends up in down state where as
    hardware packet I/O is enabled. Hence disable packet I/O also
    before bailing out.
    
    Fixes: 1ea0166da050 ("octeontx2-pf: Fix the device state on error")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Kovvuri Goutham <[email protected]>
    Signed-off-by: Sai Krishna <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-vf: Detach LF resources on probe cleanup [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Wed May 3 12:39:44 2023 +0530

    octeontx2-vf: Detach LF resources on probe cleanup
    
    [ Upstream commit 99ae1260fdb5f15beab8a3adfb93a9041c87a2c1 ]
    
    When a VF device probe fails due to error in MSIX vector allocation then
    the resources NIX and NPA LFs were not detached. Fix this by detaching
    the LFs when MSIX vector allocation fails.
    
    Fixes: 3184fb5ba96e ("octeontx2-vf: Virtual function driver support")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Kovvuri Goutham <[email protected]>
    Signed-off-by: Sai Krishna <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
of: Fix modalias string generation [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Tue Apr 4 18:21:09 2023 +0100

    of: Fix modalias string generation
    
    [ Upstream commit b19a4266c52de78496fe40f0b37580a3b762e67d ]
    
    The helper generating an OF based modalias (of_device_get_modalias())
    works fine, but due to the use of snprintf() internally it needs a
    buffer one byte longer than what should be needed just for the entire
    string (excluding the '\0'). Most users of this helper are sysfs hooks
    providing the modalias string to users. They all provide a PAGE_SIZE
    buffer which is way above the number of bytes required to fit the
    modalias string and hence do not suffer from this issue.
    
    There is another user though, of_device_request_module(), which is only
    called by drivers/usb/common/ulpi.c. This request module function is
    faulty, but maybe because in most cases there is an alternative, ULPI
    driver users have not noticed it.
    
    In this function, of_device_get_modalias() is called twice. The first
    time without buffer just to get the number of bytes required by the
    modalias string (excluding the null byte), and a second time, after
    buffer allocation, to fill the buffer. The allocation asks for an
    additional byte, in order to store the trailing '\0'. However, the
    buffer *length* provided to of_device_get_modalias() excludes this extra
    byte. The internal use of snprintf() with a length that is exactly the
    number of bytes to be written has the effect of using the last available
    byte to store a '\0', which then smashes the last character of the
    modalias string.
    
    Provide the actual size of the buffer to of_device_get_modalias() to fix
    this issue.
    
    Note: the "str[size - 1] = '\0';" line is not really needed as snprintf
    will anyway end the string with a null byte, but there is a possibility
    that this function might be called on a struct device_node without
    compatible, in this case snprintf() would not be executed. So we keep it
    just to avoid possible unbounded strings.
    
    Cc: Stephen Boyd <[email protected]>
    Cc: Peter Chen <[email protected]>
    Fixes: 9c829c097f2f ("of: device: Support loading a module with OF based modalias")
    Signed-off-by: Miquel Raynal <[email protected]>
    Reviewed-by: Rob Herring <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
openrisc: Properly store r31 to pt_regs on unhandled exceptions [+ + +]
Author: Stafford Horne <[email protected]>
Date:   Sat Feb 11 19:14:06 2023 +0900

    openrisc: Properly store r31 to pt_regs on unhandled exceptions
    
    [ Upstream commit 812489ac4dd91144a74ce65ecf232252a2e406fb ]
    
    In commit 91993c8c2ed5 ("openrisc: use shadow registers to save regs on
    exception") the unhandled exception path was changed to do an early
    store of r30 instead of r31.  The entry code was not updated and r31 is
    not getting stored to pt_regs.
    
    This patch updates the entry handler to store r31 instead of r30.  We
    also remove some misleading commented out store r30 and r31
    instructrions.
    
    I noticed this while working on adding floating point exception
    handling,  This issue probably would never impact anything since we kill
    the process or Oops right away on unhandled exceptions.
    
    Fixes: 91993c8c2ed5 ("openrisc: use shadow registers to save regs on exception")
    Signed-off-by: Stafford Horne <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc: Fix argument pointer in real64_call_asm() [+ + +]
Author: Helge Deller <[email protected]>
Date:   Wed May 3 16:39:56 2023 +0200

    parisc: Fix argument pointer in real64_call_asm()
    
    commit 6e3220ba3323a2c24be834aebf5d6e9f89d0993f upstream.
    
    Fix the argument pointer (ap) to point to real-mode memory
    instead of virtual memory.
    
    It's interesting that this issue hasn't shown up earlier, as this could
    have happened with any 64-bit PDC ROM code.
    
    I just noticed it because I suddenly faced a HPMC while trying to execute
    the 64-bit STI ROM code of an Visualize-FXe graphics card for the STI
    text console.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI/EDR: Clear Device Status after EDR error recovery [+ + +]
Author: Kuppuswamy Sathyanarayanan <[email protected]>
Date:   Wed Mar 15 16:54:49 2023 -0700

    PCI/EDR: Clear Device Status after EDR error recovery
    
    [ Upstream commit c441b1e03da6c680a3e12da59c554f454f2ccf5e ]
    
    During EDR recovery, the OS must clear error status of the port that
    triggered DPC even if firmware retains control of DPC and AER (see the
    implementation note in the PCI Firmware spec r3.3, sec 4.6.12).
    
    Prior to 068c29a248b6 ("PCI/ERR: Clear PCIe Device Status errors only if
    OS owns AER"), the port Device Status was cleared in this path:
    
      edr_handle_event
        dpc_process_error(dev)                 # "dev" triggered DPC
        pcie_do_recovery(dev, dpc_reset_link)
          dpc_reset_link                       # exit DPC
          pcie_clear_device_status(dev)        # clear Device Status
    
    After 068c29a248b6, pcie_do_recovery() no longer clears Device Status when
    firmware controls AER, so the error bit remains set even after recovery.
    
    Per the "Downstream Port Containment configuration control" bit in the
    returned _OSC Control Field (sec 4.5.1), the OS is allowed to clear error
    status until it evaluates _OST, so clear Device Status in
    edr_handle_event() if the error recovery was successful.
    
    [bhelgaas: commit log]
    Fixes: 068c29a248b6 ("PCI/ERR: Clear PCIe Device Status errors only if OS owns AER")
    Link: https://lore.kernel.org/r/20230315235449.1279209-1-sathyanarayanan.kuppuswamy@linux.intel.com
    Reported-by: Tsaur Erwin <[email protected]>
    Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: imx6: Install the fault handler only on compatible match [+ + +]
Author: H. Nikolaus Schaller <[email protected]>
Date:   Thu Mar 9 17:56:31 2023 +0100

    PCI: imx6: Install the fault handler only on compatible match
    
    [ Upstream commit 5f5ac460dfe7f4e11f99de9870f240e39189cf72 ]
    
    commit bb38919ec56e ("PCI: imx6: Add support for i.MX6 PCIe controller")
    added a fault hook to this driver in the probe function. So it was only
    installed if needed.
    
    commit bde4a5a00e76 ("PCI: imx6: Allow probe deferral by reset GPIO")
    moved it from probe to driver init which installs the hook unconditionally
    as soon as the driver is compiled into a kernel.
    
    When this driver is compiled as a module, the hook is not registered
    until after the driver has been matched with a .compatible and
    loaded.
    
    commit 415b6185c541 ("PCI: imx6: Fix config read timeout handling")
    extended the fault handling code.
    
    commit 2d8ed461dbc9 ("PCI: imx6: Add support for i.MX8MQ")
    added some protection for non-ARM architectures, but this does not
    protect non-i.MX ARM architectures.
    
    Since fault handlers can be triggered on any architecture for different
    reasons, there is no guarantee that they will be triggered only for the
    assumed situation, leading to improper error handling (i.MX6-specific
    imx6q_pcie_abort_handler) on foreign systems.
    
    I had seen strange L3 imprecise external abort messages several times on
    OMAP4 and OMAP5 devices and couldn't make sense of them until I realized
    they were related to this unused imx6q driver because I had
    CONFIG_PCI_IMX6=y.
    
    Note that CONFIG_PCI_IMX6=y is useful for kernel binaries that are designed
    to run on different ARM SoC and be differentiated only by device tree
    binaries. So turning off CONFIG_PCI_IMX6 is not a solution.
    
    Therefore we check the compatible in the init function before registering
    the fault handler.
    
    Link: https://lore.kernel.org/r/e1bcfc3078c8[email protected]
    Fixes: bde4a5a00e76 ("PCI: imx6: Allow probe deferral by reset GPIO")
    Fixes: 415b6185c541 ("PCI: imx6: Fix config read timeout handling")
    Fixes: 2d8ed461dbc9 ("PCI: imx6: Add support for i.MX8MQ")
    Signed-off-by: H. Nikolaus Schaller <[email protected]>
    Signed-off-by: Lorenzo Pieralisi <[email protected]>
    Reviewed-by: Richard Zhu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: pciehp: Fix AB-BA deadlock between reset_lock and device_lock [+ + +]
Author: Lukas Wunner <[email protected]>
Date:   Tue Apr 11 08:21:02 2023 +0200

    PCI: pciehp: Fix AB-BA deadlock between reset_lock and device_lock
    
    commit f5eff5591b8f9c5effd25c92c758a127765f74c1 upstream.
    
    In 2013, commits
    
      2e35afaefe64 ("PCI: pciehp: Add reset_slot() method")
      608c388122c7 ("PCI: Add slot reset option to pci_dev_reset()")
    
    amended PCIe hotplug to mask Presence Detect Changed events during a
    Secondary Bus Reset.  The reset thus no longer causes gratuitous slot
    bringdown and bringup.
    
    However the commits neglected to serialize reset with code paths reading
    slot registers.  For instance, a slot bringup due to an earlier hotplug
    event may see the Presence Detect State bit cleared during a concurrent
    Secondary Bus Reset.
    
    In 2018, commit
    
      5b3f7b7d062b ("PCI: pciehp: Avoid slot access during reset")
    
    retrofitted the missing locking.  It introduced a reset_lock which
    serializes a Secondary Bus Reset with other parts of pciehp.
    
    Unfortunately the locking turns out to be overzealous:  reset_lock is
    held for the entire enumeration and de-enumeration of hotplugged devices,
    including driver binding and unbinding.
    
    Driver binding and unbinding acquires device_lock while the reset_lock
    of the ancestral hotplug port is held.  A concurrent Secondary Bus Reset
    acquires the ancestral reset_lock while already holding the device_lock.
    The asymmetric locking order in the two code paths can lead to AB-BA
    deadlocks.
    
    Michael Haeuptle reports such deadlocks on simultaneous hot-removal and
    vfio release (the latter implies a Secondary Bus Reset):
    
      pciehp_ist()                                    # down_read(reset_lock)
        pciehp_handle_presence_or_link_change()
          pciehp_disable_slot()
            __pciehp_disable_slot()
              remove_board()
                pciehp_unconfigure_device()
                  pci_stop_and_remove_bus_device()
                    pci_stop_bus_device()
                      pci_stop_dev()
                        device_release_driver()
                          device_release_driver_internal()
                            __device_driver_lock()    # device_lock()
    
      SYS_munmap()
        vfio_device_fops_release()
          vfio_device_group_close()
            vfio_device_close()
              vfio_device_last_close()
                vfio_pci_core_close_device()
                  vfio_pci_core_disable()             # device_lock()
                    __pci_reset_function_locked()
                      pci_reset_bus_function()
                        pci_dev_reset_slot_function()
                          pci_reset_hotplug_slot()
                            pciehp_reset_slot()       # down_write(reset_lock)
    
    Ian May reports the same deadlock on simultaneous hot-removal and an
    AER-induced Secondary Bus Reset:
    
      aer_recover_work_func()
        pcie_do_recovery()
          aer_root_reset()
            pci_bus_error_reset()
              pci_slot_reset()
                pci_slot_lock()                       # device_lock()
                pci_reset_hotplug_slot()
                  pciehp_reset_slot()                 # down_write(reset_lock)
    
    Fix by releasing the reset_lock during driver binding and unbinding,
    thereby splitting and shrinking the critical section.
    
    Driver binding and unbinding is protected by the device_lock() and thus
    serialized with a Secondary Bus Reset.  There's no need to additionally
    protect it with the reset_lock.  However, pciehp does not bind and
    unbind devices directly, but rather invokes PCI core functions which
    also perform certain enumeration and de-enumeration steps.
    
    The reset_lock's purpose is to protect slot registers, not enumeration
    and de-enumeration of hotplugged devices.  That would arguably be the
    job of the PCI core, not the PCIe hotplug driver.  After all, an
    AER-induced Secondary Bus Reset may as well happen during boot-time
    enumeration of the PCI hierarchy and there's no locking to prevent that
    either.
    
    Exempting *de-enumeration* from the reset_lock is relatively harmless:
    A concurrent Secondary Bus Reset may foil config space accesses such as
    PME interrupt disablement.  But if the device is physically gone, those
    accesses are pointless anyway.  If the device is physically present and
    only logically removed through an Attention Button press or the sysfs
    "power" attribute, PME interrupts as well as DMA cannot come through
    because pciehp_unconfigure_device() disables INTx and Bus Master bits.
    That's still protected by the reset_lock in the present commit.
    
    Exempting *enumeration* from the reset_lock also has limited impact:
    The exempted call to pci_bus_add_device() may perform device accesses
    through pcibios_bus_add_device() and pci_fixup_device() which are now
    no longer protected from a concurrent Secondary Bus Reset.  Otherwise
    there should be no impact.
    
    In essence, the present commit seeks to fix the AB-BA deadlocks while
    still retaining a best-effort reset protection for enumeration and
    de-enumeration of hotplugged devices -- until a general solution is
    implemented in the PCI core.
    
    Link: https://lore.kernel.org/linux-pci/CS1PR8401MB0728FC6FDAB8A35C22BD90EC95F10@CS1PR8401MB0728.NAMPRD84.PROD.OUTLOOK.COM
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215590
    Fixes: 5b3f7b7d062b ("PCI: pciehp: Avoid slot access during reset")
    Link: https://lore.kernel.org/r/fef2b2e9edf245c049a8c5b94743c0f74ff5008a.1681191902.git.lukas@wunner.de
    Reported-by: Michael Haeuptle <[email protected]>
    Reported-by: Ian May <[email protected]>
    Reported-by: Andrey Grodzovsky <[email protected]>
    Reported-by: Rahul Kumar <[email protected]>
    Reported-by: Jialin Zhang <[email protected]>
    Tested-by: Anatoli Antonovitch <[email protected]>
    Signed-off-by: Lukas Wunner <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected] # v4.19+
    Cc: Dan Stein <[email protected]>
    Cc: Ashok Raj <[email protected]>
    Cc: Alex Michon <[email protected]>
    Cc: Xiongfeng Wang <[email protected]>
    Cc: Alex Williamson <[email protected]>
    Cc: Mika Westerberg <[email protected]>
    Cc: Sathyanarayanan Kuppuswamy <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: qcom: Fix the incorrect register usage in v2.7.0 config [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Thu Mar 16 13:40:59 2023 +0530

    PCI: qcom: Fix the incorrect register usage in v2.7.0 config
    
    commit 2542e16c392508800f1d9037feee881a9c444951 upstream.
    
    Qcom PCIe IP version v2.7.0 and its derivatives don't contain the
    PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT register. Instead, they have the new
    PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 register. So fix the incorrect
    register usage which is modifying a different register.
    
    Also in this IP version, this register change doesn't depend on MSI
    being enabled. So remove that check also.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: ed8cc3b1fc84 ("PCI: qcom: Add support for SDM845 PCIe controller")
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Lorenzo Pieralisi <[email protected]>
    Cc: <[email protected]> # 5.6+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf auxtrace: Fix address filter entire kernel size [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Mon Apr 3 18:48:30 2023 +0300

    perf auxtrace: Fix address filter entire kernel size
    
    commit 1f9f33ccf0320be21703d9195dd2b36a1c9a07cb upstream.
    
    kallsyms is not completely in address order.
    
    In find_entire_kern_cb(), calculate the kernel end from the maximum
    address not the last symbol.
    
    Example:
    
     Before:
    
        $ sudo cat /proc/kallsyms | grep ' [twTw] ' | tail -1
        ffffffffc00b8bd0 t bpf_prog_6deef7357e7b4530    [bpf]
        $ sudo cat /proc/kallsyms | grep ' [twTw] ' | sort | tail -1
        ffffffffc15e0cc0 t iwl_mvm_exit [iwlmvm]
        $ perf.d093603a05aa record -v --kcore -e intel_pt// --filter 'filter *' -- uname |& grep filter
        Address filter: filter 0xffffffff93200000/0x2ceba000
    
     After:
    
        $ perf.8fb0f7a01f8e record -v --kcore -e intel_pt// --filter 'filter *' -- uname |& grep filter
        Address filter: filter 0xffffffff93200000/0x2e3e2000
    
    Fixes: 1b36c03e356936d6 ("perf record: Add support for using symbols in address filters")
    Signed-off-by: Adrian Hunter <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf intel-pt: Fix CYC timestamps after standalone CBR [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Mon Apr 3 18:48:31 2023 +0300

    perf intel-pt: Fix CYC timestamps after standalone CBR
    
    commit 430635a0ef1ce958b7b4311f172694ece2c692b8 upstream.
    
    After a standalone CBR (not associated with TSC), update the cycles
    reference timestamp and reset the cycle count, so that CYC timestamps
    are calculated relative to that point with the new frequency.
    
    Fixes: cc33618619cefc6d ("perf tools: Add Intel PT support for decoding CYC packets")
    Signed-off-by: Adrian Hunter <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf map: Delete two variable initialisations before null pointer checks in sort__sym_from_cmp() [+ + +]
Author: Markus Elfring <[email protected]>
Date:   Thu Apr 13 14:46:39 2023 +0200

    perf map: Delete two variable initialisations before null pointer checks in sort__sym_from_cmp()
    
    [ Upstream commit c160118a90d4acf335993d8d59b02ae2147a524e ]
    
    Addresses of two data structure members were determined before
    corresponding null pointer checks in the implementation of the function
    “sort__sym_from_cmp”.
    
    Thus avoid the risk for undefined behaviour by removing extra
    initialisations for the local variables “from_l” and “from_r” (also
    because they were already reassigned with the same value behind this
    pointer check).
    
    This issue was detected by using the Coccinelle software.
    
    Fixes: 1b9e97a2a95e4941 ("perf tools: Fix report -F symbol_from for data without branch info")
    Signed-off-by: <[email protected]>
    Acked-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Cc: German Gomez <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/cocci/[email protected]/
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf pmu: zfree() expects a pointer to a pointer to zero it after freeing its contents [+ + +]
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Wed Apr 12 10:23:35 2023 -0300

    perf pmu: zfree() expects a pointer to a pointer to zero it after freeing its contents
    
    [ Upstream commit 57f14b5ae1a97537f2abd2828ee7212cada7036e ]
    
    An audit showed just this one problem with zfree(), fix it.
    
    Fixes: 9fbc61f832ebf432 ("perf pmu: Add support for PMU capabilities")
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf sched: Cast PTHREAD_STACK_MIN to int as it may turn into sysconf(__SC_THREAD_STACK_MIN_VALUE) [+ + +]
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Wed Jul 14 13:06:38 2021 -0300

    perf sched: Cast PTHREAD_STACK_MIN to int as it may turn into sysconf(__SC_THREAD_STACK_MIN_VALUE)
    
    commit d08c84e01afa7a7eee6badab25d5420fa847f783 upstream.
    
    In fedora rawhide the PTHREAD_STACK_MIN define may end up expanded to a
    sysconf() call, and that will return 'long int', breaking the build:
    
        45 fedora:rawhide                : FAIL gcc version 11.1.1 20210623 (Red Hat 11.1.1-6) (GCC)
          builtin-sched.c: In function 'create_tasks':
          /git/perf-5.14.0-rc1/tools/include/linux/kernel.h:43:24: error: comparison of distinct pointer types lacks a cast [-Werror]
             43 |         (void) (&_max1 == &_max2);              \
                |                        ^~
          builtin-sched.c:673:34: note: in expansion of macro 'max'
            673 |                         (size_t) max(16 * 1024, PTHREAD_STACK_MIN));
                |                                  ^~~
          cc1: all warnings being treated as errors
    
      $ grep __sysconf /usr/include/*/*.h
      /usr/include/bits/pthread_stack_min-dynamic.h:extern long int __sysconf (int __name) __THROW;
      /usr/include/bits/pthread_stack_min-dynamic.h:#   define PTHREAD_STACK_MIN __sysconf (__SC_THREAD_STACK_MIN_VALUE)
      /usr/include/bits/time.h:extern long int __sysconf (int);
      /usr/include/bits/time.h:# define CLK_TCK ((__clock_t) __sysconf (2)) /* 2 is _SC_CLK_TCK */
      $
    
    So cast it to int to cope with that.
    
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Cc: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf symbols: Fix return incorrect build_id size in elf_read_build_id() [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Thu Apr 27 01:28:41 2023 +0000

    perf symbols: Fix return incorrect build_id size in elf_read_build_id()
    
    [ Upstream commit 1511e4696acb715a4fe48be89e1e691daec91c0e ]
    
    In elf_read_build_id(), if gnu build_id is found, should return the size of
    the actually copied data. If descsz is greater thanBuild_ID_SIZE,
    write_buildid data access may occur.
    
    Fixes: be96ea8ffa788dcc ("perf symbols: Fix issue with binaries using 16-bytes buildids (v2)")
    Reported-by: Will Ochowicz <[email protected]>
    Signed-off-by: Yang Jihong <[email protected]>
    Tested-by: Will Ochowicz <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Link: https://lore.kernel.org/lkml/CWLP265MB49702F7BA3D6D8F13E4B1A719C649@CWLP265MB4970.GBRP265.PROD.OUTLOOK.COM/T/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf vendor events power9: Remove UTF-8 characters from JSON files [+ + +]
Author: Kajol Jain <[email protected]>
Date:   Tue Mar 28 16:59:08 2023 +0530

    perf vendor events power9: Remove UTF-8 characters from JSON files
    
    [ Upstream commit 5d9df8731c0941f3add30f96745a62586a0c9d52 ]
    
    Commit 3c22ba5243040c13 ("perf vendor events powerpc: Update POWER9
    events") added and updated power9 PMU JSON events. However some of the
    JSON events which are part of other.json and pipeline.json files,
    contains UTF-8 characters in their brief description.  Having UTF-8
    character could breaks the perf build on some distros.
    
    Fix this issue by removing the UTF-8 characters from other.json and
    pipeline.json files.
    
    Result without the fix:
    
      [command]# file -i pmu-events/arch/powerpc/power9/*
      pmu-events/arch/powerpc/power9/cache.json:          application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/floating-point.json: application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/frontend.json:       application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/marked.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/memory.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/metrics.json:        application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/nest_metrics.json:   application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/other.json:          application/json; charset=utf-8
      pmu-events/arch/powerpc/power9/pipeline.json:       application/json; charset=utf-8
      pmu-events/arch/powerpc/power9/pmc.json:            application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/translation.json:    application/json; charset=us-ascii
      [command]#
    
    Result with the fix:
    
      [command]# file -i pmu-events/arch/powerpc/power9/*
      pmu-events/arch/powerpc/power9/cache.json:          application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/floating-point.json: application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/frontend.json:       application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/marked.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/memory.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/metrics.json:        application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/nest_metrics.json:   application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/other.json:          application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/pipeline.json:       application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/pmc.json:            application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/translation.json:    application/json; charset=us-ascii
      [command]#
    
    Fixes: 3c22ba5243040c13 ("perf vendor events powerpc: Update POWER9 events")
    Reported-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Kajol Jain <[email protected]>
    Acked-by: Ian Rogers <[email protected]>
    Tested-by: Arnaldo Carvalho de Melo <[email protected]>
    Cc: Athira Rajeev <[email protected]>
    Cc: Disha Goel <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Madhavan Srinivasan <[email protected]>
    Cc: Sukadev Bhattiprolu <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/core: Fix hardlockup failure caused by perf throttle [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Mon Feb 27 10:35:08 2023 +0800

    perf/core: Fix hardlockup failure caused by perf throttle
    
    [ Upstream commit 15def34e2635ab7e0e96f1bc32e1b69609f14942 ]
    
    commit e050e3f0a71bf ("perf: Fix broken interrupt rate throttling")
    introduces a change in throttling threshold judgment. Before this,
    compare hwc->interrupts and max_samples_per_tick, then increase
    hwc->interrupts by 1, but this commit reverses order of these two
    behaviors, causing the semantics of max_samples_per_tick to change.
    In literal sense of "max_samples_per_tick", if hwc->interrupts ==
    max_samples_per_tick, it should not be throttled, therefore, the judgment
    condition should be changed to "hwc->interrupts > max_samples_per_tick".
    
    In fact, this may cause the hardlockup to fail, The minimum value of
    max_samples_per_tick may be 1, in this case, the return value of
    __perf_event_account_interrupt function is 1.
    As a result, nmi_watchdog gets throttled, which would stop PMU (Use x86
    architecture as an example, see x86_pmu_handle_irq).
    
    Fixes: e050e3f0a71b ("perf: Fix broken interrupt rate throttling")
    Signed-off-by: Yang Jihong <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
phy: tegra: xusb: Add missing tegra_xusb_port_unregister for usb2_port and ulpi_port [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Tue Nov 29 19:16:34 2022 +0800

    phy: tegra: xusb: Add missing tegra_xusb_port_unregister for usb2_port and ulpi_port
    
    [ Upstream commit e024854048e733391b31fe5a398704b31b9af803 ]
    
    The tegra_xusb_port_unregister should be called when usb2_port
    and ulpi_port map fails in tegra_xusb_add_usb2_port() or in
    tegra_xusb_add_ulpi_port(), fix it.
    
    Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support")
    Signed-off-by: Gaosheng Cui <[email protected]>
    Acked-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: touchscreen_dmi: Add info for the Dexp Ursus KX210i [+ + +]
Author: Andrey Avdeev <[email protected]>
Date:   Sun Apr 30 11:01:10 2023 +0300

    platform/x86: touchscreen_dmi: Add info for the Dexp Ursus KX210i
    
    commit 4b65f95c87c35699bc6ad540d6b9dd7f950d0924 upstream.
    
    Add touchscreen info for the Dexp Ursus KX210i
    
    Signed-off-by: Andrey Avdeev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

platform/x86: touchscreen_dmi: Add upside-down quirk for GDIX1002 ts on the Juno Tablet [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Fri May 5 23:03:23 2023 +0200

    platform/x86: touchscreen_dmi: Add upside-down quirk for GDIX1002 ts on the Juno Tablet
    
    commit 6abfa99ce52f61a31bcfc2aaaae09006f5665495 upstream.
    
    The Juno Computers Juno Tablet has an upside-down mounted Goodix
    touchscreen. Add a quirk to invert both axis to correct for this.
    
    Link: https://junocomputers.com/us/product/juno-tablet/
    Cc: [email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
posix-cpu-timers: Implement the missing timer_wait_running callback [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Mon Apr 17 15:37:55 2023 +0200

    posix-cpu-timers: Implement the missing timer_wait_running callback
    
    commit f7abf14f0001a5a47539d9f60bbdca649e43536b upstream.
    
    For some unknown reason the introduction of the timer_wait_running callback
    missed to fixup posix CPU timers, which went unnoticed for almost four years.
    Marco reported recently that the WARN_ON() in timer_wait_running()
    triggers with a posix CPU timer test case.
    
    Posix CPU timers have two execution models for expiring timers depending on
    CONFIG_POSIX_CPU_TIMERS_TASK_WORK:
    
    1) If not enabled, the expiry happens in hard interrupt context so
       spin waiting on the remote CPU is reasonably time bound.
    
       Implement an empty stub function for that case.
    
    2) If enabled, the expiry happens in task work before returning to user
       space or guest mode. The expired timers are marked as firing and moved
       from the timer queue to a local list head with sighand lock held. Once
       the timers are moved, sighand lock is dropped and the expiry happens in
       fully preemptible context. That means the expiring task can be scheduled
       out, migrated, interrupted etc. So spin waiting on it is more than
       suboptimal.
    
       The timer wheel has a timer_wait_running() mechanism for RT, which uses
       a per CPU timer-base expiry lock which is held by the expiry code and the
       task waiting for the timer function to complete blocks on that lock.
    
       This does not work in the same way for posix CPU timers as there is no
       timer base and expiry for process wide timers can run on any task
       belonging to that process, but the concept of waiting on an expiry lock
       can be used too in a slightly different way:
    
        - Add a mutex to struct posix_cputimers_work. This struct is per task
          and used to schedule the expiry task work from the timer interrupt.
    
        - Add a task_struct pointer to struct cpu_timer which is used to store
          a the task which runs the expiry. That's filled in when the task
          moves the expired timers to the local expiry list. That's not
          affecting the size of the k_itimer union as there are bigger union
          members already
    
        - Let the task take the expiry mutex around the expiry function
    
        - Let the waiter acquire a task reference with rcu_read_lock() held and
          block on the expiry mutex
    
       This avoids spin-waiting on a task which might not even be on a CPU and
       works nicely for RT too.
    
    Fixes: ec8f954a40da ("posix-timers: Use a callback for cancel synchronization on PREEMPT_RT")
    Reported-by: Marco Elver <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Marco Elver <[email protected]>
    Tested-by: Sebastian Andrzej Siewior <[email protected]>
    Reviewed-by: Frederic Weisbecker <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
power: supply: generic-adc-battery: fix unit scaling [+ + +]
Author: Sebastian Reichel <[email protected]>
Date:   Fri Mar 17 23:56:57 2023 +0100

    power: supply: generic-adc-battery: fix unit scaling
    
    [ Upstream commit 44263f50065969f2344808388bd589740f026167 ]
    
    power-supply properties are reported in µV, µA and µW.
    The IIO API provides mV, mA, mW, so the values need to
    be multiplied by 1000.
    
    Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO")
    Reviewed-by: Linus Walleij <[email protected]>
    Reviewed-by: Matti Vaittinen <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/mpc512x: fix resource printk format warning [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 22 23:01:13 2023 -0800

    powerpc/mpc512x: fix resource printk format warning
    
    [ Upstream commit 7538c97e2b80ff6b7a8ea2ecf16a04355461b439 ]
    
    Use "%pa" format specifier for resource_size_t to avoid a compiler
    printk format warning.
    
    ../arch/powerpc/platforms/512x/clock-commonclk.c: In function 'mpc5121_clk_provide_backwards_compat':
    ../arch/powerpc/platforms/512x/clock-commonclk.c:989:44: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=]
      989 |         snprintf(devname, sizeof(devname), "%08x.%s", res.start, np->name); \
          |                                            ^~~~~~~~~  ~~~~~~~~~
          |                                                          |
          |                                                          resource_size_t {aka long long unsigned int}
    
    Prevents 24 such warnings.
    
    Fixes: 01f25c371658 ("clk: mpc512x: add backwards compat to the CCF code")
    Signed-off-by: Randy Dunlap <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/rtas: use memmove for potentially overlapping buffer copy [+ + +]
Author: Nathan Lynch <[email protected]>
Date:   Mon Mar 6 15:33:41 2023 -0600

    powerpc/rtas: use memmove for potentially overlapping buffer copy
    
    [ Upstream commit 271208ee5e335cb1ad280d22784940daf7ddf820 ]
    
    Using memcpy() isn't safe when buf is identical to rtas_err_buf, which
    can happen during boot before slab is up. Full context which may not
    be obvious from the diff:
    
            if (altbuf) {
                    buf = altbuf;
            } else {
                    buf = rtas_err_buf;
                    if (slab_is_available())
                            buf = kmalloc(RTAS_ERROR_LOG_MAX, GFP_ATOMIC);
            }
            if (buf)
                    memcpy(buf, rtas_err_buf, RTAS_ERROR_LOG_MAX);
    
    This was found by inspection and I'm not aware of it causing problems
    in practice. It appears to have been introduced by commit
    033ef338b6e0 ("powerpc: Merge rtas.c into arch/powerpc/kernel"); the
    old ppc64 version of this code did not have this problem.
    
    Use memmove() instead.
    
    Fixes: 033ef338b6e0 ("powerpc: Merge rtas.c into arch/powerpc/kernel")
    Signed-off-by: Nathan Lynch <[email protected]>
    Reviewed-by: Andrew Donnellan <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/sysdev/tsi108: fix resource printk format warnings [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 22 23:01:16 2023 -0800

    powerpc/sysdev/tsi108: fix resource printk format warnings
    
    [ Upstream commit 55d8bd02cc1b9f1063993b5c42c9cabf4af67dea ]
    
    Use "%pa" format specifier for resource_size_t to avoid a compiler
    printk format warning.
    
      arch/powerpc/sysdev/tsi108_pci.c: In function 'tsi108_setup_pci':
      include/linux/kern_levels.h:5:25: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'resource_size_t'
    
    Fixes: c4342ff92bed ("[POWERPC] Update mpc7448hpc2 board irq support using device tree")
    Fixes: 2b9d7467a6db ("[POWERPC] Add tsi108 pci and platform device data register function")
    Signed-off-by: Randy Dunlap <[email protected]>
    [mpe: Use pr_info() and unsplit string]
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/wii: fix resource printk format warnings [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 22 23:01:14 2023 -0800

    powerpc/wii: fix resource printk format warnings
    
    [ Upstream commit 7b69600d4da0049244e9be2f5ef5a2f8e04fcd9a ]
    
    Use "%pa" format specifier for resource_size_t to avoid compiler
    printk format warnings.
    
    ../arch/powerpc/platforms/embedded6xx/flipper-pic.c: In function 'flipper_pic_init':
    ../include/linux/kern_levels.h:5:25: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=]
    ../arch/powerpc/platforms/embedded6xx/flipper-pic.c:148:9: note: in expansion of macro 'pr_info'
      148 |         pr_info("controller at 0x%08x mapped to 0x%p\n", res.start, io_base);
          |         ^~~~~~~
    
    ../arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_init':
    ../include/linux/kern_levels.h:5:25: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=]
    ../arch/powerpc/platforms/embedded6xx/hlwd-pic.c:174:9: note: in expansion of macro 'pr_info'
      174 |         pr_info("controller at 0x%08x mapped to 0x%p\n", res.start, io_base);
          |         ^~~~~~~
    
    ../arch/powerpc/platforms/embedded6xx/wii.c: In function 'wii_ioremap_hw_regs':
    ../include/linux/kern_levels.h:5:25: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=]
    ../arch/powerpc/platforms/embedded6xx/wii.c:77:17: note: in expansion of macro 'pr_info'
       77 |                 pr_info("%s at 0x%08x mapped to 0x%p\n", name,
          |                 ^~~~~~~
    
    Fixes: 028ee972f032 ("powerpc: gamecube/wii: flipper interrupt controller support")
    Fixes: 9c21025c7845 ("powerpc: wii: hollywood interrupt controller support")
    Fixes: 5a7ee3198dfa ("powerpc: wii: platform support")
    Signed-off-by: Randy Dunlap <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
printk: declare printk_deferred_{enter,safe}() in include/linux/printk.h [+ + +]
Author: Tetsuo Handa <[email protected]>
Date:   Sun May 14 13:41:27 2023 +0900

    printk: declare printk_deferred_{enter,safe}() in include/linux/printk.h
    
    commit 85e3e7fbbb720b9897fba9a99659e31cbd1c082e upstream.
    
    [This patch implements subset of original commit 85e3e7fbbb72 ("printk:
    remove NMI tracking") where commit 1007843a9190 ("mm/page_alloc: fix
    potential deadlock on zonelist_update_seq seqlock") depends on, for
    commit 3d36424b3b58 ("mm/page_alloc: fix race condition between
    build_all_zonelists and page allocation") was backported to stable.]
    
    All NMI contexts are handled the same as the safe context: store the
    message and defer printing. There is no need to have special NMI
    context tracking for this. Using in_nmi() is enough.
    
    There are several parts of the kernel that are manually calling into
    the printk NMI context tracking in order to cause general printk
    deferred printing:
    
        arch/arm/kernel/smp.c
        arch/powerpc/kexec/crash.c
        kernel/trace/trace.c
    
    For arm/kernel/smp.c and powerpc/kexec/crash.c, provide a new
    function pair printk_deferred_enter/exit that explicitly achieves the
    same objective.
    
    For ftrace, remove the printk context manipulation completely. It was
    added in commit 03fc7f9c99c1 ("printk/nmi: Prevent deadlock when
    accessing the main log buffer in NMI"). The purpose was to enforce
    storing messages directly into the ring buffer even in NMI context.
    It really should have only modified the behavior in NMI context.
    There is no need for a special behavior any longer. All messages are
    always stored directly now. The console deferring is handled
    transparently in vprintk().
    
    Signed-off-by: John Ogness <[email protected]>
    [[email protected]: Remove special handling in ftrace.c completely.
    Signed-off-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [penguin-kernel: Copy only printk_deferred_{enter,safe}() definition ]
    Signed-off-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
pstore: Revert pmsg_lock back to a normal mutex [+ + +]
Author: John Stultz <[email protected]>
Date:   Wed Mar 8 20:40:43 2023 +0000

    pstore: Revert pmsg_lock back to a normal mutex
    
    [ Upstream commit 5239a89b06d6b199f133bf0ffea421683187f257 ]
    
    This reverts commit 76d62f24db07f22ccf9bc18ca793c27d4ebef721.
    
    So while priority inversion on the pmsg_lock is an occasional
    problem that an rt_mutex would help with, in uses where logging
    is writing to pmsg heavily from multiple threads, the pmsg_lock
    can be heavily contended.
    
    After this change landed, it was reported that cases where the
    mutex locking overhead was commonly adding on the order of 10s
    of usecs delay had suddenly jumped to ~msec delay with rtmutex.
    
    It seems the slight differences in the locks under this level
    of contention causes the normal mutexes to utilize the spinning
    optimizations, while the rtmutexes end up in the sleeping
    slowpath (which allows additional threads to pile on trying
    to take the lock).
    
    In this case, it devolves to a worse case senerio where the lock
    acquisition and scheduling overhead dominates, and each thread
    is waiting on the order of ~ms to do ~us of work.
    
    Obviously, having tons of threads all contending on a single
    lock for logging is non-optimal, so the proper fix is probably
    reworking pstore pmsg to have per-cpu buffers so we don't have
    contention.
    
    Additionally, Steven Rostedt has provided some furhter
    optimizations for rtmutexes that improves the rtmutex spinning
    path, but at least in my testing, I still see the test tripping
    into the sleeping path on rtmutexes while utilizing the spinning
    path with mutexes.
    
    But in the short term, lets revert the change to the rt_mutex
    and go back to normal mutexes to avoid a potentially major
    performance regression. And we can work on optimizations to both
    rtmutexes and finer-grained locking for pstore pmsg in the
    future.
    
    Cc: Wei Wang <[email protected]>
    Cc: Midas Chien<[email protected]>
    Cc: "Chunhui Li (李春辉)" <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: Kees Cook <[email protected]>
    Cc: Anton Vorontsov <[email protected]>
    Cc: "Guilherme G. Piccoli" <[email protected]>
    Cc: Tony Luck <[email protected]>
    Cc: [email protected]
    Fixes: 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion")
    Reported-by: "Chunhui Li (李春辉)" <[email protected]>
    Signed-off-by: John Stultz <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
pwm: meson: Fix axg ao mux parents [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Sun Apr 9 17:15:52 2023 +0200

    pwm: meson: Fix axg ao mux parents
    
    commit eb411c0cf59ae6344b34bc6f0d298a22b300627e upstream.
    
    This fix is basically the same as 9bce02ef0dfa ("pwm: meson: Fix the
    G12A AO clock parents order"). Vendor driver referenced there has
    xtal as first parent also for axg ao. In addition fix the name
    of the aoclk81 clock. Apparently name aoclk81 as used by the vendor
    driver was changed when mainlining the axg clock driver.
    
    Fixes: bccaa3f917c9 ("pwm: meson: Add clock source configuration for Meson-AXG")
    Cc: [email protected]
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Martin Blumenstingl <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pwm: meson: Fix g12a ao clk81 name [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Tue Apr 11 07:34:11 2023 +0200

    pwm: meson: Fix g12a ao clk81 name
    
    commit 9e4fa80ab7ef9eb4f7b1ea9fc31e0eb040e85e25 upstream.
    
    Fix the name of the aoclk81 clock. Apparently name aoclk81 as used by
    the vendor driver was changed when mainlining the g12a clock driver.
    
    Fixes: f41efceb46e6 ("pwm: meson: Add clock source configuration for Meson G12A")
    Cc: [email protected]
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Martin Blumenstingl <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pwm: mtk-disp: Adjust the clocks to avoid them mismatch [+ + +]
Author: Jitao Shi <[email protected]>
Date:   Sun Aug 8 21:24:29 2021 +0800

    pwm: mtk-disp: Adjust the clocks to avoid them mismatch
    
    [ Upstream commit d7a4e582587d97a586b1f7709e3bddcf35928e96 ]
    
    The clks "main" and "mm" are prepared in .probe() (and unprepared in
    .remove()). This results in the clocks being on during suspend which
    results in unnecessarily increased power consumption.
    
    Remove the clock operations from .probe() and .remove(). Add the
    clk_prepare_enable() in .enable() and the clk_disable_unprepare() in
    .disable().
    
    Signed-off-by: Jitao Shi <[email protected]>
    [[email protected]: squashed in fixup patch]
    Signed-off-by: Thierry Reding <[email protected]>
    Stable-dep-of: 36dd7f530ae7 ("pwm: mtk-disp: Disable shadow registers before setting backlight values")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: mtk-disp: Disable shadow registers before setting backlight values [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Mon Apr 3 15:30:53 2023 +0200

    pwm: mtk-disp: Disable shadow registers before setting backlight values
    
    [ Upstream commit 36dd7f530ae7d9ce9e853ffb8aa337de65c6600b ]
    
    If shadow registers usage is not desired, disable that before performing
    any write to CON0/1 registers in the .apply() callback, otherwise we may
    lose clkdiv or period/width updates.
    
    Fixes: cd4b45ac449a ("pwm: Add MediaTek MT2701 display PWM driver support")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Nícolas F. R. A. Prado <[email protected]>
    Tested-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: Alexandre Mergnat <[email protected]>
    Tested-by: Alexandre Mergnat <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: mtk-disp: Don't check the return code of pwmchip_remove() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Jul 7 18:28:27 2021 +0200

    pwm: mtk-disp: Don't check the return code of pwmchip_remove()
    
    [ Upstream commit 9b7b5736ffd5da6f8f6329ebe5f1829cbcf8afae ]
    
    pwmchip_remove() returns always 0. Don't use the value to make it
    possible to eventually change the function to return void. Also the
    driver core ignores the return value of mtk_disp_pwm_remove().
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Stable-dep-of: 36dd7f530ae7 ("pwm: mtk-disp: Disable shadow registers before setting backlight values")
    Signed-off-by: Sasha Levin <[email protected]>

 
rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed [+ + +]
Author: Zheng Yejian <[email protected]>
Date:   Fri Jan 6 15:09:34 2023 +0800

    rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed
    
    commit 7a29fb4a4771124bc61de397dbfc1554dbbcc19c upstream.
    
    Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel
    stack overflow as shown below. This issue can be reproduced by enabling
    CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",
    and then giving the following commands at the shell prompt:
    
      # cd /sys/kernel/tracing/
      # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
      # echo 1 > events/kprobes/enable
    
    This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes
    blacklist using NOKPROBE_SYMBOL().
    
    Insufficient stack space to handle exception!
    ESR: 0x00000000f2000004 -- BRK (AArch64)
    FAR: 0x0000ffffccf3e510
    Task stack:     [0xffff80000ad30000..0xffff80000ad38000]
    IRQ stack:      [0xffff800008050000..0xffff800008058000]
    Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]
    CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19
    Hardware name: linux,dummy-virt (DT)
    pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __rcu_irq_enter_check_tick+0x0/0x1b8
    lr : ct_nmi_enter+0x11c/0x138
    sp : ffff80000ad30080
    x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000
    x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000
    x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148
    x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c
    x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809
    x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000
    x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001
    x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4
    x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000
    Kernel panic - not syncing: kernel stack overflow
    CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19
    Hardware name: linux,dummy-virt (DT)
    Call trace:
     dump_backtrace+0xf8/0x108
     show_stack+0x20/0x30
     dump_stack_lvl+0x68/0x84
     dump_stack+0x1c/0x38
     panic+0x214/0x404
     add_taint+0x0/0xf8
     panic_bad_stack+0x144/0x160
     handle_bad_stack+0x38/0x58
     __bad_stack+0x78/0x7c
     __rcu_irq_enter_check_tick+0x0/0x1b8
     arm64_enter_el1_dbg.isra.0+0x14/0x20
     el1_dbg+0x2c/0x90
     el1h_64_sync_handler+0xcc/0xe8
     el1h_64_sync+0x64/0x68
     __rcu_irq_enter_check_tick+0x0/0x1b8
     arm64_enter_el1_dbg.isra.0+0x14/0x20
     el1_dbg+0x2c/0x90
     el1h_64_sync_handler+0xcc/0xe8
     el1h_64_sync+0x64/0x68
     __rcu_irq_enter_check_tick+0x0/0x1b8
     arm64_enter_el1_dbg.isra.0+0x14/0x20
     el1_dbg+0x2c/0x90
     el1h_64_sync_handler+0xcc/0xe8
     el1h_64_sync+0x64/0x68
     __rcu_irq_enter_check_tick+0x0/0x1b8
     [...]
     el1_dbg+0x2c/0x90
     el1h_64_sync_handler+0xcc/0xe8
     el1h_64_sync+0x64/0x68
     __rcu_irq_enter_check_tick+0x0/0x1b8
     arm64_enter_el1_dbg.isra.0+0x14/0x20
     el1_dbg+0x2c/0x90
     el1h_64_sync_handler+0xcc/0xe8
     el1h_64_sync+0x64/0x68
     __rcu_irq_enter_check_tick+0x0/0x1b8
     arm64_enter_el1_dbg.isra.0+0x14/0x20
     el1_dbg+0x2c/0x90
     el1h_64_sync_handler+0xcc/0xe8
     el1h_64_sync+0x64/0x68
     __rcu_irq_enter_check_tick+0x0/0x1b8
     el1_interrupt+0x28/0x60
     el1h_64_irq_handler+0x18/0x28
     el1h_64_irq+0x64/0x68
     __ftrace_set_clr_event_nolock+0x98/0x198
     __ftrace_set_clr_event+0x58/0x80
     system_enable_write+0x144/0x178
     vfs_write+0x174/0x738
     ksys_write+0xd0/0x188
     __arm64_sys_write+0x4c/0x60
     invoke_syscall+0x64/0x180
     el0_svc_common.constprop.0+0x84/0x160
     do_el0_svc+0x48/0xe8
     el0_svc+0x34/0xd0
     el0t_64_sync_handler+0xb8/0xc0
     el0t_64_sync+0x190/0x194
    SMP: stopping secondary CPUs
    Kernel Offset: 0x28da86000000 from 0xffff800008000000
    PHYS_OFFSET: 0xfffff76600000000
    CPU features: 0x00000,01a00100,0000421b
    Memory Limit: none
    
    Acked-by: Joel Fernandes (Google) <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
    Signed-off-by: Zheng Yejian <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Joel Fernandes (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rcu: Fix missing TICK_DEP_MASK_RCU_EXP dependency check [+ + +]
Author: Zqiang <[email protected]>
Date:   Tue Dec 20 22:16:25 2022 +0800

    rcu: Fix missing TICK_DEP_MASK_RCU_EXP dependency check
    
    [ Upstream commit db7b464df9d820186e98a65aa6a10f0d51fbf8ce ]
    
    This commit adds checks for the TICK_DEP_MASK_RCU_EXP bit, thus enabling
    RCU expedited grace periods to actually force-enable scheduling-clock
    interrupts on holdout CPUs.
    
    Fixes: df1e849ae455 ("rcu: Enable tick for nohz_full CPUs slow to provide expedited QS")
    Signed-off-by: Zqiang <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Frederic Weisbecker <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Anna-Maria Behnsen <[email protected]>
    Acked-by: Frederic Weisbecker <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Joel Fernandes (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/cm: Trace icm_send_rej event before the cm state is reset [+ + +]
Author: Mark Zhang <[email protected]>
Date:   Thu Mar 30 10:23:51 2023 +0300

    RDMA/cm: Trace icm_send_rej event before the cm state is reset
    
    [ Upstream commit bd9de1badac7e4ff6780365d4aa38983f5e2a436 ]
    
    Trace icm_send_rej event before the cm state is reset to idle, so that
    correct cm state will be logged. For example when an incoming request is
    rejected, the old trace log was:
        icm_send_rej: local_id=961102742 remote_id=3829151631 state=IDLE reason=REJ_CONSUMER_DEFINED
    With this patch:
        icm_send_rej: local_id=312971016 remote_id=3778819983 state=MRA_REQ_SENT reason=REJ_CONSUMER_DEFINED
    
    Fixes: 8dc105befe16 ("RDMA/cm: Add tracepoints to track MAD send operations")
    Signed-off-by: Mark Zhang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx4: Prevent shift wrapping in set_user_sq_size() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Mar 7 12:51:27 2023 +0300

    RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()
    
    [ Upstream commit d50b3c73f1ac20dabc53dc6e9d64ce9c79a331eb ]
    
    The ucmd->log_sq_bb_count variable is controlled by the user so this
    shift can wrap.  Fix it by using check_shl_overflow() in the same way
    that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined
    behavior in hns_roce_set_user_sq_size()").
    
    Fixes: 839041329fd3 ("IB/mlx4: Sanity check userspace send queue sizes")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Fix flow counter query via DEVX [+ + +]
Author: Mark Bloch <[email protected]>
Date:   Thu Apr 13 12:23:09 2023 +0300

    RDMA/mlx5: Fix flow counter query via DEVX
    
    [ Upstream commit 3e358ea8614ddfbc59ca7a3f5dff5dde2b350b2c ]
    
    Commit cited in "fixes" tag added bulk support for flow counters but it
    didn't account that's also possible to query a counter using a non-base id
    if the counter was allocated as bulk.
    
    When a user performs a query, validate the flow counter id given in the
    mailbox is inside the valid range taking bulk value into account.
    
    Fixes: 208d70f562e5 ("IB/mlx5: Support flow counters offset for bulk counters")
    Signed-off-by: Mark Bloch <[email protected]>
    Reviewed-by: Maor Gottlieb <[email protected]>
    Link: https://lore.kernel.org/r/79d7fbe291690128e44672418934256254d93115.1681377114.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Use correct device num_ports when modify DC [+ + +]
Author: Mark Zhang <[email protected]>
Date:   Thu Apr 20 04:39:06 2023 +0300

    RDMA/mlx5: Use correct device num_ports when modify DC
    
    [ Upstream commit 746aa3c8cb1a650ff2583497ac646e505831b9b9 ]
    
    Just like other QP types, when modify DC, the port_num should be compared
    with dev->num_ports, instead of HCA_CAP.num_ports.  Otherwise Multi-port
    vHCA on DC may not work.
    
    Fixes: 776a3906b692 ("IB/mlx5: Add support for DC target QP")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Zhang <[email protected]>
    Reviewed-by: Maor Gottlieb <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/rdmavt: Delete unnecessary NULL check [+ + +]
Author: Natalia Petrova <[email protected]>
Date:   Fri Mar 3 15:44:08 2023 +0300

    RDMA/rdmavt: Delete unnecessary NULL check
    
    [ Upstream commit b73a0b80c69de77d8d4942abb37066531c0169b2 ]
    
    There is no need to check 'rdi->qp_dev' for NULL. The field 'qp_dev'
    is created in rvt_register_device() which will fail if the 'qp_dev'
    allocation fails in rvt_driver_qp_init(). Overwise this pointer
    doesn't changed and passed to rvt_qp_exit() by the next step.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 0acb0cc7ecc1 ("IB/rdmavt: Initialize and teardown of qpn table")
    Signed-off-by: Natalia Petrova <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/siw: Fix potential page_array out of range access [+ + +]
Author: Daniil Dulov <[email protected]>
Date:   Mon Feb 27 01:17:51 2023 -0800

    RDMA/siw: Fix potential page_array out of range access
    
    [ Upstream commit 271bfcfb83a9f77cbae3d6e1a16e3c14132922f0 ]
    
    When seg is equal to MAX_ARRAY, the loop should break, otherwise
    it will result in out of range access.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
    Signed-off-by: Daniil Dulov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/siw: Remove namespace check from siw_netdev_event() [+ + +]
Author: Tetsuo Handa <[email protected]>
Date:   Sun Apr 2 14:10:13 2023 +0900

    RDMA/siw: Remove namespace check from siw_netdev_event()
    
    [ Upstream commit 266e9b3475ba82212062771fdbc40be0e3c06ec8 ]
    
    syzbot is reporting that siw_netdev_event(NETDEV_UNREGISTER) cannot destroy
    siw_device created after unshare(CLONE_NEWNET) due to net namespace check.
    It seems that this check was by error there and should be removed.
    
    Reported-by: syzbot <[email protected]>
    Link: https://syzkaller.appspot.com/bug?extid=5e70d01ee8985ae62a3b
    Suggested-by: Jason Gunthorpe <[email protected]>
    Suggested-by: Leon Romanovsky <[email protected]>
    Fixes: bdcf26bf9b3a ("rdma/siw: network and RDMA core interface")
    Signed-off-by: Tetsuo Handa <[email protected]>
    Link: https://lore.kernel.org/r/a44e9ac5-44e2-d575-9e30-02483cc7ffd[email protected]
    Reviewed-by: Bernard Metzler <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/srpt: Add a check for valid 'mad_agent' pointer [+ + +]
Author: Saravanan Vajravel <[email protected]>
Date:   Wed Apr 5 21:25:49 2023 -0700

    RDMA/srpt: Add a check for valid 'mad_agent' pointer
    
    [ Upstream commit eca5cd9474cd26d62f9756f536e2e656d3f62f3a ]
    
    When unregistering MAD agent, srpt module has a non-null check
    for 'mad_agent' pointer before invoking ib_unregister_mad_agent().
    This check can pass if 'mad_agent' variable holds an error value.
    The 'mad_agent' can have an error value for a short window when
    srpt_add_one() and srpt_remove_one() is executed simultaneously.
    
    In srpt module, added a valid pointer check for 'sport->mad_agent'
    before unregistering MAD agent.
    
    This issue can hit when RoCE driver unregisters ib_device
    
    Stack Trace:
    ------------
    BUG: kernel NULL pointer dereference, address: 000000000000004d
    PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0
    Oops: 0002 [#1] PREEMPT SMP NOPTI
    CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P
    Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020
    Workqueue: bnxt_re bnxt_re_task [bnxt_re]
    RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40
    Call Trace:
      ib_unregister_mad_agent+0x46/0x2f0 [ib_core]
      IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
      ? __schedule+0x20b/0x560
      srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]
      srpt_remove_one+0x20/0x150 [ib_srpt]
      remove_client_context+0x88/0xd0 [ib_core]
      bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex
      disable_device+0x8a/0x160 [ib_core]
      bond0: active interface up!
      ? kernfs_name_hash+0x12/0x80
     (NULL device *): Bonding Info Received: rdev: 000000006c0b8247
      __ib_unregister_device+0x42/0xb0 [ib_core]
     (NULL device *):         Master: mode: 4 num_slaves:2
      ib_unregister_device+0x22/0x30 [ib_core]
     (NULL device *):         Slave: id: 105069936 name:p2p1 link:0 state:0
      bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]
      bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]
    
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Reviewed-by: Selvin Xavier <[email protected]>
    Reviewed-by: Kashyap Desai <[email protected]>
    Signed-off-by: Saravanan Vajravel <s[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: core: Avoid lockdep reports when resolving supplies [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Wed Mar 29 14:33:54 2023 -0700

    regulator: core: Avoid lockdep reports when resolving supplies
    
    [ Upstream commit cba6cfdc7c3f1516f0d08ddfb24e689af0932573 ]
    
    An automated bot told me that there was a potential lockdep problem
    with regulators. This was on the chromeos-5.15 kernel, but I see
    nothing that would be different downstream compared to upstream. The
    bot said:
      ============================================
      WARNING: possible recursive locking detected
      5.15.104-lockdep-17461-gc1e499ed6604 #1 Not tainted
      --------------------------------------------
      kworker/u16:4/115 is trying to acquire lock:
      ffffff8083110170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: create_regulator+0x398/0x7ec
    
      but task is already holding lock:
      ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8
    
      other info that might help us debug this:
       Possible unsafe locking scenario:
    
             CPU0
             ----
        lock(regulator_ww_class_mutex);
        lock(regulator_ww_class_mutex);
    
       *** DEADLOCK ***
    
       May be due to missing lock nesting notation
    
      4 locks held by kworker/u16:4/115:
       #0: ffffff808006a948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x520/0x1348
       #1: ffffffc00e0a7cc0 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x55c/0x1348
       #2: ffffff80828a2260 (&dev->mutex){....}-{3:3}, at: __device_attach_async_helper+0xd0/0x2a4
       #3: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8
    
      stack backtrace:
      CPU: 2 PID: 115 Comm: kworker/u16:4 Not tainted 5.15.104-lockdep-17461-gc1e499ed6604 #1 9292e52fa83c0e23762b2b3aa1bacf5787a4d5da
      Hardware name: Google Quackingstick (rev0+) (DT)
      Workqueue: events_unbound async_run_entry_fn
      Call trace:
       dump_backtrace+0x0/0x4ec
       show_stack+0x34/0x50
       dump_stack_lvl+0xdc/0x11c
       dump_stack+0x1c/0x48
       __lock_acquire+0x16d4/0x6c74
       lock_acquire+0x208/0x750
       __mutex_lock_common+0x11c/0x11f8
       ww_mutex_lock+0xc0/0x440
       create_regulator+0x398/0x7ec
       regulator_resolve_supply+0x654/0x7c4
       regulator_register_resolve_supply+0x30/0x120
       class_for_each_device+0x1b8/0x230
       regulator_register+0x17a4/0x1f40
       devm_regulator_register+0x60/0xd0
       reg_fixed_voltage_probe+0x728/0xaec
       platform_probe+0x150/0x1c8
       really_probe+0x274/0xa20
       __driver_probe_device+0x1dc/0x3f4
       driver_probe_device+0x78/0x1c0
       __device_attach_driver+0x1ac/0x2c8
       bus_for_each_drv+0x11c/0x190
       __device_attach_async_helper+0x1e4/0x2a4
       async_run_entry_fn+0xa0/0x3ac
       process_one_work+0x638/0x1348
       worker_thread+0x4a8/0x9c4
       kthread+0x2e4/0x3a0
       ret_from_fork+0x10/0x20
    
    The problem was first reported soon after we made many of the
    regulators probe asynchronously, though nothing I've seen implies that
    the problems couldn't have also happened even without that.
    
    I haven't personally been able to reproduce the lockdep issue, but the
    issue does look somewhat legitimate. Specifically, it looks like in
    regulator_resolve_supply() we are holding a "rdev" lock while calling
    set_supply() -> create_regulator() which grabs the lock of a
    _different_ "rdev" (the one for our supply). This is not necessarily
    safe from a lockdep perspective since there is no documented ordering
    between these two locks.
    
    In reality, we should always be locking a regulator before the
    supplying regulator, so I don't expect there to be any real deadlocks
    in practice. However, the regulator framework in general doesn't
    express this to lockdep.
    
    Let's fix the issue by simply grabbing the two locks involved in the
    same way we grab multiple locks elsewhere in the regulator framework:
    using the "wound/wait" mechanisms.
    
    Fixes: eaa7995c529b ("regulator: core: avoid regulator_resolve_supply() race condition")
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeid
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

regulator: core: Consistently set mutex_owner when using ww_mutex_lock_slow() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Wed Mar 29 14:33:53 2023 -0700

    regulator: core: Consistently set mutex_owner when using ww_mutex_lock_slow()
    
    [ Upstream commit b83a1772be854f87602de14726737d3e5b06e1f4 ]
    
    When a codepath locks a rdev using ww_mutex_lock_slow() directly then
    that codepath is responsible for incrementing the "ref_cnt" and also
    setting the "mutex_owner" to "current".
    
    The regulator core consistently got that right for "ref_cnt" but
    didn't always get it right for "mutex_owner". Let's fix this.
    
    It's unlikely that this truly matters because the "mutex_owner" is
    only needed if we're going to do subsequent locking of the same
    rdev. However, even though it's not truly needed it seems less
    surprising if we consistently set "mutex_owner" properly.
    
    Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeid
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

regulator: stm32-pwr: fix of_iomap leak [+ + +]
Author: YAN SHI <[email protected]>
Date:   Wed Apr 12 11:35:29 2023 +0800

    regulator: stm32-pwr: fix of_iomap leak
    
    [ Upstream commit c4a413e56d16a2ae84e6d8992f215c4dcc7fac20 ]
    
    Smatch reports:
    drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn:
    'base' from of_iomap() not released on lines: 151,166.
    
    In stm32_pwr_regulator_probe(), base is not released
    when devm_kzalloc() fails to allocate memory or
    devm_regulator_register() fails to register a new regulator device,
    which may cause a leak.
    
    To fix this issue, replace of_iomap() with
    devm_platform_ioremap_resource(). devm_platform_ioremap_resource()
    is a specialized function for platform devices.
    It allows 'base' to be automatically released whether the probe
    function succeeds or fails.
    
    Besides, use IS_ERR(base) instead of !base
    as the return value of devm_platform_ioremap_resource()
    can either be a pointer to the remapped memory or
    an ERR_PTR() encoded error code if the operation fails.
    
    Fixes: dc62f951a6a8 ("regulator: stm32-pwr: Fix return value check in stm32_pwr_regulator_probe()")
    Signed-off-by: YAN SHI <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Reviewed-by: Dongliang Mu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
reiserfs: Add security prefix to xattr name in reiserfs_security_write() [+ + +]
Author: Roberto Sassu <[email protected]>
Date:   Fri Mar 31 14:32:18 2023 +0200

    reiserfs: Add security prefix to xattr name in reiserfs_security_write()
    
    commit d82dcd9e21b77d338dc4875f3d4111f0db314a7c upstream.
    
    Reiserfs sets a security xattr at inode creation time in two stages: first,
    it calls reiserfs_security_init() to obtain the xattr from active LSMs;
    then, it calls reiserfs_security_write() to actually write that xattr.
    
    Unfortunately, it seems there is a wrong expectation that LSMs provide the
    full xattr name in the form 'security.<suffix>'. However, LSMs always
    provided just the suffix, causing reiserfs to not write the xattr at all
    (if the suffix is shorter than the prefix), or to write an xattr with the
    wrong name.
    
    Add a temporary buffer in reiserfs_security_write(), and write to it the
    full xattr name, before passing it to reiserfs_xattr_set_handle().
    
    Also replace the name length check with a check that the full xattr name is
    not larger than XATTR_NAME_MAX.
    
    Cc: [email protected] # v2.6.x
    Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation")
    Signed-off-by: Roberto Sassu <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
relayfs: fix out-of-bounds access in relay_file_read [+ + +]
Author: Zhang Zhengming <[email protected]>
Date:   Wed Apr 19 12:02:03 2023 +0800

    relayfs: fix out-of-bounds access in relay_file_read
    
    commit 43ec16f1450f4936025a9bdf1a273affdb9732c1 upstream.
    
    There is a crash in relay_file_read, as the var from
    point to the end of last subbuf.
    
    The oops looks something like:
    pc : __arch_copy_to_user+0x180/0x310
    lr : relay_file_read+0x20c/0x2c8
    Call trace:
     __arch_copy_to_user+0x180/0x310
     full_proxy_read+0x68/0x98
     vfs_read+0xb0/0x1d0
     ksys_read+0x6c/0xf0
     __arm64_sys_read+0x20/0x28
     el0_svc_common.constprop.3+0x84/0x108
     do_el0_svc+0x74/0x90
     el0_svc+0x1c/0x28
     el0_sync_handler+0x88/0xb0
     el0_sync+0x148/0x180
    
    We get the condition by analyzing the vmcore:
    
    1). The last produced byte and last consumed byte
        both at the end of the last subbuf
    
    2). A softirq calls function(e.g __blk_add_trace)
        to write relay buffer occurs when an program is calling
        relay_file_read_avail().
    
            relay_file_read
                    relay_file_read_avail
                            relay_file_read_consume(buf, 0, 0);
                            //interrupted by softirq who will write subbuf
                            ....
                            return 1;
                    //read_start point to the end of the last subbuf
                    read_start = relay_file_read_start_pos
                    //avail is equal to subsize
                    avail = relay_file_read_subbuf_avail
                    //from  points to an invalid memory address
                    from = buf->start + read_start
                    //system is crashed
                    copy_to_user(buffer, from, avail)
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 8d62fdebdaf9 ("relay file read: start-pos fix")
    Signed-off-by: Zhang Zhengming <zh[email protected]>
    Reviewed-by: Zhao Lei <[email protected]>
    Reviewed-by: Zhou Kete <[email protected]>
    Reviewed-by: Pengcheng Yang <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
remoteproc: st: Call of_node_put() on iteration error [+ + +]
Author: Mathieu Poirier <[email protected]>
Date:   Mon Mar 20 16:18:23 2023 -0600

    remoteproc: st: Call of_node_put() on iteration error
    
    commit 8a74918948b40317a5b5bab9739d13dcb5de2784 upstream.
    
    Function of_phandle_iterator_next() calls of_node_put() on the last
    device_node it iterated over, but when the loop exits prematurely it has
    to be called explicitly.
    
    Fixes: 3df52ed7f269 ("remoteproc: st: add reserved memory support")
    Cc: [email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Reviewed-by: Arnaud Pouliquen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

remoteproc: stm32: Call of_node_put() on iteration error [+ + +]
Author: Mathieu Poirier <[email protected]>
Date:   Mon Mar 20 16:18:22 2023 -0600

    remoteproc: stm32: Call of_node_put() on iteration error
    
    commit ccadca5baf5124a880f2bb50ed1ec265415f025b upstream.
    
    Function of_phandle_iterator_next() calls of_node_put() on the last
    device_node it iterated over, but when the loop exits prematurely it has
    to be called explicitly.
    
    Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver")
    Cc: [email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Reviewed-by: Arnaud Pouliquen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work" [+ + +]
Author: Liu Jian <[email protected]>
Date:   Fri Apr 14 18:30:06 2023 +0800

    Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"
    
    [ Upstream commit db2bf510bd5d57f064d9e1db395ed86a08320c54 ]
    
    This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.
    
    This patch introduces a possible null-ptr-def problem. Revert it. And the
    fixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:
    btsdio: fix use after free bug in btsdio_remove due to race condition").
    
    Fixes: 1e9ac114c442 ("Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work")
    Signed-off-by: Liu Jian <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "ubifs: dirty_cow_znode: Fix memleak in error handling path" [+ + +]
Author: Zhihao Cheng <[email protected]>
Date:   Wed Mar 1 20:29:18 2023 +0800

    Revert "ubifs: dirty_cow_znode: Fix memleak in error handling path"
    
    commit 7d01cb27f6aebc54efbe28d8961a973b8f795b13 upstream.
    
    This reverts commit 122deabfe1428 (ubifs: dirty_cow_znode: Fix memleak
    in error handling path).
    After commit 122deabfe1428 applied, if insert_old_idx() failed, old
    index neither exists in TNC nor in old-index tree. Which means that
    old index node could be overwritten in layout_leb_in_gaps(), then
    ubifs image will be corrupted in power-cut.
    
    Fixes: 122deabfe1428 (ubifs: dirty_cow_znode: Fix memleak ... path)
    Cc: [email protected]
    Signed-off-by: Zhihao Cheng <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ring-buffer: Ensure proper resetting of atomic variables in ring_buffer_reset_online_cpus [+ + +]
Author: Tze-nan Wu <[email protected]>
Date:   Wed Apr 26 14:20:23 2023 +0800

    ring-buffer: Ensure proper resetting of atomic variables in ring_buffer_reset_online_cpus
    
    [ Upstream commit 7c339fb4d8577792378136c15fde773cfb863cb8 ]
    
    In ring_buffer_reset_online_cpus, the buffer_size_kb write operation
    may permanently fail if the cpu_online_mask changes between two
    for_each_online_buffer_cpu loops. The number of increases and decreases
    on both cpu_buffer->resize_disabled and cpu_buffer->record_disabled may be
    inconsistent, causing some CPUs to have non-zero values for these atomic
    variables after the function returns.
    
    This issue can be reproduced by "echo 0 > trace" while hotplugging cpu.
    After reproducing success, we can find out buffer_size_kb will not be
    functional anymore.
    
    To prevent leaving 'resize_disabled' and 'record_disabled' non-zero after
    ring_buffer_reset_online_cpus returns, we ensure that each atomic variable
    has been set up before atomic_sub() to it.
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: [email protected]
    Cc: <[email protected]>
    Cc: [email protected]
    Fixes: b23d7a5f4a07 ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU")
    Reviewed-by: Cheng-Jui Wang <[email protected]>
    Signed-off-by: Tze-nan Wu <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ring-buffer: Sync IRQ works before buffer destruction [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Thu Apr 27 17:59:20 2023 +0200

    ring-buffer: Sync IRQ works before buffer destruction
    
    commit 675751bb20634f981498c7d66161584080cc061e upstream.
    
    If something was written to the buffer just before destruction,
    it may be possible (maybe not in a real system, but it did
    happen in ARCH=um with time-travel) to destroy the ringbuffer
    before the IRQ work ran, leading this KASAN report (or a crash
    without KASAN):
    
        BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a
        Read of size 8 at addr 000000006d640a48 by task swapper/0
    
        CPU: 0 PID: 0 Comm: swapper Tainted: G        W  O       6.3.0-rc1 #7
        Stack:
         60c4f20f 0c203d48 41b58ab3 60f224fc
         600477fa 60f35687 60c4f20f 601273dd
         00000008 6101eb00 6101eab0 615be548
        Call Trace:
         [<60047a58>] show_stack+0x25e/0x282
         [<60c609e0>] dump_stack_lvl+0x96/0xfd
         [<60c50d4c>] print_report+0x1a7/0x5a8
         [<603078d3>] kasan_report+0xc1/0xe9
         [<60308950>] __asan_report_load8_noabort+0x1b/0x1d
         [<60232844>] irq_work_run_list+0x11a/0x13a
         [<602328b4>] irq_work_tick+0x24/0x34
         [<6017f9dc>] update_process_times+0x162/0x196
         [<6019f335>] tick_sched_handle+0x1a4/0x1c3
         [<6019fd9e>] tick_sched_timer+0x79/0x10c
         [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695
         [<60182913>] hrtimer_interrupt+0x16c/0x2c4
         [<600486a3>] um_timer+0x164/0x183
         [...]
    
        Allocated by task 411:
         save_stack_trace+0x99/0xb5
         stack_trace_save+0x81/0x9b
         kasan_save_stack+0x2d/0x54
         kasan_set_track+0x34/0x3e
         kasan_save_alloc_info+0x25/0x28
         ____kasan_kmalloc+0x8b/0x97
         __kasan_kmalloc+0x10/0x12
         __kmalloc+0xb2/0xe8
         load_elf_phdrs+0xee/0x182
         [...]
    
        The buggy address belongs to the object at 000000006d640800
         which belongs to the cache kmalloc-1k of size 1024
        The buggy address is located 584 bytes inside of
         freed 1024-byte region [000000006d640800, 000000006d640c00)
    
    Add the appropriate irq_work_sync() so the work finishes before
    the buffers are destroyed.
    
    Prior to the commit in the Fixes tag below, there was only a
    single global IRQ work, so this issue didn't exist.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230427175920.a76159263122.I8295e405c44362a86c995e9c2c37e3e03810aa56@changeid
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Fixes: 15693458c4bc ("tracing/ring-buffer: Move poll wake ups into ring buffer code")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rtc: meson-vrtc: Use ktime_get_real_ts64() to get the current time [+ + +]
Author: Martin Blumenstingl <[email protected]>
Date:   Mon Mar 20 22:21:42 2023 +0100

    rtc: meson-vrtc: Use ktime_get_real_ts64() to get the current time
    
    [ Upstream commit 0e6255fa3f649170da6bd1a544680589cfae1131 ]
    
    The VRTC alarm register can be programmed with an amount of seconds
    after which the SoC will be woken up by the VRTC timer again. We are
    already converting the alarm time from meson_vrtc_set_alarm() to
    "seconds since 1970". This means we also need to use "seconds since
    1970" for the current time.
    
    This fixes a problem where setting the alarm to one minute in the future
    results in the firmware (which handles wakeup) to output (on the serial
    console) that the system will be woken up in billions of seconds.
    ktime_get_raw_ts64() returns the time since boot, not since 1970. Switch
    to ktime_get_real_ts64() to fix the calculation of the alarm time and to
    make the SoC wake up at the specified date/time. Also the firmware
    (which manages suspend) now prints either 59 or 60 seconds until wakeup
    (depending on how long it takes for the system to enter suspend).
    
    Fixes: 6ef35398e827 ("rtc: Add Amlogic Virtual Wake RTC")
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rtc: omap: include header for omap_rtc_power_off_program prototype [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sat Mar 11 10:40:21 2023 +0100

    rtc: omap: include header for omap_rtc_power_off_program prototype
    
    [ Upstream commit f69c2b5420497b7a54181ce170d682cbeb1f119f ]
    
    Non-static functions should have a prototype:
    
      drivers/rtc/rtc-omap.c:410:5: error: no previous prototype for ‘omap_rtc_power_off_program’ [-Werror=missing-prototypes]
    
    Fixes: 6256f7f7f217 ("rtc: OMAP: Add support for rtc-only mode")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rxrpc: Fix hard call timeout units [+ + +]
Author: David Howells <[email protected]>
Date:   Fri Apr 28 21:27:54 2023 +0100

    rxrpc: Fix hard call timeout units
    
    [ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]
    
    The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
    seconds, so fix the point at which sendmsg() applies it to the call to
    convert to jiffies from seconds, not milliseconds.
    
    Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
    Signed-off-by: David Howells <[email protected]>
    cc: Marc Dionne <[email protected]>
    cc: "David S. Miller" <[email protected]>
    cc: Eric Dumazet <[email protected]>
    cc: Jakub Kicinski <[email protected]>
    cc: Paolo Abeni <[email protected]>
    cc: [email protected]
    cc: [email protected]
    cc: [email protected]
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/dasd: fix hanging blockdevice after request requeue [+ + +]
Author: Stefan Haberland <[email protected]>
Date:   Wed Apr 5 16:20:17 2023 +0200

    s390/dasd: fix hanging blockdevice after request requeue
    
    commit d8898ee50edecacdf0141f26fd90acf43d7e9cd7 upstream.
    
    The DASD driver does not kick the requeue list when requeuing IO requests
    to the blocklayer. This might lead to hanging blockdevice when there is
    no other trigger for this.
    
    Fix by automatically kick the requeue list when requeuing DASD requests
    to the blocklayer.
    
    Fixes: e443343e509a ("s390/dasd: blk-mq conversion")
    CC: [email protected] # 4.14+
    Signed-off-by: Stefan Haberland <[email protected]>
    Reviewed-by: Jan Hoeppner <[email protected]>
    Reviewed-by: Halil Pasic <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scm: fix MSG_CTRUNC setting condition for SO_PASSSEC [+ + +]
Author: Alexander Mikhalitsyn <[email protected]>
Date:   Mon Mar 13 12:32:11 2023 +0100

    scm: fix MSG_CTRUNC setting condition for SO_PASSSEC
    
    [ Upstream commit a02d83f9947d8f71904eda4de046630c3eb6802c ]
    
    Currently, kernel would set MSG_CTRUNC flag if msg_control buffer
    wasn't provided and SO_PASSCRED was set or if there was pending SCM_RIGHTS.
    
    For some reason we have no corresponding check for SO_PASSSEC.
    
    In the recvmsg(2) doc we have:
           MSG_CTRUNC
                  indicates that some control data was discarded due to lack
                  of space in the buffer for ancillary data.
    
    So, we need to set MSG_CTRUNC flag for all types of SCM.
    
    This change can break applications those don't check MSG_CTRUNC flag.
    
    Cc: "David S. Miller" <[email protected]>
    Cc: Eric Dumazet <[email protected]>
    Cc: Jakub Kicinski <[email protected]>
    Cc: Paolo Abeni <[email protected]>
    Cc: Leon Romanovsky <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Alexander Mikhalitsyn <[email protected]>
    
    v2:
    - commit message was rewritten according to Eric's suggestion
    Acked-by: Paul Moore <[email protected]>
    
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
scripts/gdb: bail early if there are no clocks [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 23 15:52:45 2023 -0700

    scripts/gdb: bail early if there are no clocks
    
    [ Upstream commit 1d7adbc74c009057ed9dc3112f388e91a9c79acc ]
    
    Avoid generating an exception if there are no clocks registered:
    
    (gdb) lx-clk-summary
                                     enable  prepare  protect
       clock                          count    count    count        rate
    ------------------------------------------------------------------------
    Python Exception <class 'gdb.error'>: No symbol "clk_root_list" in
    current context.
    Error occurred in Python: No symbol "clk_root_list" in current context.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: d1e9710b63d8 ("scripts/gdb: initial clk support: lx-clk-summary")
    Signed-off-by: Florian Fainelli <[email protected]>
    Cc: Jan Kiszka <ja[email protected]>
    Cc: Kieran Bingham <[email protected]>
    Cc: Leonard Crestez <[email protected]>
    Cc: Stephen Boyd <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scripts/gdb: bail early if there are no generic PD [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 23 16:16:57 2023 -0700

    scripts/gdb: bail early if there are no generic PD
    
    [ Upstream commit f19c3c2959e465209ade1a7a699e6cbf4359ce78 ]
    
    Avoid generating an exception if there are no generic power domain(s)
    registered:
    
    (gdb) lx-genpd-summary
    domain                          status          children
        /device                                             runtime status
    ----------------------------------------------------------------------
    Python Exception <class 'gdb.error'>: No symbol "gpd_list" in current context.
    Error occurred in Python: No symbol "gpd_list" in current context.
    (gdb) quit
    
    [[email protected]: correctly invoke gdb_eval_or_none]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 8207d4a88e1e ("scripts/gdb: add lx-genpd-summary command")
    Signed-off-by: Florian Fainelli <f.fain[email protected]>
    Cc: Jan Kiszka <[email protected]>
    Cc: Kieran Bingham <[email protected]>
    Cc: Leonard Crestez <[email protected]>
    Cc: Stephen Boyd <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scripts/gdb: fix lx-timerlist for Python3 [+ + +]
Author: Peng Liu <[email protected]>
Date:   Tue Mar 21 14:19:29 2023 +0800

    scripts/gdb: fix lx-timerlist for Python3
    
    commit 7362042f3556528e9e9b1eb5ce8d7a3a6331476b upstream.
    
    Below incompatibilities between Python2 and Python3 made lx-timerlist fail
    to run under Python3.
    
    o xrange() is replaced by range() in Python3
    o bytes and str are different types in Python3
    o the return value of Inferior.read_memory() is memoryview object in
      Python3
    
    akpm: cc stable so that older kernels are properly debuggable under newer
    Python.
    
    Link: https://lkml.kernel.org/r/TYCP286MB2146EE1180A4D5176CBA8AB2C6819@TYCP286MB2146.JPNP286.PROD.OUTLOOK.COM
    Signed-off-by: Peng Liu <[email protected]>
    Reviewed-by: Jan Kiszka <[email protected]>
    Cc: Florian Fainelli <[email protected]>
    Cc: Kieran Bingham <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup() [+ + +]
Author: Shuchang Li <[email protected]>
Date:   Tue Apr 4 15:21:32 2023 +0800

    scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()
    
    [ Upstream commit 91a0c0c1413239d0548b5aac4c82f38f6d53a91e ]
    
    When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4)
    returns false, drbl_regs_memmap_p is not remapped. This passes a NULL
    pointer to iounmap(), which can trigger a WARN() on certain arches.
    
    When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4)
    returns true, drbl_regs_memmap_p may has been remapped and
    ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a
    NULL pointer to iounmap().
    
    To fix these issues, we need to add null checks before iounmap(), and
    change some goto labels.
    
    Fixes: 1351e69fc6db ("scsi: lpfc: Add push-to-adapter support to sli4")
    Signed-off-by: Shuchang Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Justin Tee <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: megaraid: Fix mega_cmd_done() CMDID_INT_CMDS [+ + +]
Author: Danila Chernetsov <[email protected]>
Date:   Fri Mar 17 17:51:09 2023 +0000

    scsi: megaraid: Fix mega_cmd_done() CMDID_INT_CMDS
    
    [ Upstream commit 75cb113cd43f06aaf4f1bda0069cfd5b98e909eb ]
    
    When cmdid == CMDID_INT_CMDS, the 'cmds' pointer is NULL but is
    dereferenced below.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 0f2bb84d2a68 ("[SCSI] megaraid: simplify internal command handling")
    Signed-off-by: Danila Chernetsov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qedi: Fix use after free bug in qedi_remove() [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Thu Apr 13 11:34:22 2023 +0800

    scsi: qedi: Fix use after free bug in qedi_remove()
    
    [ Upstream commit c5749639f2d0a1f6cbe187d05f70c2e7c544d748 ]
    
    In qedi_probe() we call __qedi_probe() which initializes
    &qedi->recovery_work with qedi_recovery_handler() and
    &qedi->board_disable_work with qedi_board_disable_work().
    
    When qedi_schedule_recovery_handler() is called, schedule_delayed_work()
    will finally start the work.
    
    In qedi_remove(), which is called to remove the driver, the following
    sequence may be observed:
    
    Fix this by finishing the work before cleanup in qedi_remove().
    
    CPU0                  CPU1
    
                         |qedi_recovery_handler
    qedi_remove          |
      __qedi_remove      |
    iscsi_host_free      |
    scsi_host_put        |
    //free shost         |
                         |iscsi_host_for_each_session
                         |//use qedi->shost
    
    Cancel recovery_work and board_disable_work in __qedi_remove().
    
    Fixes: 4b1068f5d74b ("scsi: qedi: Add MFW error recovery process")
    Signed-off-by: Zheng Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Manish Rangankar <[email protected]>
    Reviewed-by: Mike Christie <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: core: Avoid smp_processor_id() in preemptible code [+ + +]
Author: Shin'ichiro Kawasaki <[email protected]>
Date:   Sat May 15 16:03:15 2021 +0900

    scsi: target: core: Avoid smp_processor_id() in preemptible code
    
    commit 70ca3c57ff914113f681e657634f7fbfa68e1ad1 upstream.
    
    The BUG message "BUG: using smp_processor_id() in preemptible [00000000]
    code" was observed for TCMU devices with kernel config DEBUG_PREEMPT.
    
    The message was observed when blktests block/005 was run on TCMU devices
    with fileio backend or user:zbc backend [1]. The commit 1130b499b4a7
    ("scsi: target: tcm_loop: Use LIO wq cmd submission helper") triggered the
    symptom. The commit modified work queue to handle commands and changed
    'current->nr_cpu_allowed' at smp_processor_id() call.
    
    The message was also observed at system shutdown when TCMU devices were not
    cleaned up [2]. The function smp_processor_id() was called in SCSI host
    work queue for abort handling, and triggered the BUG message. This symptom
    was observed regardless of the commit 1130b499b4a7 ("scsi: target:
    tcm_loop: Use LIO wq cmd submission helper").
    
    To avoid the preemptible code check at smp_processor_id(), get CPU ID with
    raw_smp_processor_id() instead. The CPU ID is used for performance
    improvement then thread move to other CPU will not affect the code.
    
    [1]
    
    [   56.468103] run blktests block/005 at 2021-05-12 14:16:38
    [   57.369473] check_preemption_disabled: 85 callbacks suppressed
    [   57.369480] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1511
    [   57.369506] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1510
    [   57.369512] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1506
    [   57.369552] caller is __target_init_cmd+0x157/0x170 [target_core_mod]
    [   57.369606] CPU: 4 PID: 1506 Comm: fio Not tainted 5.13.0-rc1+ #34
    [   57.369613] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018
    [   57.369617] Call Trace:
    [   57.369621] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1507
    [   57.369628]  dump_stack+0x6d/0x89
    [   57.369642]  check_preemption_disabled+0xc8/0xd0
    [   57.369628] caller is __target_init_cmd+0x157/0x170 [target_core_mod]
    [   57.369655]  __target_init_cmd+0x157/0x170 [target_core_mod]
    [   57.369695]  target_init_cmd+0x76/0x90 [target_core_mod]
    [   57.369732]  tcm_loop_queuecommand+0x109/0x210 [tcm_loop]
    [   57.369744]  scsi_queue_rq+0x38e/0xc40
    [   57.369761]  __blk_mq_try_issue_directly+0x109/0x1c0
    [   57.369779]  blk_mq_try_issue_directly+0x43/0x90
    [   57.369790]  blk_mq_submit_bio+0x4e5/0x5d0
    [   57.369812]  submit_bio_noacct+0x46e/0x4e0
    [   57.369830]  __blkdev_direct_IO_simple+0x1a3/0x2d0
    [   57.369859]  ? set_init_blocksize.isra.0+0x60/0x60
    [   57.369880]  generic_file_read_iter+0x89/0x160
    [   57.369898]  blkdev_read_iter+0x44/0x60
    [   57.369906]  new_sync_read+0x102/0x170
    [   57.369929]  vfs_read+0xd4/0x160
    [   57.369941]  __x64_sys_pread64+0x6e/0xa0
    [   57.369946]  ? lockdep_hardirqs_on+0x79/0x100
    [   57.369958]  do_syscall_64+0x3a/0x70
    [   57.369965]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   57.369973] RIP: 0033:0x7f7ed4c1399f
    [   57.369979] Code: 08 89 3c 24 48 89 4c 24 18 e8 7d f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 04 24 e8 cd f3 ff ff 48 8b
    [   57.369983] RSP: 002b:00007ffd7918c580 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
    [   57.369990] RAX: ffffffffffffffda RBX: 00000000015b4540 RCX: 00007f7ed4c1399f
    [   57.369993] RDX: 0000000000001000 RSI: 00000000015de000 RDI: 0000000000000009
    [   57.369996] RBP: 00000000015b4540 R08: 0000000000000000 R09: 0000000000000001
    [   57.369999] R10: 0000000000e5c000 R11: 0000000000000293 R12: 00007f7eb5269a70
    [   57.370002] R13: 0000000000000000 R14: 0000000000001000 R15: 00000000015b4568
    [   57.370031] CPU: 7 PID: 1507 Comm: fio Not tainted 5.13.0-rc1+ #34
    [   57.370036] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018
    [   57.370039] Call Trace:
    [   57.370045]  dump_stack+0x6d/0x89
    [   57.370056]  check_preemption_disabled+0xc8/0xd0
    [   57.370068]  __target_init_cmd+0x157/0x170 [target_core_mod]
    [   57.370121]  target_init_cmd+0x76/0x90 [target_core_mod]
    [   57.370178]  tcm_loop_queuecommand+0x109/0x210 [tcm_loop]
    [   57.370197]  scsi_queue_rq+0x38e/0xc40
    [   57.370224]  __blk_mq_try_issue_directly+0x109/0x1c0
    ...
    
    [2]
    
    [  117.458597] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u16:8
    [  117.467279] caller is __target_init_cmd+0x157/0x170 [target_core_mod]
    [  117.473893] CPU: 1 PID: 418 Comm: kworker/u16:6 Not tainted 5.13.0-rc1+ #34
    [  117.481150] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 8
    [  117.481153] Workqueue: scsi_tmf_7 scmd_eh_abort_handler
    [  117.481156] Call Trace:
    [  117.481158]  dump_stack+0x6d/0x89
    [  117.481162]  check_preemption_disabled+0xc8/0xd0
    [  117.512575]  target_submit_tmr+0x41/0x150 [target_core_mod]
    [  117.519705]  tcm_loop_issue_tmr+0xa7/0x100 [tcm_loop]
    [  117.524913]  tcm_loop_abort_task+0x43/0x60 [tcm_loop]
    [  117.530137]  scmd_eh_abort_handler+0x7b/0x230
    [  117.534681]  process_one_work+0x268/0x580
    [  117.538862]  worker_thread+0x55/0x3b0
    [  117.542652]  ? process_one_work+0x580/0x580
    [  117.548351]  kthread+0x143/0x160
    [  117.551675]  ? kthread_create_worker_on_cpu+0x40/0x40
    [  117.556873]  ret_from_fork+0x1f/0x30
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 1526d9f10c61 ("scsi: target: Make state_list per CPU")
    Cc: [email protected] # v5.11+
    Reviewed-by: Mike Christie <[email protected]>
    Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: target: Fix multiple LUN_RESET handling [+ + +]
Author: Mike Christie <[email protected]>
Date:   Sat Mar 18 20:56:18 2023 -0500

    scsi: target: Fix multiple LUN_RESET handling
    
    [ Upstream commit 673db054d7a2b5a470d7a25baf65956d005ad729 ]
    
    This fixes a bug where an initiator thinks a LUN_RESET has cleaned up
    running commands when it hasn't. The bug was added in commit 51ec502a3266
    ("target: Delete tmr from list before processing").
    
    The problem occurs when:
    
     1. We have N I/O cmds running in the target layer spread over 2 sessions.
    
     2. The initiator sends a LUN_RESET for each session.
    
     3. session1's LUN_RESET loops over all the running commands from both
        sessions and moves them to its local drain_task_list.
    
     4. session2's LUN_RESET does not see the LUN_RESET from session1 because
        the commit above has it remove itself. session2 also does not see any
        commands since the other reset moved them off the state lists.
    
     5. sessions2's LUN_RESET will then complete with a successful response.
    
     6. sessions2's inititor believes the running commands on its session are
        now cleaned up due to the successful response and cleans up the running
        commands from its side. It then restarts them.
    
     7. The commands do eventually complete on the backend and the target
        starts to return aborted task statuses for them. The initiator will
        either throw a invalid ITT error or might accidentally lookup a new
        task if the ITT has been reallocated already.
    
    Fix the bug by reverting the patch, and serialize the execution of
    LUN_RESETs and Preempt and Aborts.
    
    Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,
    because it turns out the original patch fixed a bug that was not
    mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second
    LUN_RESET and wait on it. Then the second reset will run
    core_tmr_drain_tmr_list and see the first reset and wait on it resulting in
    a deadlock.
    
    Fixes: 51ec502a3266 ("target: Delete tmr from list before processing")
    Signed-off-by: Mike Christie <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: iscsit: Fix TAS handling during conn cleanup [+ + +]
Author: Mike Christie <[email protected]>
Date:   Sat Mar 18 20:56:19 2023 -0500

    scsi: target: iscsit: Fix TAS handling during conn cleanup
    
    [ Upstream commit cc79da306ebb2edb700c3816b90219223182ac3c ]
    
    Fix a bug added in commit f36199355c64 ("scsi: target: iscsi: Fix cmd abort
    fabric stop race").
    
    If CMD_T_TAS is set on the se_cmd we must call iscsit_free_cmd() to do the
    last put on the cmd and free it, because the connection is down and we will
    not up sending the response and doing the put from the normal I/O
    path.
    
    Add a check for CMD_T_TAS in iscsit_release_commands_from_conn() so we now
    detect this case and run iscsit_free_cmd().
    
    Fixes: f36199355c64 ("scsi: target: iscsi: Fix cmd abort fabric stop race")
    Signed-off-by: Mike Christie <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: Make state_list per CPU [+ + +]
Author: Mike Christie <[email protected]>
Date:   Sun Nov 1 12:59:33 2020 -0600

    scsi: target: Make state_list per CPU
    
    [ Upstream commit 1526d9f10c6184031e42afad0adbdde1213e8ad1 ]
    
    Do a state_list/execute_task_lock per CPU, so we can do submissions from
    different CPUs without contention with each other.
    
    Note: tcm_fc was passing TARGET_SCF_USE_CPUID, but never set cpuid.  The
    assumption is that it wanted to set the cpuid to the CPU it was submitting
    from so it will get this behavior with this patch.
    
    [mkp: s/printk/pr_err/ + resolve COMPARE AND WRITE patch conflict]
    
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Himanshu Madhani <[email protected]>
    Signed-off-by: Mike Christie <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: 673db054d7a2 ("scsi: target: Fix multiple LUN_RESET handling")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: Rename cmd.bad_sector to cmd.sense_info [+ + +]
Author: David Disseldorp <[email protected]>
Date:   Sun Nov 1 00:32:09 2020 +0100

    scsi: target: Rename cmd.bad_sector to cmd.sense_info
    
    [ Upstream commit 8dd992fb67f33a0777fb4bee1e22a5ee5530f024 ]
    
    cmd.bad_sector currently gets packed into the sense INFORMATION field for
    TCM_LOGICAL_BLOCK_{GUARD,APP_TAG,REF_TAG}_CHECK_FAILED errors, which carry
    an .add_sector_info flag in the sense_detail_table to ensure this.
    
    In preparation for propagating a byte offset on COMPARE AND WRITE
    TCM_MISCOMPARE_VERIFY error, rename cmd.bad_sector to cmd.sense_info and
    sense_detail.add_sector_info to sense_detail.add_sense_info so that it
    better reflects the sense INFORMATION field destination.
    
    [ddiss: update previously overlooked ib_isert]
    
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Mike Christie <[email protected]>
    Signed-off-by: David Disseldorp <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: 673db054d7a2 ("scsi: target: Fix multiple LUN_RESET handling")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: Rename struct sense_info to sense_detail [+ + +]
Author: David Disseldorp <[email protected]>
Date:   Sun Nov 1 00:32:08 2020 +0100

    scsi: target: Rename struct sense_info to sense_detail
    
    [ Upstream commit b455233dcc403e3eb955a642dd69b6676e12b245 ]
    
    This helps distinguish it from the SCSI sense INFORMATION field.
    
    Link: https://lore.kernel.org/r/2[email protected]
    Reviewed-by: Mike Christie <[email protected]>
    Signed-off-by: David Disseldorp <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: 673db054d7a2 ("scsi: target: Fix multiple LUN_RESET handling")
    Signed-off-by: Sasha Levin <[email protected]>

 
seccomp: Move copy_seccomp() to no failure path. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Aug 23 08:45:32 2022 -0700

    seccomp: Move copy_seccomp() to no failure path.
    
    commit a1140cb215fa13dcec06d12ba0c3ee105633b7c4 upstream.
    
    Our syzbot instance reported memory leaks in do_seccomp() [0], similar
    to the report [1].  It shows that we miss freeing struct seccomp_filter
    and some objects included in it.
    
    We can reproduce the issue with the program below [2] which calls one
    seccomp() and two clone() syscalls.
    
    The first clone()d child exits earlier than its parent and sends a
    signal to kill it during the second clone(), more precisely before the
    fatal_signal_pending() test in copy_process().  When the parent receives
    the signal, it has to destroy the embryonic process and return -EINTR to
    user space.  In the failure path, we have to call seccomp_filter_release()
    to decrement the filter's refcount.
    
    Initially, we called it in free_task() called from the failure path, but
    the commit 3a15fb6ed92c ("seccomp: release filter after task is fully
    dead") moved it to release_task() to notify user space as early as possible
    that the filter is no longer used.
    
    To keep the change and current seccomp refcount semantics, let's move
    copy_seccomp() just after the signal check and add a WARN_ON_ONCE() in
    free_task() for future debugging.
    
    [0]:
    unreferenced object 0xffff8880063add00 (size 256):
      comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.914s)
      hex dump (first 32 bytes):
        01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
        ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
      backtrace:
        do_seccomp (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/seccomp.c:666 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)
        do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
        entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    unreferenced object 0xffffc90000035000 (size 4096):
      comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        __vmalloc_node_range (mm/vmalloc.c:3226)
        __vmalloc_node (mm/vmalloc.c:3261 (discriminator 4))
        bpf_prog_alloc_no_stats (kernel/bpf/core.c:91)
        bpf_prog_alloc (kernel/bpf/core.c:129)
        bpf_prog_create_from_user (net/core/filter.c:1414)
        do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)
        do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
        entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    unreferenced object 0xffff888003fa1000 (size 1024):
      comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        bpf_prog_alloc_no_stats (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/bpf/core.c:95)
        bpf_prog_alloc (kernel/bpf/core.c:129)
        bpf_prog_create_from_user (net/core/filter.c:1414)
        do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)
        do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
        entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    unreferenced object 0xffff888006360240 (size 16):
      comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)
      hex dump (first 16 bytes):
        01 00 37 00 76 65 72 6c e0 83 01 06 80 88 ff ff  ..7.verl........
      backtrace:
        bpf_prog_store_orig_filter (net/core/filter.c:1137)
        bpf_prog_create_from_user (net/core/filter.c:1428)
        do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)
        do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
        entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    unreferenced object 0xffff8880060183e0 (size 8):
      comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)
      hex dump (first 8 bytes):
        06 00 00 00 00 00 ff 7f                          ........
      backtrace:
        kmemdup (mm/util.c:129)
        bpf_prog_store_orig_filter (net/core/filter.c:1144)
        bpf_prog_create_from_user (net/core/filter.c:1428)
        do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)
        do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
        entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    
    [1]: https://syzkaller.appspot.com/bug?id=2809bb0ac77ad9aa3f4afe42d6a610aba594a987
    
    [2]:
    #define _GNU_SOURCE
    #include <sched.h>
    #include <signal.h>
    #include <unistd.h>
    #include <sys/syscall.h>
    #include <linux/filter.h>
    #include <linux/seccomp.h>
    
    void main(void)
    {
            struct sock_filter filter[] = {
                    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
            };
            struct sock_fprog fprog = {
                    .len = sizeof(filter) / sizeof(filter[0]),
                    .filter = filter,
            };
            long i, pid;
    
            syscall(__NR_seccomp, SECCOMP_SET_MODE_FILTER, 0, &fprog);
    
            for (i = 0; i < 2; i++) {
                    pid = syscall(__NR_clone, CLONE_NEWNET | SIGKILL, NULL, NULL, 0);
                    if (pid == 0)
                            return;
            }
    }
    
    Fixes: 3a15fb6ed92c ("seccomp: release filter after task is fully dead")
    Reported-by: [email protected]
    Reported-by: Ayushman Dutta <[email protected]>
    Suggested-by: Kees Cook <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Christian Brauner (Microsoft) <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
selftests/bpf: Wait for receive in cg_storage_multi test [+ + +]
Author: YiFei Zhu <[email protected]>
Date:   Wed Apr 5 19:33:54 2023 +0000

    selftests/bpf: Wait for receive in cg_storage_multi test
    
    [ Upstream commit 5af607a861d43ffff830fc1890033e579ec44799 ]
    
    In some cases the loopback latency might be large enough, causing
    the assertion on invocations to be run before ingress prog getting
    executed. The assertion would fail and the test would flake.
    
    This can be reliably reproduced by arbitrarily increasing the
    loopback latency (thanks to [1]):
      tc qdisc add dev lo root handle 1: htb default 12
      tc class add dev lo parent 1:1 classid 1:12 htb rate 20kbps ceil 20kbps
      tc qdisc add dev lo parent 1:12 netem delay 100ms
    
    Fix this by waiting on the receive end, instead of instantly
    returning to the assert. The call to read() will wait for the
    default SO_RCVTIMEO timeout of 3 seconds provided by
    start_server().
    
    [1] https://gist.github.com/kstevens715/4598301
    
    Reported-by: Martin KaFai Lau <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]/
    Fixes: 3573f384014f ("selftests/bpf: Test CGROUP_STORAGE behavior on shared egress + ingress")
    Acked-by: Stanislav Fomichev <[email protected]>
    Signed-off-by: YiFei Zhu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/resctrl: Check for return value after write_schemata() [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Wed Feb 15 15:06:00 2023 +0200

    selftests/resctrl: Check for return value after write_schemata()
    
    [ Upstream commit 0d45c83b95da414e98ad333e723141a94f6e2c64 ]
    
    MBA test case writes schemata but it does not check if the write is
    successful or not.
    
    Add the error check and return error properly.
    
    Fixes: 01fee6b4d1f9 ("selftests/resctrl: Add MBA test")
    Co-developed-by: Fenghua Yu <[email protected]>
    Signed-off-by: Fenghua Yu <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Reinette Chatre <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/resctrl: Return NULL if malloc_and_init_memory() did not alloc mem [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Wed Feb 15 15:05:57 2023 +0200

    selftests/resctrl: Return NULL if malloc_and_init_memory() did not alloc mem
    
    [ Upstream commit 22a8be280383812235131dda18a8212a59fadd2d ]
    
    malloc_and_init_memory() in fill_buf isn't checking if memalign()
    successfully allocated memory or not before accessing the memory.
    
    Check the return value of memalign() and return NULL if allocating
    aligned memory fails.
    
    Fixes: a2561b12fe39 ("selftests/resctrl: Add built in benchmark")
    Co-developed-by: Fenghua Yu <[email protected]>
    Signed-off-by: Fenghua Yu <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Reinette Chatre <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selinux: ensure av_permissions.h is built when needed [+ + +]
Author: Paul Moore <[email protected]>
Date:   Wed Apr 12 13:29:11 2023 -0400

    selinux: ensure av_permissions.h is built when needed
    
    [ Upstream commit 4ce1f694eb5d8ca607fed8542d32a33b4f1217a5 ]
    
    The Makefile rule responsible for building flask.h and
    av_permissions.h only lists flask.h as a target which means that
    av_permissions.h is only generated when flask.h needs to be
    generated.  This patch fixes this by adding av_permissions.h as a
    target to the rule.
    
    Fixes: 8753f6bec352 ("selinux: generate flask headers during kernel build")
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selinux: fix Makefile dependencies of flask.h [+ + +]
Author: Ondrej Mosnacek <[email protected]>
Date:   Wed Apr 12 15:59:19 2023 +0200

    selinux: fix Makefile dependencies of flask.h
    
    [ Upstream commit bcab1adeaad4b39a1e04cb98979a367d08253f03 ]
    
    Make the flask.h target depend on the genheaders binary instead of
    classmap.h to ensure that it is rebuilt if any of the dependencies of
    genheaders are changed.
    
    Notably this fixes flask.h not being rebuilt when
    initial_sid_to_string.h is modified.
    
    Fixes: 8753f6bec352 ("selinux: generate flask headers during kernel build")
    Signed-off-by: Ondrej Mosnacek <[email protected]>
    Acked-by: Stephen Smalley <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250: Add missing wakeup event reporting [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Fri Apr 14 10:02:39 2023 -0700

    serial: 8250: Add missing wakeup event reporting
    
    [ Upstream commit 0ba9e3a13c6adfa99e32b2576d20820ab10ad48a ]
    
    An 8250 UART configured as a wake-up source would not have reported
    itself through sysfs as being the source of wake-up, correct that.
    
    Fixes: b3b708fa2780 ("wake up from a serial port")
    Signed-off-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: 8250: Fix serial8250_tx_empty() race with DMA Tx [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Fri Mar 17 13:33:18 2023 +0200

    serial: 8250: Fix serial8250_tx_empty() race with DMA Tx
    
    commit 146a37e05d620cef4ad430e5d1c9c077fe6fa76f upstream.
    
    There's a potential race before THRE/TEMT deasserts when DMA Tx is
    starting up (or the next batch of continuous Tx is being submitted).
    This can lead to misdetecting Tx empty condition.
    
    It is entirely normal for THRE/TEMT to be set for some time after the
    DMA Tx had been setup in serial8250_tx_dma(). As Tx side is definitely
    not empty at that point, it seems incorrect for serial8250_tx_empty()
    claim Tx is empty.
    
    Fix the race by also checking in serial8250_tx_empty() whether there's
    DMA Tx active.
    
    Note: This fix only addresses in-kernel race mainly to make using
    TCSADRAIN/FLUSH robust. Userspace can still cause other races but they
    seem userspace concurrency control problems.
    
    Fixes: 9ee4b83e51f74 ("serial: 8250: Add support for dmaengine")
    Cc: [email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sfc: Fix module EEPROM reporting for QSFP modules [+ + +]
Author: Andy Moreton <[email protected]>
Date:   Fri Apr 28 12:33:33 2023 +0100

    sfc: Fix module EEPROM reporting for QSFP modules
    
    [ Upstream commit 281900a923d4c50df109b52a22ae3cdac150159b ]
    
    The sfc driver does not report QSFP module EEPROM contents correctly
    as only the first page is fetched from hardware.
    
    Commit 0e1a2a3e6e7d ("ethtool: Add SFF-8436 and SFF-8636 max EEPROM
    length definitions") added ETH_MODULE_SFF_8436_MAX_LEN for the overall
    size of the EEPROM info, so use that to report the full EEPROM contents.
    
    Fixes: 9b17010da57a ("sfc: Add ethtool -m support for QSFP modules")
    Signed-off-by: Andy Moreton <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sh: init: use OF_EARLY_FLATTREE for early init [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sun Mar 5 20:00:33 2023 -0800

    sh: init: use OF_EARLY_FLATTREE for early init
    
    commit 6cba655543c7959f8a6d2979b9d40a6a66b7ed4f upstream.
    
    When CONFIG_OF_EARLY_FLATTREE and CONFIG_SH_DEVICE_TREE are not set,
    SH3 build fails with a call to early_init_dt_scan(), so in
    arch/sh/kernel/setup.c and arch/sh/kernel/head_32.S, use
    CONFIG_OF_EARLY_FLATTREE instead of CONFIG_OF_FLATTREE.
    
    Fixes this build error:
    ../arch/sh/kernel/setup.c: In function 'sh_fdt_init':
    ../arch/sh/kernel/setup.c:262:26: error: implicit declaration of function 'early_init_dt_scan' [-Werror=implicit-function-declaration]
      262 |         if (!dt_virt || !early_init_dt_scan(dt_virt)) {
    
    Fixes: 03767daa1387 ("sh: fix build regression with CONFIG_OF && !CONFIG_OF_FLATTREE")
    Fixes: eb6b6930a70f ("sh: fix memory corruption of unflattened device tree")
    Signed-off-by: Randy Dunlap <[email protected]>
    Suggested-by: Rob Herring <[email protected]>
    Cc: Frank Rowand <[email protected]>
    Cc: [email protected]
    Cc: Rich Felker <[email protected]>
    Cc: Yoshinori Sato <[email protected]>
    Cc: Geert Uytterhoeven <[email protected]>
    Cc: John Paul Adrian Glaubitz <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

sh: math-emu: fix macro redefined warning [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sun Mar 5 20:00:34 2023 -0800

    sh: math-emu: fix macro redefined warning
    
    commit 58a49ad90939386a8682e842c474a0d2c00ec39c upstream.
    
    Fix a warning that was reported by the kernel test robot:
    
    In file included from ../include/math-emu/soft-fp.h:27,
                     from ../arch/sh/math-emu/math.c:22:
    ../arch/sh/include/asm/sfp-machine.h:17: warning: "__BYTE_ORDER" redefined
       17 | #define __BYTE_ORDER __BIG_ENDIAN
    In file included from ../arch/sh/math-emu/math.c:21:
    ../arch/sh/math-emu/sfp-util.h:71: note: this is the location of the previous definition
       71 | #define __BYTE_ORDER __LITTLE_ENDIAN
    
    Fixes: b929926f01f2 ("sh: define __BIG_ENDIAN for math-emu")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Link: lore.kernel.org/r/[email protected]
    Cc: John Paul Adrian Glaubitz <[email protected]>
    Cc: Yoshinori Sato <[email protected]>
    Cc: Rich Felker <[email protected]>
    Cc: [email protected]
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Cc: [email protected]
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

sh: mcount.S: fix build error when PRINTK is not enabled [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sun Mar 5 20:00:37 2023 -0800

    sh: mcount.S: fix build error when PRINTK is not enabled
    
    commit c2bd1e18c6f85c0027da2e5e7753b9bfd9f8e6dc upstream.
    
    Fix a build error in mcount.S when CONFIG_PRINTK is not enabled.
    Fixes this build error:
    
    sh2-linux-ld: arch/sh/lib/mcount.o: in function `stack_panic':
    (.text+0xec): undefined reference to `dump_stack'
    
    Fixes: e460ab27b6c3 ("sh: Fix up stack overflow check with ftrace disabled.")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: John Paul Adrian Glaubitz <[email protected]>
    Cc: Yoshinori Sato <[email protected]>
    Cc: Rich Felker <[email protected]>
    Suggested-by: Geert Uytterhoeven <[email protected]>
    Cc: [email protected]
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

sh: nmi_debug: fix return value of __setup handler [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sun Mar 5 20:00:32 2023 -0800

    sh: nmi_debug: fix return value of __setup handler
    
    commit d1155e4132de712a9d3066e2667ceaad39a539c5 upstream.
    
    __setup() handlers should return 1 to obsolete_checksetup() in
    init/main.c to indicate that the boot option has been handled.
    A return of 0 causes the boot option/value to be listed as an Unknown
    kernel parameter and added to init's (limited) argument or environment
    strings. Also, error return codes don't mean anything to
    obsolete_checksetup() -- only non-zero (usually 1) or zero.
    So return 1 from nmi_debug_setup().
    
    Fixes: 1e1030dccb10 ("sh: nmi_debug support.")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: Igor Zhbanov <[email protected]>
    Link: lore.kernel.org/r/[email protected]
    Cc: John Paul Adrian Glaubitz <glaub[email protected]>
    Cc: Yoshinori Sato <[email protected]>
    Cc: Rich Felker <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

sh: sq: Fix incorrect element size for allocating bitmap buffer [+ + +]
Author: John Paul Adrian Glaubitz <[email protected]>
Date:   Wed Apr 19 13:48:52 2023 +0200

    sh: sq: Fix incorrect element size for allocating bitmap buffer
    
    [ Upstream commit 80f746e2bd0e1da3fdb49a53570e54a1a225faac ]
    
    The Store Queue code allocates a bitmap buffer with the size of
    multiple of sizeof(long) in sq_api_init(). While the buffer size
    is calculated correctly, the code uses the wrong element size to
    allocate the buffer which results in the allocated bitmap buffer
    being too small.
    
    Fix this by allocating the buffer with kcalloc() with element size
    sizeof(long) instead of kzalloc() whose elements size defaults to
    sizeof(char).
    
    Fixes: d7c30c682a27 ("sh: Store Queue API rework.")
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sit: update dev->needed_headroom in ipip6_tunnel_bind_dev() [+ + +]
Author: Cong Wang <[email protected]>
Date:   Wed Apr 26 23:00:06 2023 -0700

    sit: update dev->needed_headroom in ipip6_tunnel_bind_dev()
    
    [ Upstream commit c88f8d5cd95fd039cff95d682b8e71100c001df0 ]
    
    When a tunnel device is bound with the underlying device, its
    dev->needed_headroom needs to be updated properly. IPv4 tunnels
    already do the same in ip_tunnel_bind_dev(). Otherwise we may
    not have enough header room for skb, especially after commit
    b17f709a2401 ("gue: TX support for using remote checksum offload option").
    
    Fixes: 32b8a8e59c9c ("sit: add IPv4 over IPv4 support")
    Reported-by: Palash Oswal <[email protected]>
    Link: https://lore.kernel.org/netdev/CAGyP=7fDcSPKu6nttbGwt7RXzE3uyYxLjCSE97J64pRxJP8jPA@mail.gmail.com/
    Cc: Kuniyuki Iwashima <[email protected]>
    Cc: Eric Dumazet <[email protected]>
    Signed-off-by: Cong Wang <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: ti: pm33xx: Enable basic PM runtime support for genpd [+ + +]
Author: Tony Lindgren <[email protected]>
Date:   Mon Nov 16 12:57:13 2020 +0200

    soc: ti: pm33xx: Enable basic PM runtime support for genpd
    
    [ Upstream commit 74033131d2467fda6b76ba10bc80a75fb47e03d1 ]
    
    To prepare for moving to use genpd, let's enable basic PM
    runtime support.
    
    Cc: Dave Gerlach <[email protected]>
    Cc: Santosh Shilimkar <[email protected]>
    Cc: Suman Anna <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Stable-dep-of: 8f3c307b580a ("soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe")
    Signed-off-by: Sasha Levin <[email protected]>

soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Fri Jan 6 09:40:22 2023 +0400

    soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe
    
    [ Upstream commit 8f3c307b580a4a6425896007325bddefc36e8d91 ]
    
    wkup_m3_ipc_get() takes refcount, which should be freed by
    wkup_m3_ipc_put(). Add missing refcount release in the error paths.
    
    Fixes: 5a99ae0092fe ("soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sound/oss/dmasound: fix 'dmasound_setup' defined but not used [+ + +]
Author: Miles Chen <[email protected]>
Date:   Thu Apr 14 17:19:38 2022 +0800

    sound/oss/dmasound: fix 'dmasound_setup' defined but not used
    
    commit 357ad4d898286b94aaae0cb7e3f573459e5b98b9 upstream.
    
    We observed: 'dmasound_setup' defined but not used error with
    COMPILER=gcc ARCH=m68k DEFCONFIG=allmodconfig build.
    
    Fix it by adding __maybe_unused to dmasound_setup.
    
    Error(s):
    sound/oss/dmasound/dmasound_core.c:1431:12: error: 'dmasound_setup' defined but not used [-Werror=unused-function]
    
    Fixes: 9dd7c46346ca ("sound/oss/dmasound: fix build when drivers are mixed =y/=m")
    Signed-off-by: Miles Chen <[email protected]>
    Acked-by: Randy Dunlap <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

sound/oss/dmasound: fix build when drivers are mixed =y/=m [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Tue Apr 5 16:41:18 2022 -0700

    sound/oss/dmasound: fix build when drivers are mixed =y/=m
    
    commit 9dd7c46346ca4390f84a7ea9933005eb1b175c15 upstream.
    
    When CONFIG_DMASOUND_ATARI=m and CONFIG_DMASOUND_Q40=y (or vice versa),
    dmasound_core.o can be built without dmasound_deinit() being defined,
    causing a build error:
    
    ERROR: modpost: "dmasound_deinit" [sound/oss/dmasound/dmasound_atari.ko] undefined!
    
    Modify dmasound_core.c and dmasound.h so that dmasound_deinit() is
    always available.
    
    The mixed modes (=y/=m) also mean that several variables and structs
    have to be declared in all cases.
    
    Suggested-by: Arnd Bergmann <[email protected]>
    Suggested-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Link: lore.kernel.org/r/202204032138.EFT9q[email protected]
    Cc: Geert Uytterhoeven <[email protected]>
    Cc: Jaroslav Kysela <[email protected]>
    Cc: Takashi Iwai <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: cadence-quadspi: fix suspend-resume implementations [+ + +]
Author: Dhruva Gole <[email protected]>
Date:   Mon Apr 17 14:40:27 2023 +0530

    spi: cadence-quadspi: fix suspend-resume implementations
    
    [ Upstream commit 2087e85bb66ee3652dafe732bb9b9b896229eafc ]
    
    The cadence QSPI driver misbehaves after performing a full system suspend
    resume:
    ...
    spi-nor spi0.0: resume() failed
    ...
    This results in a flash connected via OSPI interface after system suspend-
    resume to be unusable.
    fix these suspend and resume functions.
    
    Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
    Signed-off-by: Dhruva Gole <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: fsl-spi: Fix CPM/QE mode Litte Endian [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Sat Apr 1 19:59:46 2023 +0200

    spi: fsl-spi: Fix CPM/QE mode Litte Endian
    
    [ Upstream commit c20c57d9868d7f9fd1b2904c7801b07e128f6322 ]
    
    CPM has the same problem as QE so for CPM also use the fix added
    by commit 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian"):
    
      CPM mode uses Little Endian so words > 8 bits are byte swapped.
      Workaround this by always enforcing wordsize 8 for 16 and 32 bits
      words. Unfortunately this will not work for LSB transfers
      where wordsize is > 8 bits so disable these for now.
    
    Also limit the workaround to 16 and 32 bits words because it can
    only work for multiples of 8-bits.
    
    Signed-off-by: Christophe Leroy <[email protected]>
    Cc: Joakim Tjernlund <[email protected]>
    Fixes: 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian")
    Link: https://lore.kernel.org/r/1b7d3e84b1128f42c1887dd2fb9cdf390f541bc1.1680371809.git.christophe.leroy@csgroup.eu
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: imx: Don't skip cleanup in remove's error path [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Mar 6 07:57:32 2023 +0100

    spi: imx: Don't skip cleanup in remove's error path
    
    [ Upstream commit 11951c9e3f364d7ae3b568a0e52c8335d43066b5 ]
    
    Returning early in a platform driver's remove callback is wrong. In this
    case the dma resources are not released in the error path. this is never
    retried later and so this is a permanent leak. To fix this, only skip
    hardware disabling if waking the device fails.
    
    Fixes: d593574aff0a ("spi: imx: do not access registers while clocks disabled")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: qup: Don't skip cleanup in remove's error path [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Thu Mar 30 23:03:40 2023 +0200

    spi: qup: Don't skip cleanup in remove's error path
    
    [ Upstream commit 61f49171a43ab1f80c73c5c88c508770c461e0f2 ]
    
    Returning early in a platform driver's remove callback is wrong. In this
    case the dma resources are not released in the error path. this is never
    retried later and so this is a permanent leak. To fix this, only skip
    hardware disabling if waking the device fails.
    
    Fixes: 64ff247a978f ("spi: Add Qualcomm QUP SPI controller support")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: spi-imx: using pm_runtime_resume_and_get instead of pm_runtime_get_sync [+ + +]
Author: Minghao Chi <[email protected]>
Date:   Thu Apr 14 08:53:42 2022 +0000

    spi: spi-imx: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
    
    [ Upstream commit 7d34ff58f35c82207698f43af79817a05e1342e5 ]
    
    Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
    pm_runtime_put_noidle. This change is just to simplify the code, no
    actual functional changes.
    
    Reported-by: Zeal Robot <[email protected]>
    Signed-off-by: Minghao Chi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 11951c9e3f36 ("spi: imx: Don't skip cleanup in remove's error path")
    Signed-off-by: Sasha Levin <[email protected]>

 
spmi: Add a check for remove callback when removing a SPMI driver [+ + +]
Author: Jishnu Prakash <[email protected]>
Date:   Thu Apr 13 15:38:34 2023 -0700

    spmi: Add a check for remove callback when removing a SPMI driver
    
    [ Upstream commit b56eef3e16d888883fefab47425036de80dd38fc ]
    
    When removing a SPMI driver, there can be a crash due to NULL pointer
    dereference if it does not have a remove callback defined. This is
    one such call trace observed when removing the QCOM SPMI PMIC driver:
    
     dump_backtrace.cfi_jt+0x0/0x8
     dump_stack_lvl+0xd8/0x16c
     panic+0x188/0x498
     __cfi_slowpath+0x0/0x214
     __cfi_slowpath+0x1dc/0x214
     spmi_drv_remove+0x16c/0x1e0
     device_release_driver_internal+0x468/0x79c
     driver_detach+0x11c/0x1a0
     bus_remove_driver+0xc4/0x124
     driver_unregister+0x58/0x84
     cleanup_module+0x1c/0xc24 [qcom_spmi_pmic]
     __do_sys_delete_module+0x3ec/0x53c
     __arm64_sys_delete_module+0x18/0x28
     el0_svc_common+0xdc/0x294
     el0_svc+0x38/0x9c
     el0_sync_handler+0x8c/0xf0
     el0_sync+0x1b4/0x1c0
    
    If a driver has all its resources allocated through devm_() APIs and
    does not need any other explicit cleanup, it would not require a
    remove callback to be defined. Hence, add a check for remove callback
    presence before calling it when removing a SPMI driver.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 6f00f8c8635f ("mfd: qcom-spmi-pmic: Use devm_of_platform_populate()")
    Fixes: 5a86bf343976 ("spmi: Linux driver framework for SPMI")
    Signed-off-by: Jishnu Prakash <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: iio: resolver: ads1210: fix config mode [+ + +]
Author: Nuno Sá <[email protected]>
Date:   Mon Mar 27 16:54:14 2023 +0200

    staging: iio: resolver: ads1210: fix config mode
    
    commit 16313403d873ff17a587818b61f84c8cb4971cef upstream.
    
    As stated in the device datasheet [1], bits a0 and a1 have to be set to
    1 for the configuration mode.
    
    [1]: https://www.analog.com/media/en/technical-documentation/data-sheets/ad2s1210.pdf
    
    Fixes: b19e9ad5e2cb9 ("staging:iio:resolver:ad2s1210 general driver cleanup")
    Cc: stable <[email protected]>
    Signed-off-by: Nuno Sá <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

staging: rtl8192e: Fix W_DISABLE# does not work after stop/start [+ + +]
Author: Philipp Hortmann <[email protected]>
Date:   Tue Apr 18 22:02:01 2023 +0200

    staging: rtl8192e: Fix W_DISABLE# does not work after stop/start
    
    [ Upstream commit 3fac2397f562eb669ddc2f45867a253f3fc26184 ]
    
    When loading the driver for rtl8192e, the W_DISABLE# switch is working as
    intended. But when the WLAN is turned off in software and then turned on
    again the W_DISABLE# does not work anymore. Reason for this is that in
    the function _rtl92e_dm_check_rf_ctrl_gpio() the bfirst_after_down is
    checked and returned when true. bfirst_after_down is set true when
    switching the WLAN off in software. But it is not set to false again
    when WLAN is turned on again.
    
    Add bfirst_after_down = false in _rtl92e_sta_up to reset bit and fix
    above described bug.
    
    Fixes: 94a799425eee ("From: wlanfae <[email protected]> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
    Signed-off-by: Philipp Hortmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
SUNRPC: remove the maximum number of retries in call_bind_status [+ + +]
Author: Dai Ngo <[email protected]>
Date:   Tue Apr 18 13:19:02 2023 -0700

    SUNRPC: remove the maximum number of retries in call_bind_status
    
    [ Upstream commit 691d0b782066a6eeeecbfceb7910a8f6184e6105 ]
    
    Currently call_bind_status places a hard limit of 3 to the number of
    retries on EACCES error. This limit was done to prevent NLM unlock
    requests from being hang forever when the server keeps returning garbage.
    However this change causes problem for cases when NLM service takes
    longer than 9 seconds to register with the port mapper after a restart.
    
    This patch removes this hard coded limit and let the RPC handles
    the retry based on the standard hard/soft task semantics.
    
    Fixes: 0b760113a3a1 ("NLM: Don't hang forever on NLM unlock requests")
    Reported-by: Helen Chao <[email protected]>
    Tested-by: Helen Chao <[email protected]>
    Signed-off-by: Dai Ngo <da[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Mon Apr 24 15:20:22 2023 -0700

    tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.
    
    [ Upstream commit 50749f2dd6854a41830996ad302aef2ffaf011d8 ]
    
    syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY
    skbs.  We can reproduce the problem with these sequences:
    
      sk = socket(AF_INET, SOCK_DGRAM, 0)
      sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE)
      sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1)
      sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53))
      sk.close()
    
    sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets
    skb->cb->ubuf.refcnt to 1, and calls sock_hold().  Here, struct
    ubuf_info_msgzc indirectly holds a refcnt of the socket.  When the
    skb is sent, __skb_tstamp_tx() clones it and puts the clone into
    the socket's error queue with the TX timestamp.
    
    When the original skb is received locally, skb_copy_ubufs() calls
    skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt.
    This additional count is decremented while freeing the skb, but struct
    ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is
    not called.
    
    The last refcnt is not released unless we retrieve the TX timestamped
    skb by recvmsg().  Since we clear the error queue in inet_sock_destruct()
    after the socket's refcnt reaches 0, there is a circular dependency.
    If we close() the socket holding such skbs, we never call sock_put()
    and leak the count, sk, and skb.
    
    TCP has the same problem, and commit e0c8bccd40fc ("net: stream:
    purge sk_error_queue in sk_stream_kill_queues()") tried to fix it
    by calling skb_queue_purge() during close().  However, there is a
    small chance that skb queued in a qdisc or device could be put
    into the error queue after the skb_queue_purge() call.
    
    In __skb_tstamp_tx(), the cloned skb should not have a reference
    to the ubuf to remove the circular dependency, but skb_clone() does
    not call skb_copy_ubufs() for zerocopy skb.  So, we need to call
    skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().
    
    [0]:
    BUG: memory leak
    unreferenced object 0xffff88800c6d2d00 (size 1152):
      comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00  ................
        02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024
        [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083
        [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline]
        [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245
        [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515
        [<00000000b9b11231>] sock_create net/socket.c:1566 [inline]
        [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline]
        [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline]
        [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636
        [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline]
        [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline]
        [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647
        [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
        [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
        [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    BUG: memory leak
    unreferenced object 0xffff888017633a00 (size 240):
      comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff  .........-m.....
      backtrace:
        [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497
        [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline]
        [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596
        [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline]
        [<00000000be626478>] msg_zerocopy_realloc+0x1ce/0x7f0 net/core/skbuff.c:1370
        [<00000000cbfc9870>] __ip_append_data+0x2adf/0x3b30 net/ipv4/ip_output.c:1037
        [<0000000089869146>] ip_make_skb+0x26c/0x2e0 net/ipv4/ip_output.c:1652
        [<00000000098015c2>] udp_sendmsg+0x1bac/0x2390 net/ipv4/udp.c:1253
        [<0000000045e0e95e>] inet_sendmsg+0x10a/0x150 net/ipv4/af_inet.c:819
        [<000000008d31bfde>] sock_sendmsg_nosec net/socket.c:714 [inline]
        [<000000008d31bfde>] sock_sendmsg+0x141/0x190 net/socket.c:734
        [<0000000021e21aa4>] __sys_sendto+0x243/0x360 net/socket.c:2117
        [<00000000ac0af00c>] __do_sys_sendto net/socket.c:2129 [inline]
        [<00000000ac0af00c>] __se_sys_sendto net/socket.c:2125 [inline]
        [<00000000ac0af00c>] __x64_sys_sendto+0xe1/0x1c0 net/socket.c:2125
        [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
        [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
        [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
    Fixes: b5947e5d1e71 ("udp: msg_zerocopy")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe [+ + +]
Author: Kang Chen <[email protected]>
Date:   Wed Apr 19 10:07:48 2023 +0800

    thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe
    
    [ Upstream commit f05c7b7d9ea9477fcc388476c6f4ade8c66d2d26 ]
    
    Smatch reports:
    1. mtk_thermal_probe() warn: 'apmixed_base' from of_iomap() not released.
    2. mtk_thermal_probe() warn: 'auxadc_base' from of_iomap() not released.
    
    The original code forgets to release iomap resource when handling errors,
    fix it by switch to devm_of_iomap.
    
    Fixes: 89945047b166 ("thermal: mediatek: Add tsensor support for V2 thermal system")
    Signed-off-by: Kang Chen <[email protected]>
    Reviewed-by: Dongliang Mu <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/20230[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tick/common: Align tick period with the HZ tick. [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Tue Apr 18 14:26:39 2023 +0200

    tick/common: Align tick period with the HZ tick.
    
    [ Upstream commit e9523a0d81899361214d118ad60ef76f0e92f71d ]
    
    With HIGHRES enabled tick_sched_timer() is programmed every jiffy to
    expire the timer_list timers. This timer is programmed accurate in
    respect to CLOCK_MONOTONIC so that 0 seconds and nanoseconds is the
    first tick and the next one is 1000/CONFIG_HZ ms later. For HZ=250 it is
    every 4 ms and so based on the current time the next tick can be
    computed.
    
    This accuracy broke since the commit mentioned below because the jiffy
    based clocksource is initialized with higher accuracy in
    read_persistent_wall_and_boot_offset(). This higher accuracy is
    inherited during the setup in tick_setup_device(). The timer still fires
    every 4ms with HZ=250 but timer is no longer aligned with
    CLOCK_MONOTONIC with 0 as it origin but has an offset in the us/ns part
    of the timestamp. The offset differs with every boot and makes it
    impossible for user land to align with the tick.
    
    Align the tick period with CLOCK_MONOTONIC ensuring that it is always a
    multiple of 1000/CONFIG_HZ ms.
    
    Fixes: 857baa87b6422 ("sched/clock: Enable sched clock early")
    Reported-by: Gusenleitner Klaus <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tick/nohz: Fix cpu_is_hotpluggable() by checking with nohz subsystem [+ + +]
Author: Joel Fernandes (Google) <[email protected]>
Date:   Tue Jan 24 17:31:26 2023 +0000

    tick/nohz: Fix cpu_is_hotpluggable() by checking with nohz subsystem
    
    commit 58d7668242647e661a20efe065519abd6454287e upstream.
    
    For CONFIG_NO_HZ_FULL systems, the tick_do_timer_cpu cannot be offlined.
    However, cpu_is_hotpluggable() still returns true for those CPUs. This causes
    torture tests that do offlining to end up trying to offline this CPU causing
    test failures. Such failure happens on all architectures.
    
    Fix the repeated error messages thrown by this (even if the hotplug errors are
    harmless) by asking the opinion of the nohz subsystem on whether the CPU can be
    hotplugged.
    
    [ Apply Frederic Weisbecker feedback on refactoring tick_nohz_cpu_down(). ]
    
    For drivers/base/ portion:
    Acked-by: Greg Kroah-Hartman <[email protected]>
    Acked-by: Frederic Weisbecker <[email protected]>
    Cc: Frederic Weisbecker <[email protected]>
    Cc: "Paul E. McKenney" <[email protected]>
    Cc: Zhouyi Zhou <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: Marc Zyngier <[email protected]>
    Cc: rcu <[email protected]>
    Cc: [email protected]
    Fixes: 2987557f52b9 ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Joel Fernandes (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tick/sched: Optimize tick_do_update_jiffies64() further [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Tue Nov 17 14:19:47 2020 +0100

    tick/sched: Optimize tick_do_update_jiffies64() further
    
    [ Upstream commit 7a35bf2a6a871cd0252cd371d741e7d070b53af9 ]
    
    Now that it's clear that there is always one tick to account, simplify the
    calculations some more.
    
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: e9523a0d8189 ("tick/common: Align tick period with the HZ tick.")
    Signed-off-by: Sasha Levin <[email protected]>

tick/sched: Reduce seqcount held scope in tick_do_update_jiffies64() [+ + +]
Author: Yunfeng Ye <[email protected]>
Date:   Tue Nov 17 14:19:46 2020 +0100

    tick/sched: Reduce seqcount held scope in tick_do_update_jiffies64()
    
    [ Upstream commit 94ad2e3cedb82af034f6d97c58022f162b669f9b ]
    
    If jiffies are up to date already (caller lost the race against another
    CPU) there is no point to change the sequence count. Doing that just forces
    other CPUs into the seqcount retry loop in tick_nohz_next_event() for
    nothing.
    
    Just bail out early.
    
    [ tglx: Rewrote most of it ]
    
    Signed-off-by: Yunfeng Ye <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: e9523a0d8189 ("tick/common: Align tick period with the HZ tick.")
    Signed-off-by: Sasha Levin <[email protected]>

tick/sched: Use tick_next_period for lockless quick check [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Tue Nov 17 14:19:45 2020 +0100

    tick/sched: Use tick_next_period for lockless quick check
    
    [ Upstream commit 372acbbaa80940189593f9d69c7c069955f24f7a ]
    
    No point in doing calculations.
    
       tick_next_period = last_jiffies_update + tick_period
    
    Just check whether now is before tick_next_period to figure out whether
    jiffies need an update.
    
    Add a comment why the intentional data race in the quick check is safe or
    not so safe in a 32bit corner case and why we don't worry about it.
    
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: e9523a0d8189 ("tick/common: Align tick period with the HZ tick.")
    Signed-off-by: Sasha Levin <[email protected]>

 
tick: Get rid of tick_period [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Tue Nov 17 14:19:49 2020 +0100

    tick: Get rid of tick_period
    
    [ Upstream commit b996544916429946bf4934c1c01a306d1690972c ]
    
    The variable tick_period is initialized to NSEC_PER_TICK / HZ during boot
    and never updated again.
    
    If NSEC_PER_TICK is not an integer multiple of HZ this computation is less
    accurate than TICK_NSEC which has proper rounding in place.
    
    Aside of the inaccuracy there is no reason for having this variable at
    all. It's just a pointless indirection and all usage sites can just use the
    TICK_NSEC constant.
    
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: e9523a0d8189 ("tick/common: Align tick period with the HZ tick.")
    Signed-off-by: Sasha Levin <[email protected]>

 
tools: bpftool: Remove invalid \' json escape [+ + +]
Author: Luis Gerhorst <[email protected]>
Date:   Mon Feb 27 16:08:54 2023 +0100

    tools: bpftool: Remove invalid \' json escape
    
    [ Upstream commit c679bbd611c08b0559ffae079330bc4e5574696a ]
    
    RFC8259 ("The JavaScript Object Notation (JSON) Data Interchange
    Format") only specifies \", \\, \/, \b, \f, \n, \r, and \r as valid
    two-character escape sequences. This does not include \', which is not
    required in JSON because it exclusively uses double quotes as string
    separators.
    
    Solidus (/) may be escaped, but does not have to. Only reverse
    solidus (\), double quotes ("), and the control characters have to be
    escaped. Therefore, with this fix, bpftool correctly supports all valid
    two-character escape sequences (but still does not support characters
    that require multi-character escape sequences).
    
    Witout this fix, attempting to load a JSON file generated by bpftool
    using Python 3.10.6's default json.load() may fail with the error
    "Invalid \escape" if the file contains the invalid escaped single
    quote (\').
    
    Fixes: b66e907cfee2 ("tools: bpftool: copy JSON writer from iproute2 repository")
    Signed-off-by: Luis Gerhorst <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Reviewed-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tpm, tpm: Implement usage counter for locality [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Thu Nov 24 14:55:33 2022 +0100

    tpm, tpm: Implement usage counter for locality
    
    [ Upstream commit 7a2f55d0be296c4e81fd782f3d6c43ed4ec7e265 ]
    
    Implement a usage counter for the (default) locality used by the TPM TIS
    driver:
    Request the locality from the TPM if it has not been claimed yet, otherwise
    only increment the counter. Also release the locality if the counter is 0
    otherwise only decrement the counter. Since in case of SPI the register
    accesses are locked by means of the SPI bus mutex use a sleepable lock
    (i.e. also a mutex) to ensure thread-safety of the counter which may be
    accessed by both a userspace thread and the interrupt handler.
    
    By doing this refactor the names of the amended functions to use a more
    appropriate prefix.
    
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Tested-by: Michael Niewöhner <[email protected]>
    Tested-by: Jarkko Sakkinen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Stable-dep-of: 955df4f87760 ("tpm, tpm_tis: Claim locality when interrupts are reenabled on resume")
    Signed-off-by: Sasha Levin <[email protected]>

 
tpm, tpm_tis: Claim locality before writing interrupt registers [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Thu Nov 24 14:55:29 2022 +0100

    tpm, tpm_tis: Claim locality before writing interrupt registers
    
    [ Upstream commit 15d7aa4e46eba87242a320f39773aa16faddadee ]
    
    In tpm_tis_probe_single_irq() interrupt registers TPM_INT_VECTOR,
    TPM_INT_STATUS and TPM_INT_ENABLE are modified to setup the interrupts.
    Currently these modifications are done without holding a locality thus they
    have no effect. Fix this by claiming the (default) locality before the
    registers are written.
    
    Since now tpm_tis_gen_interrupt() is called with the locality already
    claimed remove locality request and release from this function.
    
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Tested-by: Jarkko Sakkinen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Stable-dep-of: 955df4f87760 ("tpm, tpm_tis: Claim locality when interrupts are reenabled on resume")
    Signed-off-by: Sasha Levin <[email protected]>

tpm, tpm_tis: Claim locality before writing TPM_INT_ENABLE register [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Thu Nov 24 14:55:26 2022 +0100

    tpm, tpm_tis: Claim locality before writing TPM_INT_ENABLE register
    
    [ Upstream commit 282657a8bd7fddcf511b834f43705001668b33a7 ]
    
    In disable_interrupts() the TPM_GLOBAL_INT_ENABLE bit is unset in the
    TPM_INT_ENABLE register to shut the interrupts off. However modifying the
    register is only possible with a held locality. So claim the locality
    before disable_interrupts() is called.
    
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Tested-by: Michael Niewöhner <[email protected]>
    Tested-by: Jarkko Sakkinen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Stable-dep-of: 955df4f87760 ("tpm, tpm_tis: Claim locality when interrupts are reenabled on resume")
    Signed-off-by: Sasha Levin <[email protected]>

tpm, tpm_tis: Claim locality when interrupts are reenabled on resume [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Thu Nov 24 14:55:36 2022 +0100

    tpm, tpm_tis: Claim locality when interrupts are reenabled on resume
    
    [ Upstream commit 955df4f87760b3bb2af253d3fbb12fb712b3ffa6 ]
    
    In tpm_tis_resume() make sure that the locality has been claimed when
    tpm_tis_reenable_interrupts() is called. Otherwise the writings to the
    register might not have any effect.
    
    Fixes: 45baa1d1fa39 ("tpm_tis: Re-enable interrupts upon (S3) resume")
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Tested-by: Jarkko Sakkinen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tpm, tpm_tis: Disable interrupts if tpm_tis_probe_irq() failed [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Thu Nov 24 14:55:27 2022 +0100

    tpm, tpm_tis: Disable interrupts if tpm_tis_probe_irq() failed
    
    [ Upstream commit 6d789ad726950e612a7f31044260337237c5b490 ]
    
    Both functions tpm_tis_probe_irq_single() and tpm_tis_probe_irq() may setup
    the interrupts and then return with an error. This case is indicated by a
    missing TPM_CHIP_FLAG_IRQ flag in chip->flags.
    Currently the interrupt setup is only undone if tpm_tis_probe_irq_single()
    fails. Undo the setup also if tpm_tis_probe_irq() fails.
    
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Tested-by: Michael Niewöhner <[email protected]>
    Tested-by: Jarkko Sakkinen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Stable-dep-of: 955df4f87760 ("tpm, tpm_tis: Claim locality when interrupts are reenabled on resume")
    Signed-off-by: Sasha Levin <[email protected]>

tpm, tpm_tis: Do not skip reset of original interrupt vector [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Thu Nov 24 14:55:28 2022 +0100

    tpm, tpm_tis: Do not skip reset of original interrupt vector
    
    [ Upstream commit ed9be0e6c892a783800d77a41ca4c7255c6af8c5 ]
    
    If in tpm_tis_probe_irq_single() an error occurs after the original
    interrupt vector has been read, restore the interrupts before the error is
    returned.
    
    Since the caller does not check the error value, return -1 in any case that
    the TPM_CHIP_FLAG_IRQ flag is not set. Since the return value of function
    tpm_tis_gen_interrupt() is not longer used, make it a void function.
    
    Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM access")
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Tested-by: Jarkko Sakkinen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: audit: move some local functions out of tty.h [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Apr 8 14:51:29 2021 +0200

    tty: audit: move some local functions out of tty.h
    
    [ Upstream commit da5d669e00d2c437b3f508d60add417fc74f4bb6 ]
    
    The functions tty_audit_add_data() and tty_audit_tiocsti() are local to
    the tty core code, and do not need to be in a "kernel-wide" header file
    so move them to drivers/tty/tty.h
    
    Cc: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <gr[email protected]>
    Stable-dep-of: 094fb49a2d0d ("tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH")
    Signed-off-by: Sasha Levin <[email protected]>

tty: clean include/linux/tty.h up [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Apr 8 14:51:34 2021 +0200

    tty: clean include/linux/tty.h up
    
    [ Upstream commit 5ffa6e344a1c92a27c242f500fc74e6eb361a4bc ]
    
    There are a lot of tty-core-only functions that are listed in
    include/linux/tty.h.  Move them to drivers/tty/tty.h so that no one else
    can accidentally call them or think that they are public functions.
    
    Cc: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 094fb49a2d0d ("tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH")
    Signed-off-by: Sasha Levin <[email protected]>

tty: create internal tty.h file [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Apr 8 14:51:22 2021 +0200

    tty: create internal tty.h file
    
    [ Upstream commit 98602c010ceba82f2c2384122dbd07bc965fd367 ]
    
    There are a number of functions and #defines in include/linux/tty.h that
    do not belong there as they are private to the tty core code.
    
    Create an initial drivers/tty/tty.h file and copy the odd "tty logging"
    macros into it to seed the file with some initial things that we know
    nothing outside of the tty core should be calling.
    
    Cc: Tetsuo Handa <[email protected]>
    Cc: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 094fb49a2d0d ("tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH")
    Signed-off-by: Sasha Levin <[email protected]>

tty: move some internal tty lock enums and functions out of tty.h [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Apr 8 14:51:30 2021 +0200

    tty: move some internal tty lock enums and functions out of tty.h
    
    [ Upstream commit 6c80c0b94b94192d9a34b400f8237703c6475f4d ]
    
    Move the TTY_LOCK_* enums and tty_ldisc lock functions out of the global
    tty.h into the local header file to clean things up.
    
    Cc: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 094fb49a2d0d ("tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH")
    Signed-off-by: Sasha Levin <[email protected]>

tty: move some tty-only functions to drivers/tty/tty.h [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Apr 8 14:51:32 2021 +0200

    tty: move some tty-only functions to drivers/tty/tty.h
    
    [ Upstream commit 9f72cab1596327e1011ab4599c07b165e0fb45db ]
    
    The flow change and restricted_tty_write() logic is internal to the tty
    core only, so move it out of the include/linux/tty.h file.
    
    Cc: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 094fb49a2d0d ("tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH")
    Signed-off-by: Sasha Levin <[email protected]>

tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Fri Mar 17 13:33:17 2023 +0200

    tty: Prevent writing chars during tcsetattr TCSADRAIN/FLUSH
    
    [ Upstream commit 094fb49a2d0d6827c86d2e0840873e6db0c491d2 ]
    
    If userspace races tcsetattr() with a write, the drained condition
    might not be guaranteed by the kernel. There is a race window after
    checking Tx is empty before tty_set_termios() takes termios_rwsem for
    write. During that race window, more characters can be queued by a
    racing writer.
    
    Any ongoing transmission might produce garbage during HW's
    ->set_termios() call. The intent of TCSADRAIN/FLUSH seems to be
    preventing such a character corruption. If those flags are set, take
    tty's write lock to stop any writer before performing the lower layer
    Tx empty check and wait for the pending characters to be sent (if any).
    
    The initial wait for all-writers-done must be placed outside of tty's
    write lock to avoid deadlock which makes it impossible to use
    tty_wait_until_sent(). The write lock is retried if a racing write is
    detected.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: [email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tty: serial: fsl_lpuart: adjust buffer length to the intended size [+ + +]
Author: Shenwei Wang <[email protected]>
Date:   Mon Apr 10 14:55:55 2023 -0500

    tty: serial: fsl_lpuart: adjust buffer length to the intended size
    
    [ Upstream commit f73fd750552524b06b5d77ebfdd106ccc8fcac61 ]
    
    Based on the fls function definition provided below, we should not
    subtract 1 to obtain the correct buffer length:
    
    fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
    
    Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx")
    Signed-off-by: Shenwei Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
uapi/linux/const.h: prefer ISO-friendly __typeof__ [+ + +]
Author: Kevin Brodsky <[email protected]>
Date:   Tue Apr 11 10:27:47 2023 +0100

    uapi/linux/const.h: prefer ISO-friendly __typeof__
    
    [ Upstream commit 31088f6f7906253ef4577f6a9b84e2d42447dba0 ]
    
    typeof is (still) a GNU extension, which means that it cannot be used when
    building ISO C (e.g.  -std=c99).  It should therefore be avoided in uapi
    headers in favour of the ISO-friendly __typeof__.
    
    Unfortunately this issue could not be detected by
    CONFIG_UAPI_HEADER_TEST=y as the __ALIGN_KERNEL() macro is not expanded in
    any uapi header.
    
    This matters from a userspace perspective, not a kernel one. uapi
    headers and their contents are expected to be usable in a variety of
    situations, and in particular when building ISO C applications (with
    -std=c99 or similar).
    
    This particular problem can be reproduced by trying to use the
    __ALIGN_KERNEL macro directly in application code, say:
    
    #include <linux/const.h>
    
    int align(int x, int a)
    {
            return __KERNEL_ALIGN(x, a);
    }
    
    and trying to build that with -std=c99.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: a79ff731a1b2 ("netfilter: xtables: make XT_ALIGN() usable in exported headers by exporting __ALIGN_KERNEL()")
    Signed-off-by: Kevin Brodsky <[email protected]>
    Reported-by: Ruben Ayrapetyan <[email protected]>
    Tested-by: Ruben Ayrapetyan <[email protected]>
    Reviewed-by: Petr Vorel <[email protected]>
    Tested-by: Petr Vorel <[email protected]>
    Reviewed-by: Masahiro Yamada <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ubi: Fix return value overwrite issue in try_write_vid_and_data() [+ + +]
Author: Wang YanQing <[email protected]>
Date:   Tue Mar 28 23:35:34 2023 +0800

    ubi: Fix return value overwrite issue in try_write_vid_and_data()
    
    commit 31a149d5c13c4cbcf97de3435817263a2d8c9d6e upstream.
    
    The commit 2d78aee426d8 ("UBI: simplify LEB write and atomic LEB change code")
    adds helper function, try_write_vid_and_data(), to simplify the code, but this
    helper function has bug, it will return 0 (success) when ubi_io_write_vid_hdr()
    or the ubi_io_write_data() return error number (-EIO, etc), because the return
    value of ubi_wl_put_peb() will overwrite the original return value.
    
    This issue will cause unexpected data loss issue, because the caller of this
    function and UBIFS willn't know the data is lost.
    
    Fixes: 2d78aee426d8 ("UBI: simplify LEB write and atomic LEB change code")
    Cc: [email protected]
    Signed-off-by: Wang YanQing <[email protected]>
    Reviewed-by: Zhihao Cheng <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ubifs: Fix memleak when insert_old_idx() failed [+ + +]
Author: Zhihao Cheng <[email protected]>
Date:   Wed Mar 1 20:29:19 2023 +0800

    ubifs: Fix memleak when insert_old_idx() failed
    
    commit b5fda08ef213352ac2df7447611eb4d383cce929 upstream.
    
    Following process will cause a memleak for copied up znode:
    
    dirty_cow_znode
      zn = copy_znode(c, znode);
      err = insert_old_idx(c, zbr->lnum, zbr->offs);
      if (unlikely(err))
         return ERR_PTR(err);   // No one refers to zn.
    
    Fetch a reproducer in [Link].
    
    Function copy_znode() is split into 2 parts: resource allocation
    and znode replacement, insert_old_idx() is split in similar way,
    so resource cleanup could be done in error handling path without
    corrupting metadata(mem & disk).
    It's okay that old index inserting is put behind of add_idx_dirt(),
    old index is used in layout_leb_in_gaps(), so the two processes do
    not depend on each other.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216705
    Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
    Cc: [email protected]
    Signed-off-by: Zhihao Cheng <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ubifs: Free memory for tmpfile name [+ + +]
Author: Mårten Lindahl <[email protected]>
Date:   Thu Mar 30 11:32:14 2023 +0200

    ubifs: Free memory for tmpfile name
    
    commit 1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3 upstream.
    
    When opening a ubifs tmpfile on an encrypted directory, function
    fscrypt_setup_filename allocates memory for the name that is to be
    stored in the directory entry, but after the name has been copied to the
    directory entry inode, the memory is not freed.
    
    When running kmemleak on it we see that it is registered as a leak. The
    report below is triggered by a simple program 'tmpfile' just opening a
    tmpfile:
    
      unreferenced object 0xffff88810178f380 (size 32):
        comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s)
        backtrace:
          __kmem_cache_alloc_node
          __kmalloc
          fscrypt_setup_filename
          ubifs_tmpfile
          vfs_tmpfile
          path_openat
    
    Free this memory after it has been copied to the inode.
    
    Signed-off-by: Mårten Lindahl <[email protected]>
    Reviewed-by: Zhihao Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: chipidea: fix missing goto in `ci_hdrc_probe` [+ + +]
Author: Yinhao Hu <[email protected]>
Date:   Wed Apr 12 13:58:52 2023 +0800

    usb: chipidea: fix missing goto in `ci_hdrc_probe`
    
    [ Upstream commit d6f712f53b79f5017cdcefafb7a5aea9ec52da5d ]
    
    From the comment of ci_usb_phy_init, it returns an error code if
    usb_phy_init has failed, and it should do some clean up, not just
    return directly.
    
    Fix this by goto the error handling.
    
    Fixes: 74475ede784d ("usb: chipidea: move PHY operation to core")
    Reviewed-by: Dongliang Mu <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Signed-off-by: Yinhao Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: dwc3: fix runtime pm imbalance on probe errors [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Apr 4 09:25:14 2023 +0200

    USB: dwc3: fix runtime pm imbalance on probe errors
    
    commit 9a8ad10c9f2e0925ff26308ec6756b93fc2f4977 upstream.
    
    Make sure not to suspend the device when probe fails to avoid disabling
    clocks and phys multiple times.
    
    Fixes: 328082376aea ("usb: dwc3: fix runtime PM in error path")
    Cc: [email protected]      # 4.8
    Cc: Roger Quadros <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

USB: dwc3: fix runtime pm imbalance on unbind [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Apr 4 09:25:15 2023 +0200

    USB: dwc3: fix runtime pm imbalance on unbind
    
    commit 44d257e9012ee8040e41d224d0e5bfb5ef5427ea upstream.
    
    Make sure to balance the runtime PM usage count on driver unbind by
    adding back the pm_runtime_allow() call that had been erroneously
    removed.
    
    Fixes: 266d0493900a ("usb: dwc3: core: don't trigger runtime pm when remove driver")
    Cc: [email protected]      # 5.9
    Cc: Li Jun <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: dwc3: gadget: Change condition for processing suspend event [+ + +]
Author: Prashanth K <[email protected]>
Date:   Fri Feb 24 11:16:58 2023 +0530

    usb: dwc3: gadget: Change condition for processing suspend event
    
    [ Upstream commit 4decf4060ecfee1f7a710999fcd421645ac0c419 ]
    
    Currently we process the suspend interrupt event only if the
    device is in configured state. Consider a case where device
    is not configured and got suspend interrupt, in that case our
    gadget will still use 100mA as composite_suspend didn't happen.
    But battery charging specification (BC1.2) expects a downstream
    device to draw less than 2.5mA when unconnected OR suspended.
    
    Fix this by removing the condition for processing suspend event,
    and thus composite_resume would set vbus draw to 2.
    
    Fixes: 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler")
    Signed-off-by: Prashanth K <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: gadget: tegra-xudc: Fix crash in vbus_draw [+ + +]
Author: Jon Hunter <[email protected]>
Date:   Wed Apr 5 19:18:53 2023 +0100

    usb: gadget: tegra-xudc: Fix crash in vbus_draw
    
    [ Upstream commit 5629d31955297ca47b9283c64fff70f2f34aa528 ]
    
    Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
    populated the vbus_draw callback for the Tegra XUDC driver. The function
    tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes
    that the pointer 'curr_usbphy' has been initialised, which is not always
    the case because this is only initialised when the USB role is updated.
    Fix this crash, by checking that the 'curr_usbphy' is valid before
    dereferencing.
    
    Fixes: ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
    Reviewed-by: Thierry Reding <[email protected]>
    Signed-off-by: Jon Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: gadget: udc: renesas_usb3: Fix use after free bug in renesas_usb3_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Mon Mar 20 14:29:31 2023 +0800

    usb: gadget: udc: renesas_usb3: Fix use after free bug in renesas_usb3_remove due to race condition
    
    [ Upstream commit 2b947f8769be8b8181dc795fd292d3e7120f5204 ]
    
    In renesas_usb3_probe, role_work is bound with renesas_usb3_role_work.
    renesas_usb3_start will be called to start the work.
    
    If we remove the driver which will call usbhs_remove, there may be
    an unfinished work. The possible sequence is as follows:
    
    CPU0                                    CPU1
    
                                             renesas_usb3_role_work
    renesas_usb3_remove
    usb_role_switch_unregister
    device_unregister
    kfree(sw)
    //free usb3->role_sw
                                             usb_role_switch_set_role
                                             //use usb3->role_sw
    
    The usb3->role_sw could be freed under such circumstance and then
    used in usb_role_switch_set_role.
    
    This bug was found by static analysis. And note that removing a
    driver is a root-only operation, and should never happen in normal
    case. But the root user may directly remove the device which
    will also trigger the remove function.
    
    Fix it by canceling the work before cleanup in the renesas_usb3_remove.
    
    Fixes: 39facfa01c9f ("usb: gadget: udc: renesas_usb3: Add register of usb role switch")
    Signed-off-by: Zheng Wang <[email protected]>
    Reviewed-by: Yoshihiro Shimoda <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: host: xhci-rcar: remove leftover quirk handling [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Tue Mar 7 17:30:37 2023 +0100

    usb: host: xhci-rcar: remove leftover quirk handling
    
    [ Upstream commit 5d67f4861884762ebc2bddb5d667444e45f25782 ]
    
    Loading V3 firmware does not need a quirk anymore, remove the leftover
    code.
    
    Fixes: ed8603e11124 ("usb: host: xhci-rcar: Simplify getting the firmware name for R-Car Gen3")
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: mtu3: fix kernel panic at qmu transfer done irq handler [+ + +]
Author: Chunfeng Yun <[email protected]>
Date:   Mon Apr 17 10:51:59 2023 +0800

    usb: mtu3: fix kernel panic at qmu transfer done irq handler
    
    [ Upstream commit d28f4091ea7ec3510fd6a3c6d433234e7a2bef14 ]
    
    When handle qmu transfer irq, it will unlock @mtu->lock before give back
    request, if another thread handle disconnect event at the same time, and
    try to disable ep, it may lock @mtu->lock and free qmu ring, then qmu
    irq hanlder may get a NULL gpd, avoid the KE by checking gpd's value before
    handling it.
    
    e.g.
    qmu done irq on cpu0                 thread running on cpu1
    
    qmu_done_tx()
      handle gpd [0]
        mtu3_requ_complete()        mtu3_gadget_ep_disable()
          unlock @mtu->lock
            give back request         lock @mtu->lock
                                        mtu3_ep_disable()
                                          mtu3_gpd_ring_free()
                                       unlock @mtu->lock
          lock @mtu->lock
        get next gpd [1]
    
    [1]: goto [0] to handle next gpd, and next gpd may be NULL.
    
    Fixes: 48e0d3735aa5 ("usb: mtu3: supports new QMU format")
    Signed-off-by: Chunfeng Yun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: serial: option: add UNISOC vendor and TOZED LT70C product [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Mon Apr 17 18:20:03 2023 +0300

    USB: serial: option: add UNISOC vendor and TOZED LT70C product
    
    commit a095edfc15f0832e046ae23964e249ef5c95af87 upstream.
    
    Add UNISOC vendor ID and TOZED LT70-C modem which is based from UNISOC
    SL8563. The modem supports the NCM mode. Interface 0 is used for running
    the AT commands. Interface 12 is the ADB interface.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1782 ProdID=4055 Rev=04.04
    S:  Manufacturer=Unisoc Phone
    S:  Product=Unisoc Phone
    S:  SerialNumber=<redacted>
    C:  #Ifs=14 Cfg#= 1 Atr=c0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
    E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#=10 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#=11 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#=12 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#=13 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
    E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
    E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
    E:  Ad=88(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
virtio_net: split free_unused_bufs() [+ + +]
Author: Xuan Zhuo <[email protected]>
Date:   Mon Aug 1 14:38:59 2022 +0800

    virtio_net: split free_unused_bufs()
    
    [ Upstream commit 6e345f8c7cd029ad3aaece15ad4425ac26e4eb63 ]
    
    This patch separates two functions for freeing sq buf and rq buf from
    free_unused_bufs().
    
    When supporting the enable/disable tx/rq queue in the future, it is
    necessary to support separate recovery of a sq buf or a rq buf.
    
    Signed-off-by: Xuan Zhuo <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Stable-dep-of: f8bb51043945 ("virtio_net: suppress cpu stall when free_unused_bufs")
    Signed-off-by: Sasha Levin <[email protected]>

virtio_net: suppress cpu stall when free_unused_bufs [+ + +]
Author: Wenliang Wang <[email protected]>
Date:   Thu May 4 10:27:06 2023 +0800

    virtio_net: suppress cpu stall when free_unused_bufs
    
    [ Upstream commit f8bb5104394560e29017c25bcade4c6b7aabd108 ]
    
    For multi-queue and large ring-size use case, the following error
    occurred when free_unused_bufs:
    rcu: INFO: rcu_sched self-detected stall on CPU.
    
    Fixes: 986a4f4d452d ("virtio_net: multiqueue support")
    Signed-off-by: Wenliang Wang <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vlan: partially enable SIOCSHWTSTAMP in container [+ + +]
Author: Vadim Fedorenko <[email protected]>
Date:   Wed Mar 15 08:33:02 2023 -0700

    vlan: partially enable SIOCSHWTSTAMP in container
    
    [ Upstream commit 731b73dba359e3ff00517c13aa0daa82b34ff466 ]
    
    Setting timestamp filter was explicitly disabled on vlan devices in
    containers because it might affect other processes on the host. But it's
    absolutely legit in case when real device is in the same namespace.
    
    Fixes: 873017af7784 ("vlan: disable SIOCSHWTSTAMP in container")
    Signed-off-by: Vadim Fedorenko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vmci_host: fix a race condition in vmci_host_poll() causing GPF [+ + +]
Author: Dae R. Jeong <[email protected]>
Date:   Mon Mar 27 21:01:53 2023 +0900

    vmci_host: fix a race condition in vmci_host_poll() causing GPF
    
    [ Upstream commit ae13381da5ff0e8e084c0323c3cc0a945e43e9c7 ]
    
    During fuzzing, a general protection fault is observed in
    vmci_host_poll().
    
    general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf]
    RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926
    <- omitting registers ->
    Call Trace:
     <TASK>
     lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672
     __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
     _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162
     add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22
     poll_wait include/linux/poll.h:49 [inline]
     vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174
     vfs_poll include/linux/poll.h:88 [inline]
     do_pollfd fs/select.c:873 [inline]
     do_poll fs/select.c:921 [inline]
     do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015
     __do_sys_ppoll fs/select.c:1121 [inline]
     __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Example thread interleaving that causes the general protection fault
    is as follows:
    
    CPU1 (vmci_host_poll)               CPU2 (vmci_host_do_init_context)
    -----                               -----
    // Read uninitialized context
    context = vmci_host_dev->context;
                                        // Initialize context
                                        vmci_host_dev->context = vmci_ctx_create();
                                        vmci_host_dev->ct_type = VMCIOBJ_CONTEXT;
    
    if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) {
        // Dereferencing the wrong pointer
        poll_wait(..., &context->host_context);
    }
    
    In this scenario, vmci_host_poll() reads vmci_host_dev->context first,
    and then reads vmci_host_dev->ct_type to check that
    vmci_host_dev->context is initialized. However, since these two reads
    are not atomically executed, there is a chance of a race condition as
    described above.
    
    To fix this race condition, read vmci_host_dev->context after checking
    the value of vmci_host_dev->ct_type so that vmci_host_poll() always
    reads an initialized context.
    
    Reported-by: Dae R. Jeong <[email protected]>
    Fixes: 8bf503991f87 ("VMCI: host side driver implementation.")
    Signed-off-by: Dae R. Jeong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
watchdog: dw_wdt: Fix the error handling path of dw_wdt_drv_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Wed Apr 26 08:52:48 2023 +0200

    watchdog: dw_wdt: Fix the error handling path of dw_wdt_drv_probe()
    
    [ Upstream commit 7f5390750645756bd5da2b24fac285f2654dd922 ]
    
    The commit in Fixes has only updated the remove function and missed the
    error handling path of the probe.
    
    Add the missing reset_control_assert() call.
    
    Fixes: 65a3b6935d92 ("watchdog: dw_wdt: get reset lines from dt")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Philipp Zabel <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/fbb650650bbb33a8fa2fd028c23157bedeed50e1.1682491863.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: ath5k: fix an off by one check in ath5k_eeprom_read_freq_list() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Feb 6 16:15:48 2023 +0300

    wifi: ath5k: fix an off by one check in ath5k_eeprom_read_freq_list()
    
    [ Upstream commit 4c856ee12df85aabd437c3836ed9f68d94268358 ]
    
    This loop checks that i < max at the start of loop but then it does
    i++ which could put it past the end of the array.  It's harmless to
    check again and prevent a potential out of bounds.
    
    Fixes: 1048643ea94d ("ath5k: Clean up eeprom parsing and add missing calibration data")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Luis Chamberlain <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/Y+D9hPQrHfWBJhXz@kili
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath6kl: minor fix for allocation size [+ + +]
Author: Alexey V. Vissarionov <[email protected]>
Date:   Wed Feb 15 20:31:37 2023 +0200

    wifi: ath6kl: minor fix for allocation size
    
    [ Upstream commit 778f83f889e7fca37780d9640fcbd0229ae38eaa ]
    
    Although the "param" pointer occupies more or equal space compared
    to "*param", the allocation size should use the size of variable
    itself.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bdcd81707973cf8a ("Add ath6kl cleaned up driver")
    Signed-off-by: Alexey V. Vissarionov <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath6kl: reduce WARN to dev_dbg() in callback [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Fri Feb 24 12:28:05 2023 +0200

    wifi: ath6kl: reduce WARN to dev_dbg() in callback
    
    [ Upstream commit 75c4a8154cb6c7239fb55d5550f481f6765fb83c ]
    
    The warn is triggered on a known race condition, documented in the code above
    the test, that is correctly handled.  Using WARN() hinders automated testing.
    Reducing severity.
    
    Fixes: de2070fc4aa7 ("ath6kl: Fix kernel panic on continuous driver load/unload")
    Reported-and-tested-by: [email protected]
    Signed-off-by: Oliver Neukum <[email protected]>
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: Alexey Khoroshilov <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath9k: hif_usb: fix memory leak of remain_skbs [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Thu Feb 16 22:23:01 2023 +0300

    wifi: ath9k: hif_usb: fix memory leak of remain_skbs
    
    [ Upstream commit 7654cc03eb699297130b693ec34e25f77b17c947 ]
    
    hif_dev->remain_skb is allocated and used exclusively in
    ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is
    processed and subsequently freed (in error paths) only during the next
    call of ath9k_hif_usb_rx_stream().
    
    So, if the urbs are deallocated between those two calls due to the device
    deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()
    is not called next time and the allocated remain_skb is leaked. Our local
    Syzkaller instance was able to trigger that.
    
    remain_skb makes sense when receiving two consecutive urbs which are
    logically linked together, i.e. a specific data field from the first skb
    indicates a cached skb to be allocated, memcpy'd with some data and
    subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs
    deallocation supposedly makes that link irrelevant so we need to free the
    cached skb in those cases.
    
    Fix the leak by introducing a function to explicitly free remain_skb (if
    it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL
    when it has not been allocated at all (hif_dev struct is kzalloced) or
    when it has been processed in next call to ath9k_hif_usb_rx_stream().
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: Alexey Khoroshilov <[email protected]>
    Acked-by: Toke Høiland-Jørgensen <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() [+ + +]
Author: Jisoo Jang <[email protected]>
Date:   Thu Mar 9 19:44:57 2023 +0900

    wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()
    
    commit 0da40e018fd034d87c9460123fa7f897b69fdee7 upstream.
    
    Fix a slab-out-of-bounds read that occurs in kmemdup() called from
    brcmf_get_assoc_ies().
    The bug could occur when assoc_info->req_len, data from a URB provided
    by a USB device, is bigger than the size of buffer which is defined as
    WL_EXTRA_BUF_MAX.
    
    Add the size check for req_len/resp_len of assoc_info.
    
    Found by a modified version of syzkaller.
    
    [   46.592467][    T7] ==================================================================
    [   46.594687][    T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50
    [   46.596572][    T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7
    [   46.598575][    T7]
    [   46.599157][    T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G           O      5.14.0+ #145
    [   46.601333][    T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
    [   46.604360][    T7] Workqueue: events brcmf_fweh_event_worker
    [   46.605943][    T7] Call Trace:
    [   46.606584][    T7]  dump_stack_lvl+0x8e/0xd1
    [   46.607446][    T7]  print_address_description.constprop.0.cold+0x93/0x334
    [   46.608610][    T7]  ? kmemdup+0x3e/0x50
    [   46.609341][    T7]  kasan_report.cold+0x79/0xd5
    [   46.610151][    T7]  ? kmemdup+0x3e/0x50
    [   46.610796][    T7]  kasan_check_range+0x14e/0x1b0
    [   46.611691][    T7]  memcpy+0x20/0x60
    [   46.612323][    T7]  kmemdup+0x3e/0x50
    [   46.612987][    T7]  brcmf_get_assoc_ies+0x967/0xf60
    [   46.613904][    T7]  ? brcmf_notify_vif_event+0x3d0/0x3d0
    [   46.614831][    T7]  ? lock_chain_count+0x20/0x20
    [   46.615683][    T7]  ? mark_lock.part.0+0xfc/0x2770
    [   46.616552][    T7]  ? lock_chain_count+0x20/0x20
    [   46.617409][    T7]  ? mark_lock.part.0+0xfc/0x2770
    [   46.618244][    T7]  ? lock_chain_count+0x20/0x20
    [   46.619024][    T7]  brcmf_bss_connect_done.constprop.0+0x241/0x2e0
    [   46.620019][    T7]  ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0
    [   46.620818][    T7]  ? __lock_acquire+0x181f/0x5790
    [   46.621462][    T7]  brcmf_notify_connect_status+0x448/0x1950
    [   46.622134][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
    [   46.622736][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
    [   46.623390][    T7]  ? find_held_lock+0x2d/0x110
    [   46.623962][    T7]  ? brcmf_fweh_event_worker+0x19f/0xc60
    [   46.624603][    T7]  ? mark_held_locks+0x9f/0xe0
    [   46.625145][    T7]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
    [   46.625871][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
    [   46.626545][    T7]  brcmf_fweh_call_event_handler.isra.0+0x90/0x100
    [   46.627338][    T7]  brcmf_fweh_event_worker+0x557/0xc60
    [   46.627962][    T7]  ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
    [   46.628736][    T7]  ? rcu_read_lock_sched_held+0xa1/0xd0
    [   46.629396][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
    [   46.629970][    T7]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
    [   46.630649][    T7]  process_one_work+0x92b/0x1460
    [   46.631205][    T7]  ? pwq_dec_nr_in_flight+0x330/0x330
    [   46.631821][    T7]  ? rwlock_bug.part.0+0x90/0x90
    [   46.632347][    T7]  worker_thread+0x95/0xe00
    [   46.632832][    T7]  ? __kthread_parkme+0x115/0x1e0
    [   46.633393][    T7]  ? process_one_work+0x1460/0x1460
    [   46.633957][    T7]  kthread+0x3a1/0x480
    [   46.634369][    T7]  ? set_kthread_struct+0x120/0x120
    [   46.634933][    T7]  ret_from_fork+0x1f/0x30
    [   46.635431][    T7]
    [   46.635687][    T7] Allocated by task 7:
    [   46.636151][    T7]  kasan_save_stack+0x1b/0x40
    [   46.636628][    T7]  __kasan_kmalloc+0x7c/0x90
    [   46.637108][    T7]  kmem_cache_alloc_trace+0x19e/0x330
    [   46.637696][    T7]  brcmf_cfg80211_attach+0x4a0/0x4040
    [   46.638275][    T7]  brcmf_attach+0x389/0xd40
    [   46.638739][    T7]  brcmf_usb_probe+0x12de/0x1690
    [   46.639279][    T7]  usb_probe_interface+0x2aa/0x760
    [   46.639820][    T7]  really_probe+0x205/0xb70
    [   46.640342][    T7]  __driver_probe_device+0x311/0x4b0
    [   46.640876][    T7]  driver_probe_device+0x4e/0x150
    [   46.641445][    T7]  __device_attach_driver+0x1cc/0x2a0
    [   46.642000][    T7]  bus_for_each_drv+0x156/0x1d0
    [   46.642543][    T7]  __device_attach+0x23f/0x3a0
    [   46.643065][    T7]  bus_probe_device+0x1da/0x290
    [   46.643644][    T7]  device_add+0xb7b/0x1eb0
    [   46.644130][    T7]  usb_set_configuration+0xf59/0x16f0
    [   46.644720][    T7]  usb_generic_driver_probe+0x82/0xa0
    [   46.645295][    T7]  usb_probe_device+0xbb/0x250
    [   46.645786][    T7]  really_probe+0x205/0xb70
    [   46.646258][    T7]  __driver_probe_device+0x311/0x4b0
    [   46.646804][    T7]  driver_probe_device+0x4e/0x150
    [   46.647387][    T7]  __device_attach_driver+0x1cc/0x2a0
    [   46.647926][    T7]  bus_for_each_drv+0x156/0x1d0
    [   46.648454][    T7]  __device_attach+0x23f/0x3a0
    [   46.648939][    T7]  bus_probe_device+0x1da/0x290
    [   46.649478][    T7]  device_add+0xb7b/0x1eb0
    [   46.649936][    T7]  usb_new_device.cold+0x49c/0x1029
    [   46.650526][    T7]  hub_event+0x1c98/0x3950
    [   46.650975][    T7]  process_one_work+0x92b/0x1460
    [   46.651535][    T7]  worker_thread+0x95/0xe00
    [   46.651991][    T7]  kthread+0x3a1/0x480
    [   46.652413][    T7]  ret_from_fork+0x1f/0x30
    [   46.652885][    T7]
    [   46.653131][    T7] The buggy address belongs to the object at ffff888019442000
    [   46.653131][    T7]  which belongs to the cache kmalloc-2k of size 2048
    [   46.654669][    T7] The buggy address is located 0 bytes inside of
    [   46.654669][    T7]  2048-byte region [ffff888019442000, ffff888019442800)
    [   46.656137][    T7] The buggy address belongs to the page:
    [   46.656720][    T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440
    [   46.657792][    T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0
    [   46.658673][    T7] flags: 0x100000000010200(slab|head|node=0|zone=1)
    [   46.659422][    T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000
    [   46.660363][    T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
    [   46.661236][    T7] page dumped because: kasan: bad access detected
    [   46.661956][    T7] page_owner tracks the page as allocated
    [   46.662588][    T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0
    [   46.664271][    T7]  prep_new_page+0x1aa/0x240
    [   46.664763][    T7]  get_page_from_freelist+0x159a/0x27c0
    [   46.665340][    T7]  __alloc_pages+0x2da/0x6a0
    [   46.665847][    T7]  alloc_pages+0xec/0x1e0
    [   46.666308][    T7]  allocate_slab+0x380/0x4e0
    [   46.666770][    T7]  ___slab_alloc+0x5bc/0x940
    [   46.667264][    T7]  __slab_alloc+0x6d/0x80
    [   46.667712][    T7]  kmem_cache_alloc_trace+0x30a/0x330
    [   46.668299][    T7]  brcmf_usbdev_qinit.constprop.0+0x50/0x470
    [   46.668885][    T7]  brcmf_usb_probe+0xc97/0x1690
    [   46.669438][    T7]  usb_probe_interface+0x2aa/0x760
    [   46.669988][    T7]  really_probe+0x205/0xb70
    [   46.670487][    T7]  __driver_probe_device+0x311/0x4b0
    [   46.671031][    T7]  driver_probe_device+0x4e/0x150
    [   46.671604][    T7]  __device_attach_driver+0x1cc/0x2a0
    [   46.672192][    T7]  bus_for_each_drv+0x156/0x1d0
    [   46.672739][    T7] page_owner free stack trace missing
    [   46.673335][    T7]
    [   46.673620][    T7] Memory state around the buggy address:
    [   46.674213][    T7]  ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   46.675083][    T7]  ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   46.675994][    T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   46.676875][    T7]                    ^
    [   46.677323][    T7]  ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   46.678190][    T7]  ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   46.679052][    T7] ==================================================================
    [   46.679945][    T7] Disabling lock debugging due to kernel taint
    [   46.680725][    T7] Kernel panic - not syncing:
    
    Reviewed-by: Arend van Spriel <[email protected]>
    Signed-off-by: Jisoo Jang <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: iwlwifi: fw: fix memory leak in debugfs [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Apr 18 12:28:05 2023 +0300

    wifi: iwlwifi: fw: fix memory leak in debugfs
    
    [ Upstream commit 3d90d2f4a018fe8cfd65068bc6350b6222be4852 ]
    
    Fix a memory leak that occurs when reading the fw_info
    file all the way, since we return NULL indicating no
    more data, but don't free the status tracking object.
    
    Fixes: 36dfe9ac6e8b ("iwlwifi: dump api version in yaml format")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230418122405.239e501b3b8d.I4268f87809ef91209cbcd748eee0863195e70fa2@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: fw: move memset before early return [+ + +]
Author: Tom Rix <[email protected]>
Date:   Fri Apr 14 13:11:58 2023 +0300

    wifi: iwlwifi: fw: move memset before early return
    
    [ Upstream commit 8ce437dd5b2e4adef13aa4ecce07392f9966b1ab ]
    
    Clang static analysis reports this representative issue
    dbg.c:1455:6: warning: Branch condition evaluates to
    a garbage value
      if (!rxf_data.size)
           ^~~~~~~~~~~~~~
    
    This check depends on iwl_ini_get_rxf_data() to clear
    rxf_data but the function can return early without
    doing the clear.  So move the memset before the early
    return.
    
    Fixes: cc9b6012d34b ("iwlwifi: yoyo: use hweight_long instead of bit manipulating")
    Signed-off-by: Tom Rix <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230414130637.872a7175f1ff.I33802a77a91998276992b088fbe25f61c87c33ac@changeid
    Signed-off-by: Johannes Berg <johann[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: make the loop for card preparation effective [+ + +]
Author: Emmanuel Grumbach <[email protected]>
Date:   Sun Apr 16 15:47:38 2023 +0300

    wifi: iwlwifi: make the loop for card preparation effective
    
    [ Upstream commit 28965ec0b5d9112585f725660e2ff13218505ace ]
    
    Since we didn't reset t to 0, only the first iteration of the loop
    did checked the ready bit several times.
    From the second iteration and on, we just tested the bit once and
    continued to the next iteration.
    
    Reported-and-tested-by: Lorenzo Zolfanelli <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216452
    Fixes: 289e5501c314 ("iwlwifi: fix the preparation of the card")
    Signed-off-by: Emmanuel Grumbach <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230416154301.615b683ab9c8.Ic52c3229d3345b0064fa34263293db095d88daf8@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: mvm: check firmware response size [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Mon Apr 17 11:41:33 2023 +0300

    wifi: iwlwifi: mvm: check firmware response size
    
    [ Upstream commit 13513cec93ac9902d0b896976d8bab3758a9881c ]
    
    Check the firmware response size for responses to the
    memory read/write command in debugfs before using it.
    
    Fixes: 2b55f43f8e47 ("iwlwifi: mvm: Add mem debugfs entry")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230417113648.0d56fcaf68ee.I70e9571f3ed7263929b04f8fabad23c9b999e4ea@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: yoyo: Fix possible division by zero [+ + +]
Author: Daniel Gabay <[email protected]>
Date:   Thu Apr 13 21:40:34 2023 +0300

    wifi: iwlwifi: yoyo: Fix possible division by zero
    
    [ Upstream commit ba30415118eee374a08b39a0460a1d1e52c24a25 ]
    
    Don't allow buffer allocation TLV with zero req_size since it
    leads later to division by zero in iwl_dbg_tlv_alloc_fragments().
    Also, NPK/SRAM locations are allowed to have zero buffer req_size,
    don't discard them.
    
    Fixes: a9248de42464 ("iwlwifi: dbg_ini: add TLV allocation new API support")
    Signed-off-by: Daniel Gabay <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230413213309.5d6688ed74d8.I5c2f3a882b50698b708d54f4524dc5bdf11e3d32@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtl8xxxu: RTL8192EU always needs full init [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Mon Mar 13 15:42:59 2023 +0200

    wifi: rtl8xxxu: RTL8192EU always needs full init
    
    commit d46e04ccd40457a0119b76e11ab64a2ad403e138 upstream.
    
    Always run the entire init sequence (rtl8xxxu_init_device()) for
    RTL8192EU. It's what the vendor driver does too.
    
    This fixes a bug where the device is unable to connect after
    rebooting:
    
    wlp3s0f3u2: send auth to ... (try 1/3)
    wlp3s0f3u2: send auth to ... (try 2/3)
    wlp3s0f3u2: send auth to ... (try 3/3)
    wlp3s0f3u2: authentication with ... timed out
    
    Rebooting leaves the device powered on (partially? at least the
    firmware is still running), but not really in a working state.
    
    Cc: [email protected]
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Jes Sorensen <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtlwifi: fix incorrect error codes in rtl_debugfs_set_write_reg() [+ + +]
Author: Wei Chen <[email protected]>
Date:   Sun Mar 26 05:42:17 2023 +0000

    wifi: rtlwifi: fix incorrect error codes in rtl_debugfs_set_write_reg()
    
    [ Upstream commit 5dbe1f8eb8c5ac69394400a5b86fd81775e96c43 ]
    
    If there is a failure during copy_from_user or user-provided data buffer is
    invalid, rtl_debugfs_set_write_reg should return negative error code instead
    of a positive value count.
    
    Fix this bug by returning correct error code. Moreover, the check of buffer
    against null is removed since it will be handled by copy_from_user.
    
    Fixes: 610247f46feb ("rtlwifi: Improve debugging by using debugfs")
    Signed-off-by: Wei Chen <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: fix incorrect error codes in rtl_debugfs_set_write_rfreg() [+ + +]
Author: Wei Chen <[email protected]>
Date:   Sun Mar 26 05:31:38 2023 +0000

    wifi: rtlwifi: fix incorrect error codes in rtl_debugfs_set_write_rfreg()
    
    [ Upstream commit 905a9241e4e8c15d2c084fee916280514848fe35 ]
    
    If there is a failure during copy_from_user or user-provided data buffer
    is invalid, rtl_debugfs_set_write_rfreg should return negative error code
    instead of a positive value count.
    
    Fix this bug by returning correct error code. Moreover, the check of buffer
    against null is removed since it will be handled by copy_from_user.
    
    Fixes: 610247f46feb ("rtlwifi: Improve debugging by using debugfs")
    Signed-off-by: Wei Chen <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: mac: Return the original error from rtw_mac_power_switch() [+ + +]
Author: Martin Blumenstingl <[email protected]>
Date:   Sun Feb 26 23:10:04 2023 +0100

    wifi: rtw88: mac: Return the original error from rtw_mac_power_switch()
    
    [ Upstream commit 15c8e267dfa62f207ee1db666c822324e3362b84 ]
    
    rtw_mac_power_switch() calls rtw_pwr_seq_parser() which can return
    -EINVAL, -EBUSY or 0. Propagate the original error code instead of
    unconditionally returning -EINVAL in case of an error.
    
    Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: mac: Return the original error from rtw_pwr_seq_parser() [+ + +]
Author: Martin Blumenstingl <[email protected]>
Date:   Sun Feb 26 23:10:03 2023 +0100

    wifi: rtw88: mac: Return the original error from rtw_pwr_seq_parser()
    
    [ Upstream commit b7ed9fa2cb76ca7a3c3cd4a6d35748fe1fbda9f6 ]
    
    rtw_pwr_seq_parser() calls rtw_sub_pwr_seq_parser() which can either
    return -EBUSY, -EINVAL or 0. Propagate the original error code instead
    of unconditionally returning -EBUSY in case of an error.
    
    Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
wireguard: timers: cast enum limits members to int in prints [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Tue Dec 13 15:52:08 2022 -0700

    wireguard: timers: cast enum limits members to int in prints
    
    commit 2d4ee16d969c97996e80e4c9cb6de0acaff22c9f upstream.
    
    Since gcc13, each member of an enum has the same type as the enum. And
    that is inherited from its members. Provided "REKEY_AFTER_MESSAGES =
    1ULL << 60", the named type is unsigned long.
    
    This generates warnings with gcc-13:
      error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int'
    
    Cast those particular enum members to int when printing them.
    
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
    Cc: Martin Liska <[email protected]>
    Signed-off-by: Jiri Slaby (SUSE) <[email protected]>
    Signed-off-by: Jason A. Donenfeld <[email protected]>
    Link: https://lore.kernel.org/all/20221213225208.3343692-2-Jason@zx2c4.com/
    Signed-off-by: Jakub Kicinski <[email protected]>
    Cc: Chris Clayton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
workqueue: Fix hung time report of worker pools [+ + +]
Author: Petr Mladek <[email protected]>
Date:   Tue Mar 7 13:53:31 2023 +0100

    workqueue: Fix hung time report of worker pools
    
    [ Upstream commit 335a42ebb0ca8ee9997a1731aaaae6dcd704c113 ]
    
    The workqueue watchdog prints a warning when there is no progress in
    a worker pool. Where the progress means that the pool started processing
    a pending work item.
    
    Note that it is perfectly fine to process work items much longer.
    The progress should be guaranteed by waking up or creating idle
    workers.
    
    show_one_worker_pool() prints state of non-idle worker pool. It shows
    a delay since the last pool->watchdog_ts.
    
    The timestamp is updated when a first pending work is queued in
    __queue_work(). Also it is updated when a work is dequeued for
    processing in worker_thread() and rescuer_thread().
    
    The delay is misleading when there is no pending work item. In this
    case it shows how long the last work item is being proceed. Show
    zero instead. There is no stall if there is no pending work.
    
    Fixes: 82607adcf9cdf40fb7b ("workqueue: implement lockup detector")
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

workqueue: Rename "delayed" (delayed by active management) to "inactive" [+ + +]
Author: Lai Jiangshan <[email protected]>
Date:   Tue Aug 17 09:32:34 2021 +0800

    workqueue: Rename "delayed" (delayed by active management) to "inactive"
    
    [ Upstream commit f97a4a1a3f8769e3452885967955e21c88f3f263 ]
    
    There are two kinds of "delayed" work items in workqueue subsystem.
    
    One is for timer-delayed work items which are visible to workqueue users.
    The other kind is for work items delayed by active management which can
    not be directly visible to workqueue users.  We mixed the word "delayed"
    for both kinds and caused somewhat ambiguity.
    
    This patch renames the later one (delayed by active management) to
    "inactive", because it is used for workqueue active management and
    most of its related symbols are named with "active" or "activate".
    
    All "delayed" and "DELAYED" are carefully checked and renamed one by
    one to avoid accidentally changing the name of the other kind for
    timer-delayed.
    
    No functional change intended.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Stable-dep-of: 335a42ebb0ca ("workqueue: Fix hung time report of worker pools")
    Signed-off-by: Sasha Levin <[email protected]>

 
writeback, cgroup: fix null-ptr-deref write in bdi_split_work_to_wbs [+ + +]
Author: Baokun Li <[email protected]>
Date:   Mon Apr 10 21:08:26 2023 +0800

    writeback, cgroup: fix null-ptr-deref write in bdi_split_work_to_wbs
    
    [ Upstream commit 1ba1199ec5747f475538c0d25a32804e5ba1dfde ]
    
    KASAN report null-ptr-deref:
    ==================================================================
    BUG: KASAN: null-ptr-deref in bdi_split_work_to_wbs+0x5c5/0x7b0
    Write of size 8 at addr 0000000000000000 by task sync/943
    CPU: 5 PID: 943 Comm: sync Tainted: 6.3.0-rc5-next-20230406-dirty #461
    Call Trace:
     <TASK>
     dump_stack_lvl+0x7f/0xc0
     print_report+0x2ba/0x340
     kasan_report+0xc4/0x120
     kasan_check_range+0x1b7/0x2e0
     __kasan_check_write+0x24/0x40
     bdi_split_work_to_wbs+0x5c5/0x7b0
     sync_inodes_sb+0x195/0x630
     sync_inodes_one_sb+0x3a/0x50
     iterate_supers+0x106/0x1b0
     ksys_sync+0x98/0x160
    [...]
    ==================================================================
    
    The race that causes the above issue is as follows:
    
               cpu1                     cpu2
    -------------------------|-------------------------
    inode_switch_wbs
     INIT_WORK(&isw->work, inode_switch_wbs_work_fn)
     queue_rcu_work(isw_wq, &isw->work)
     // queue_work async
      inode_switch_wbs_work_fn
       wb_put_many(old_wb, nr_switched)
        percpu_ref_put_many
         ref->data->release(ref)
         cgwb_release
          queue_work(cgwb_release_wq, &wb->release_work)
          // queue_work async
           &wb->release_work
           cgwb_release_workfn
                                ksys_sync
                                 iterate_supers
                                  sync_inodes_one_sb
                                   sync_inodes_sb
                                    bdi_split_work_to_wbs
                                     kmalloc(sizeof(*work), GFP_ATOMIC)
                                     // alloc memory failed
            percpu_ref_exit
             ref->data = NULL
             kfree(data)
                                     wb_get(wb)
                                      percpu_ref_get(&wb->refcnt)
                                       percpu_ref_get_many(ref, 1)
                                        atomic_long_add(nr, &ref->data->count)
                                         atomic64_add(i, v)
                                         // trigger null-ptr-deref
    
    bdi_split_work_to_wbs() traverses &bdi->wb_list to split work into all
    wbs.  If the allocation of new work fails, the on-stack fallback will be
    used and the reference count of the current wb is increased afterwards.
    If cgroup writeback membership switches occur before getting the reference
    count and the current wb is released as old_wd, then calling wb_get() or
    wb_put() will trigger the null pointer dereference above.
    
    This issue was introduced in v4.3-rc7 (see fix tag1).  Both
    sync_inodes_sb() and __writeback_inodes_sb_nr() calls to
    bdi_split_work_to_wbs() can trigger this issue.  For scenarios called via
    sync_inodes_sb(), originally commit 7fc5854f8c6e ("writeback: synchronize
    sync(2) against cgroup writeback membership switches") reduced the
    possibility of the issue by adding wb_switch_rwsem, but in v5.14-rc1 (see
    fix tag2) removed the "inode_io_list_del_locked(inode, old_wb)" from
    inode_switch_wbs_work_fn() so that wb->state contains WB_has_dirty_io,
    thus old_wb is not skipped when traversing wbs in bdi_split_work_to_wbs(),
    and the issue becomes easily reproducible again.
    
    To solve this problem, percpu_ref_exit() is called under RCU protection to
    avoid race between cgwb_release_workfn() and bdi_split_work_to_wbs().
    Moreover, replace wb_get() with wb_tryget() in bdi_split_work_to_wbs(),
    and skip the current wb if wb_tryget() fails because the wb has already
    been shutdown.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b817525a4a80 ("writeback: bdi_writeback iteration must not skip dying ones")
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Cc: Alexander Viro <[email protected]>
    Cc: Andreas Dilger <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: Dennis Zhou <[email protected]>
    Cc: Hou Tao <[email protected]>
    Cc: yangerkun <[email protected]>
    Cc: Zhang Yi <[email protected]>
    Cc: Jens Axboe <axb[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
writeback: fix call of incorrect macro [+ + +]
Author: Maxim Korotkov <[email protected]>
Date:   Thu Jan 19 13:44:43 2023 +0300

    writeback: fix call of incorrect macro
    
    [ Upstream commit 3e46c89c74f2c38e5337d2cf44b0b551adff1cb4 ]
    
     the variable 'history' is of type u16, it may be an error
     that the hweight32 macro was used for it
     I guess macro hweight16 should be used
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 2a81490811d0 ("writeback: implement foreign cgroup inode detection")
    Signed-off-by: Maxim Korotkov <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/apic: Fix atomic update of offset in reserve_eilvt_offset() [+ + +]
Author: Uros Bizjak <[email protected]>
Date:   Mon Feb 27 17:09:17 2023 +0100

    x86/apic: Fix atomic update of offset in reserve_eilvt_offset()
    
    [ Upstream commit f96fb2df3eb31ede1b34b0521560967310267750 ]
    
    The detection of atomic update failure in reserve_eilvt_offset() is
    not correct. The value returned by atomic_cmpxchg() should be compared
    to the old value from the location to be updated.
    
    If these two are the same, then atomic update succeeded and
    "eilvt_offsets[offset]" location is updated to "new" in an atomic way.
    
    Otherwise, the atomic update failed and it should be retried with the
    value from "eilvt_offsets[offset]" - exactly what atomic_try_cmpxchg()
    does in a correct and more optimal way.
    
    Fixes: a68c439b1966c ("apic, x86: Check if EILVT APIC registers are available (AMD only)")
    Signed-off-by: Uros Bizjak <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/fpu: Prevent FPU state corruption [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Sun May 1 21:31:43 2022 +0200

    x86/fpu: Prevent FPU state corruption
    
    commit 59f5ede3bc0f00eb856425f636dab0c10feb06d8 upstream.
    
    The FPU usage related to task FPU management is either protected by
    disabling interrupts (switch_to, return to user) or via fpregs_lock() which
    is a wrapper around local_bh_disable(). When kernel code wants to use the
    FPU then it has to check whether it is possible by calling irq_fpu_usable().
    
    But the condition in irq_fpu_usable() is wrong. It allows FPU to be used
    when:
    
       !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle()
    
    The latter is checking whether some other context already uses FPU in the
    kernel, but if that's not the case then it allows FPU to be used
    unconditionally even if the calling context interrupted a fpregs_lock()
    critical region. If that happens then the FPU state of the interrupted
    context becomes corrupted.
    
    Allow in kernel FPU usage only when no other context has in kernel FPU
    usage and either the calling context is not hard interrupt context or the
    hard interrupt did not interrupt a local bottomhalf disabled region.
    
    It's hard to find a proper Fixes tag as the condition was broken in one way
    or the other for a very long time and the eager/lazy FPU changes caused a
    lot of churn. Picked something remotely connected from the history.
    
    This survived undetected for quite some time as FPU usage in interrupt
    context is rare, but the recent changes to the random code unearthed it at
    least on a kernel which had FPU debugging enabled. There is probably a
    higher rate of silent corruption as not all issues can be detected by the
    FPU debugging code. This will be addressed in a subsequent change.
    
    Fixes: 5d2bd7009f30 ("x86, fpu: decouple non-lazy/eager fpu restore from xsave")
    Reported-by: Filipe Manana <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Filipe Manana <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Can Sun <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/ioapic: Don't return 0 from arch_dynirq_lower_bound() [+ + +]
Author: Saurabh Sengar <[email protected]>
Date:   Tue Mar 28 00:30:04 2023 -0700

    x86/ioapic: Don't return 0 from arch_dynirq_lower_bound()
    
    [ Upstream commit 5af507bef93c09a94fb8f058213b489178f4cbe5 ]
    
    arch_dynirq_lower_bound() is invoked by the core interrupt code to
    retrieve the lowest possible Linux interrupt number for dynamically
    allocated interrupts like MSI.
    
    The x86 implementation uses this to exclude the IO/APIC GSI space.
    This works correctly as long as there is an IO/APIC registered, but
    returns 0 if not. This has been observed in VMs where the BIOS does
    not advertise an IO/APIC.
    
    0 is an invalid interrupt number except for the legacy timer interrupt
    on x86. The return value is unchecked in the core code, so it ends up
    to allocate interrupt number 0 which is subsequently considered to be
    invalid by the caller, e.g. the MSI allocation code.
    
    The function has already a check for 0 in the case that an IO/APIC is
    registered, as ioapic_dynirq_base is 0 in case of device tree setups.
    
    Consolidate this and zero check for both ioapic_dynirq_base and gsi_top,
    which is used in the case that no IO/APIC is registered.
    
    Fixes: 3e5bedc2c258 ("x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled machines")
    Signed-off-by: Saurabh Sengar <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/MCE/AMD: Use an u64 for bank_map [+ + +]
Author: Muralidhara M K <[email protected]>
Date:   Fri Jan 27 15:16:01 2023 +0000

    x86/MCE/AMD: Use an u64 for bank_map
    
    [ Upstream commit 4c1cdec319b9aadb65737c3eb1f5cb74bd6aa156 ]
    
    Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see
    
      a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64").
    
    However, the bank_map which contains a bitfield of which banks to
    initialize is of type unsigned int and that overflows when those bit
    numbers are >= 32, leading to UBSAN complaining correctly:
    
      UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38
      shift exponent 32 is too large for 32-bit type 'int'
    
    Change the bank_map to a u64 and use the proper BIT_ULL() macro when
    modifying bits in there.
    
      [ bp: Rewrite commit message. ]
    
    Fixes: a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64")
    Signed-off-by: Muralidhara M K <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
xhci: fix debugfs register accesses while suspended [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Wed Apr 5 11:03:42 2023 +0200

    xhci: fix debugfs register accesses while suspended
    
    commit 735baf1b23458f71a8b15cb924af22c9ff9cd125 upstream.
    
    Wire up the debugfs regset device pointer so that the controller is
    resumed before accessing registers to avoid crashing or locking up if it
    happens to be runtime suspended.
    
    Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
    Cc: [email protected] # 4.15: 30332eeefec8: debugfs: regset32: Add Runtime PM support
    Cc: [email protected] # 4.15
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xsk: Fix unaligned descriptor validation [+ + +]
Author: Kal Conley <[email protected]>
Date:   Thu Apr 6 01:59:18 2023 +0200

    xsk: Fix unaligned descriptor validation
    
    [ Upstream commit d769ccaf957fe7391f357c0a923de71f594b8a2b ]
    
    Make sure unaligned descriptors that straddle the end of the UMEM are
    considered invalid. Currently, descriptor validation is broken for
    zero-copy mode which only checks descriptors at page granularity.
    For example, descriptors in zero-copy mode that overrun the end of the
    UMEM but not a page boundary are (incorrectly) considered valid. The
    UMEM boundary check needs to happen before the page boundary and
    contiguity checks in xp_desc_crosses_non_contig_pg(). Do this check in
    xp_unaligned_validate_desc() instead like xp_check_unaligned() already
    does.
    
    Fixes: 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API")
    Signed-off-by: Kal Conley <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>