Linux 5.10.164

 
ALSA: hda/realtek: Enable mute/micmute LEDs on HP Spectre x360 13-aw0xxx [+ + +]
Author: Luka Guzenko <l.guzenko@web.de>
Date:   Tue Jan 10 21:25:14 2023 +0100

    ALSA: hda/realtek: Enable mute/micmute LEDs on HP Spectre x360 13-aw0xxx
    
    commit ca88eeb308a221c2dcd4a64031d2e5fcd3db9eaa upstream.
    
    The HP Spectre x360 13-aw0xxx devices use the ALC285 codec with GPIO 0x04
    controlling the micmute LED and COEF 0x0b index 8 controlling the mute LED.
    A quirk was added to make these work as well as a fixup.
    
    Signed-off-by: Luka Guzenko <l.guzenko@web.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230110202514.2792-1-l.guzenko@web.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: atomics: format whitespace consistently [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Dec 10 15:14:06 2021 +0000

    arm64: atomics: format whitespace consistently
    
    [ Upstream commit 8e6082e94aac6d0338883b5953631b662a5a9188 ]
    
    The code for the atomic ops is formatted inconsistently, and while this
    is not a functional problem it is rather distracting when working on
    them.
    
    Some have ops have consistent indentation, e.g.
    
    | #define ATOMIC_OP_ADD_RETURN(name, mb, cl...)                           \
    | static inline int __lse_atomic_add_return##name(int i, atomic_t *v)     \
    | {                                                                       \
    |         u32 tmp;                                                        \
    |                                                                         \
    |         asm volatile(                                                   \
    |         __LSE_PREAMBLE                                                  \
    |         "       ldadd" #mb "    %w[i], %w[tmp], %[v]\n"                 \
    |         "       add     %w[i], %w[i], %w[tmp]"                          \
    |         : [i] "+r" (i), [v] "+Q" (v->counter), [tmp] "=&r" (tmp)        \
    |         : "r" (v)                                                       \
    |         : cl);                                                          \
    |                                                                         \
    |         return i;                                                       \
    | }
    
    While others have negative indentation for some lines, and/or have
    misaligned trailing backslashes, e.g.
    
    | static inline void __lse_atomic_##op(int i, atomic_t *v)                        \
    | {                                                                       \
    |         asm volatile(                                                   \
    |         __LSE_PREAMBLE                                                  \
    | "       " #asm_op "     %w[i], %[v]\n"                                  \
    |         : [i] "+r" (i), [v] "+Q" (v->counter)                           \
    |         : "r" (v));                                                     \
    | }
    
    This patch makes the indentation consistent and also aligns the trailing
    backslashes. This makes the code easier to read for those (like myself)
    who are easily distracted by these inconsistencies.
    
    This is intended as a cleanup.
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Acked-by: Will Deacon <will@kernel.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20211210151410.2782645-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Stable-dep-of: 031af50045ea ("arm64: cmpxchg_double*: hazard against entire exchange variable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: atomics: remove LL/SC trampolines [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Aug 17 16:59:13 2022 +0100

    arm64: atomics: remove LL/SC trampolines
    
    [ Upstream commit b2c3ccbd0011bb3b51d0fec24cb3a5812b1ec8ea ]
    
    When CONFIG_ARM64_LSE_ATOMICS=y, each use of an LL/SC atomic results in
    a fragment of code being generated in a subsection without a clear
    association with its caller. A trampoline in the caller branches to the
    LL/SC atomic with with a direct branch, and the atomic directly branches
    back into its trampoline.
    
    This breaks backtracing, as any PC within the out-of-line fragment will
    be symbolized as an offset from the nearest prior symbol (which may not
    be the function using the atomic), and since the atomic returns with a
    direct branch, the caller's PC may be missing from the backtrace.
    
    For example, with secondary_start_kernel() hacked to contain
    atomic_inc(NULL), the resulting exception can be reported as being taken
    from cpus_are_stuck_in_kernel():
    
    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    | Mem abort info:
    |   ESR = 0x0000000096000004
    |   EC = 0x25: DABT (current EL), IL = 32 bits
    |   SET = 0, FnV = 0
    |   EA = 0, S1PTW = 0
    |   FSC = 0x04: level 0 translation fault
    | Data abort info:
    |   ISV = 0, ISS = 0x00000004
    |   CM = 0, WnR = 0
    | [0000000000000000] user address but active_mm is swapper
    | Internal error: Oops: 96000004 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.19.0-11219-geb555cb5b794-dirty #3
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : cpus_are_stuck_in_kernel+0xa4/0x120
    | lr : secondary_start_kernel+0x164/0x170
    | sp : ffff80000a4cbe90
    | x29: ffff80000a4cbe90 x28: 0000000000000000 x27: 0000000000000000
    | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    | x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
    | x20: 0000000000000001 x19: 0000000000000001 x18: 0000000000000008
    | x17: 3030383832343030 x16: 3030303030307830 x15: ffff80000a4cbab0
    | x14: 0000000000000001 x13: 5d31666130663133 x12: 3478305b20313030
    | x11: 3030303030303078 x10: 3020726f73736563 x9 : 726f737365636f72
    | x8 : ffff800009ff2ef0 x7 : 0000000000000003 x6 : 0000000000000000
    | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000100
    | x2 : 0000000000000000 x1 : ffff0000029bd880 x0 : 0000000000000000
    | Call trace:
    |  cpus_are_stuck_in_kernel+0xa4/0x120
    |  __secondary_switched+0xb0/0xb4
    | Code: 35ffffa3 17fffc6c d53cd040 f9800011 (885f7c01)
    | ---[ end trace 0000000000000000 ]---
    
    This is confusing and hinders debugging, and will be problematic for
    CONFIG_LIVEPATCH as these cases cannot be unwound reliably.
    
    This is very similar to recent issues with out-of-line exception fixups,
    which were removed in commits:
    
      35d67794b8828333 ("arm64: lib: __arch_clear_user(): fold fixups into body")
      4012e0e22739eef9 ("arm64: lib: __arch_copy_from_user(): fold fixups into body")
      139f9ab73d60cf76 ("arm64: lib: __arch_copy_to_user(): fold fixups into body")
    
    When the trampolines were introduced in commit:
    
      addfc38672c73efd ("arm64: atomics: avoid out-of-line ll/sc atomics")
    
    The rationale was to improve icache performance by grouping the LL/SC
    atomics together. This has never been measured, and this theoretical
    benefit is outweighed by other factors:
    
    * As the subsections are collapsed into sections at object file
      granularity, these are spread out throughout the kernel and can share
      cachelines with unrelated code regardless.
    
    * GCC 12.1.0 has been observed to place the trampoline out-of-line in
      specialised __ll_sc_*() functions, introducing more branching than was
      intended.
    
    * Removing the trampolines has been observed to shrink a defconfig
      kernel Image by 64KiB when building with GCC 12.1.0.
    
    This patch removes the LL/SC trampolines, meaning that the LL/SC atomics
    will be inlined into their callers (or placed in out-of line functions
    using regular BL/RET pairs). When CONFIG_ARM64_LSE_ATOMICS=y, the LL/SC
    atomics are always called in an unlikely branch, and will be placed in a
    cold portion of the function, so this should have minimal impact to the
    hot paths.
    
    Other than the improved backtracing, there should be no functional
    change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220817155914.3975112-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Stable-dep-of: 031af50045ea ("arm64: cmpxchg_double*: hazard against entire exchange variable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: cmpxchg_double*: hazard against entire exchange variable [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Jan 4 15:16:26 2023 +0000

    arm64: cmpxchg_double*: hazard against entire exchange variable
    
    [ Upstream commit 031af50045ea97ed4386eb3751ca2c134d0fc911 ]
    
    The inline assembly for arm64's cmpxchg_double*() implementations use a
    +Q constraint to hazard against other accesses to the memory location
    being exchanged. However, the pointer passed to the constraint is a
    pointer to unsigned long, and thus the hazard only applies to the first
    8 bytes of the location.
    
    GCC can take advantage of this, assuming that other portions of the
    location are unchanged, leading to a number of potential problems.
    
    This is similar to what we fixed back in commit:
    
      fee960bed5e857eb ("arm64: xchg: hazard against entire exchange variable")
    
    ... but we forgot to adjust cmpxchg_double*() similarly at the same
    time.
    
    The same problem applies, as demonstrated with the following test:
    
    | struct big {
    |         u64 lo, hi;
    | } __aligned(128);
    |
    | unsigned long foo(struct big *b)
    | {
    |         u64 hi_old, hi_new;
    |
    |         hi_old = b->hi;
    |         cmpxchg_double_local(&b->lo, &b->hi, 0x12, 0x34, 0x56, 0x78);
    |         hi_new = b->hi;
    |
    |         return hi_old ^ hi_new;
    | }
    
    ... which GCC 12.1.0 compiles as:
    
    | 0000000000000000 <foo>:
    |    0:   d503233f        paciasp
    |    4:   aa0003e4        mov     x4, x0
    |    8:   1400000e        b       40 <foo+0x40>
    |    c:   d2800240        mov     x0, #0x12                       // #18
    |   10:   d2800681        mov     x1, #0x34                       // #52
    |   14:   aa0003e5        mov     x5, x0
    |   18:   aa0103e6        mov     x6, x1
    |   1c:   d2800ac2        mov     x2, #0x56                       // #86
    |   20:   d2800f03        mov     x3, #0x78                       // #120
    |   24:   48207c82        casp    x0, x1, x2, x3, [x4]
    |   28:   ca050000        eor     x0, x0, x5
    |   2c:   ca060021        eor     x1, x1, x6
    |   30:   aa010000        orr     x0, x0, x1
    |   34:   d2800000        mov     x0, #0x0                        // #0    <--- BANG
    |   38:   d50323bf        autiasp
    |   3c:   d65f03c0        ret
    |   40:   d2800240        mov     x0, #0x12                       // #18
    |   44:   d2800681        mov     x1, #0x34                       // #52
    |   48:   d2800ac2        mov     x2, #0x56                       // #86
    |   4c:   d2800f03        mov     x3, #0x78                       // #120
    |   50:   f9800091        prfm    pstl1strm, [x4]
    |   54:   c87f1885        ldxp    x5, x6, [x4]
    |   58:   ca0000a5        eor     x5, x5, x0
    |   5c:   ca0100c6        eor     x6, x6, x1
    |   60:   aa0600a6        orr     x6, x5, x6
    |   64:   b5000066        cbnz    x6, 70 <foo+0x70>
    |   68:   c8250c82        stxp    w5, x2, x3, [x4]
    |   6c:   35ffff45        cbnz    w5, 54 <foo+0x54>
    |   70:   d2800000        mov     x0, #0x0                        // #0     <--- BANG
    |   74:   d50323bf        autiasp
    |   78:   d65f03c0        ret
    
    Notice that at the lines with "BANG" comments, GCC has assumed that the
    higher 8 bytes are unchanged by the cmpxchg_double() call, and that
    `hi_old ^ hi_new` can be reduced to a constant zero, for both LSE and
    LL/SC versions of cmpxchg_double().
    
    This patch fixes the issue by passing a pointer to __uint128_t into the
    +Q constraint, ensuring that the compiler hazards against the entire 16
    bytes being modified.
    
    With this change, GCC 12.1.0 compiles the above test as:
    
    | 0000000000000000 <foo>:
    |    0:   f9400407        ldr     x7, [x0, #8]
    |    4:   d503233f        paciasp
    |    8:   aa0003e4        mov     x4, x0
    |    c:   1400000f        b       48 <foo+0x48>
    |   10:   d2800240        mov     x0, #0x12                       // #18
    |   14:   d2800681        mov     x1, #0x34                       // #52
    |   18:   aa0003e5        mov     x5, x0
    |   1c:   aa0103e6        mov     x6, x1
    |   20:   d2800ac2        mov     x2, #0x56                       // #86
    |   24:   d2800f03        mov     x3, #0x78                       // #120
    |   28:   48207c82        casp    x0, x1, x2, x3, [x4]
    |   2c:   ca050000        eor     x0, x0, x5
    |   30:   ca060021        eor     x1, x1, x6
    |   34:   aa010000        orr     x0, x0, x1
    |   38:   f9400480        ldr     x0, [x4, #8]
    |   3c:   d50323bf        autiasp
    |   40:   ca0000e0        eor     x0, x7, x0
    |   44:   d65f03c0        ret
    |   48:   d2800240        mov     x0, #0x12                       // #18
    |   4c:   d2800681        mov     x1, #0x34                       // #52
    |   50:   d2800ac2        mov     x2, #0x56                       // #86
    |   54:   d2800f03        mov     x3, #0x78                       // #120
    |   58:   f9800091        prfm    pstl1strm, [x4]
    |   5c:   c87f1885        ldxp    x5, x6, [x4]
    |   60:   ca0000a5        eor     x5, x5, x0
    |   64:   ca0100c6        eor     x6, x6, x1
    |   68:   aa0600a6        orr     x6, x5, x6
    |   6c:   b5000066        cbnz    x6, 78 <foo+0x78>
    |   70:   c8250c82        stxp    w5, x2, x3, [x4]
    |   74:   35ffff45        cbnz    w5, 5c <foo+0x5c>
    |   78:   f9400480        ldr     x0, [x4, #8]
    |   7c:   d50323bf        autiasp
    |   80:   ca0000e0        eor     x0, x7, x0
    |   84:   d65f03c0        ret
    
    ... sampling the high 8 bytes before and after the cmpxchg, and
    performing an EOR, as we'd expect.
    
    For backporting, I've tested this atop linux-4.9.y with GCC 5.5.0. Note
    that linux-4.9.y is oldest currently supported stable release, and
    mandates GCC 5.1+. Unfortunately I couldn't get a GCC 5.1 binary to run
    on my machines due to library incompatibilities.
    
    I've also used a standalone test to check that we can use a __uint128_t
    pointer in a +Q constraint at least as far back as GCC 4.8.5 and LLVM
    3.9.1.
    
    Fixes: 5284e1b4bc8a ("arm64: xchg: Implement cmpxchg_double")
    Fixes: e9a4b795652f ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU")
    Reported-by: Boqun Feng <boqun.feng@gmail.com>
    Link: https://lore.kernel.org/lkml/Y6DEfQXymYVgL3oJ@boqun-archlinux/
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/lkml/Y6GXoO4qmH9OIZ5Q@hirez.programming.kicks-ass.net/
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: stable@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Steve Capper <steve.capper@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20230104151626.3262137-1-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: qcom: lpass-cpu: Fix fallback SD line index handling [+ + +]
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Fri Dec 30 22:15:45 2022 -0800

    ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
    
    commit 000bca8d706d1bf7cca01af75787247c5a2fdedf upstream.
    
    These indices should reference the ID placed within the dai_driver
    array, not the indices of the array itself.
    
    This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
    lines configurable"), which among others, broke IPQ8064 audio
    (sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
    initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
    at ID 0.
    
    Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines configurable")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20221231061545.2110253-1-computersforpeace@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: wm8904: fix wrong outputs volume after power reactivation [+ + +]
Author: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Date:   Fri Dec 23 09:02:47 2022 +0100

    ASoC: wm8904: fix wrong outputs volume after power reactivation
    
    [ Upstream commit 472a6309c6467af89dbf660a8310369cc9cb041f ]
    
    Restore volume after charge pump and PGA activation to ensure
    that volume settings are correctly applied when re-enabling codec
    from SND_SOC_BIAS_OFF state.
    CLASS_W, CHARGE_PUMP and POWER_MANAGEMENT_2 register configuration
    affect how the volume register are applied and must be configured first.
    
    Fixes: a91eb199e4dc ("ASoC: Initial WM8904 CODEC driver")
    Link: https://lore.kernel.org/all/c7864c35-738c-a867-a6a6-ddf9f98df7e7@gmail.com/
    Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20221223080247.7258-1-francesco@dolcini.it
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bus: mhi: host: Fix race between channel preparation and M0 event [+ + +]
Author: Qiang Yu <quic_qianyu@quicinc.com>
Date:   Sun Oct 16 11:05:32 2022 +0800

    bus: mhi: host: Fix race between channel preparation and M0 event
    
    [ Upstream commit 869a99907faea6d1835b0bd0d0422ae3519c6ea9 ]
    
    There is a race condition where mhi_prepare_channel() updates the
    read and write pointers as the base address and in parallel, if
    an M0 transition occurs, the tasklet goes ahead and rings
    doorbells for all channels with a delta in TRE rings assuming
    they are already enabled. This causes a null pointer access. Fix
    it by adding a channel enabled check before ringing channel
    doorbells.
    
    Cc: stable@vger.kernel.org # 5.19
    Fixes: a6e2e3522f29 "bus: mhi: core: Add support for PM state transitions"
    Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Link: https://lore.kernel.org/r/1665889532-13634-1-git-send-email-quic_qianyu@quicinc.com
    [mani: CCed stable list]
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: Fix uninitialized memory read for smb311 posix symlink create [+ + +]
Author: Volker Lendecke <vl@samba.org>
Date:   Wed Jan 11 12:37:58 2023 +0100

    cifs: Fix uninitialized memory read for smb311 posix symlink create
    
    commit a152d05ae4a71d802d50cf9177dba34e8bb09f68 upstream.
    
    If smb311 posix is enabled, we send the intended mode for file
    creation in the posix create context. Instead of using what's there on
    the stack, create the mfsymlink file with 0644.
    
    Fixes: ce558b0e17f8a ("smb3: Add posix create context for smb3.11 posix mounts")
    Cc: stable@vger.kernel.org
    Signed-off-by: Volker Lendecke <vl@samba.org>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clk: imx8mp: add clkout1/2 support [+ + +]
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Wed Apr 27 18:21:31 2022 +0200

    clk: imx8mp: add clkout1/2 support
    
    [ Upstream commit 43896f56b59eeaf08687fa976257ae7083d01b41 ]
    
    clkout1 and clkout2 allow to supply clocks from the SoC to the board,
    which is used by some board designs to provide reference clocks.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
    Link: https://lore.kernel.org/r/20220427162131.3127303-1-l.stach@pengutronix.de
    Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
    Stable-dep-of: 5c1f7f109094 ("dt-bindings: clocks: imx8mp: Add ID for usb suspend clock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx8mp: Add DISP2 pixel clock [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Sun Mar 13 13:39:49 2022 +0100

    clk: imx8mp: Add DISP2 pixel clock
    
    [ Upstream commit 39772efd98adecbd5b8c6096d465d2fcbafbde6a ]
    
    Add pixel clock for second LCDIFv3 interface. Both LCDIFv3 interfaces use
    the same set of parent clock, so deduplicate imx8mp_media_disp1_pix_sels
    into common imx8mp_media_disp_pix_sels and use it for both.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Abel Vesa <abel.vesa@nxp.com>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: Peng Fan <peng.fan@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
    Link: https://lore.kernel.org/r/20220313123949.207284-1-marex@denx.de
    Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
    Stable-dep-of: 5c1f7f109094 ("dt-bindings: clocks: imx8mp: Add ID for usb suspend clock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: imx8mp: add shared clk gate for usb suspend clk [+ + +]
Author: Li Jun <jun.li@nxp.com>
Date:   Fri Sep 30 22:54:22 2022 +0800

    clk: imx: imx8mp: add shared clk gate for usb suspend clk
    
    [ Upstream commit ed1f4ccfe947a3e1018a3bd7325134574c7ff9b3 ]
    
    32K usb suspend clock gate is shared with usb_root_clk, this
    shared clock gate was initially defined only for usb suspend
    clock, usb suspend clk is kept on while system is active or
    system sleep with usb wakeup enabled, so usb root clock is
    fine with this situation; with the commit cf7f3f4fa9e5
    ("clk: imx8mp: fix usb_root_clk parent"), this clock gate is
    changed to be for usb root clock, but usb root clock will
    be off while usb is suspended, so usb suspend clock will be
    gated too, this cause some usb functionalities will not work,
    so define this clock to be a shared clock gate to conform with
    the real HW status.
    
    Fixes: 9c140d9926761 ("clk: imx: Add support for i.MX8MP clock driver")
    Cc: stable@vger.kernel.org # v5.19+
    Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/1664549663-20364-2-git-send-email-jun.li@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
docs: Fix the docs build with Sphinx 6.0 [+ + +]
Author: Jonathan Corbet <corbet@lwn.net>
Date:   Wed Jan 4 10:47:39 2023 -0700

    docs: Fix the docs build with Sphinx 6.0
    
    commit 0283189e8f3d0917e2ac399688df85211f48447b upstream.
    
    Sphinx 6.0 removed the execfile_() function, which we use as part of the
    configuration process.  They *did* warn us...  Just open-code the
    functionality as is done in Sphinx itself.
    
    Tested (using SPHINX_CONF, since this code is only executed with an
    alternative config file) on various Sphinx versions from 2.5 through 6.0.
    
    Reported-by: Martin Liška <mliska@suse.cz>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Documentation: KVM: add API issues section [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Mar 22 12:07:12 2022 +0100

    Documentation: KVM: add API issues section
    
    [ Upstream commit cde363ab7ca7aea7a853851cd6a6745a9e1aaf5e ]
    
    Add a section to document all the different ways in which the KVM API sucks.
    
    I am sure there are way more, give people a place to vent so that userspace
    authors are aware.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Message-Id: <20220322110712.222449-4-pbonzini@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/adreno: Make adreno quirks not overwrite each other [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jan 2 11:02:00 2023 +0100

    drm/msm/adreno: Make adreno quirks not overwrite each other
    
    commit 13ef096e342b00e30b95a90c6c13eee1f0bec4c5 upstream.
    
    So far the adreno quirks have all been assigned with an OR operator,
    which is problematic, because they were assigned consecutive integer
    values, which makes checking them with an AND operator kind of no bueno..
    
    Switch to using BIT(n) so that only the quirks that the programmer chose
    are taken into account when evaluating info->quirks & ADRENO_QUIRK_...
    
    Fixes: 370063ee427a ("drm/msm/adreno: Add A540 support")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/516456/
    Link: https://lore.kernel.org/r/20230102100201.77286-1-konrad.dybcio@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer [+ + +]
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Tue Dec 27 18:16:24 2022 -0800

    drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
    
    commit 1cba0d150fa102439114a91b3e215909efc9f169 upstream.
    
    There are 3 possible interrupt sources are handled by DP controller,
    HPDstatus, Controller state changes and Aux read/write transaction.
    At every irq, DP controller have to check isr status of every interrupt
    sources and service the interrupt if its isr status bits shows interrupts
    are pending. There is potential race condition may happen at current aux
    isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
    even irq is not for aux read or write transaction. This may cause aux read
    transaction return premature if host aux data read is in the middle of
    waiting for sink to complete transferring data to host while irq happen.
    This will cause host's receiving buffer contains unexpected data. This
    patch fixes this problem by checking aux isr and return immediately at
    aux isr handler if there are no any isr status bits set.
    
    Current there is a bug report regrading eDP edid corruption happen during
    system booting up. After lengthy debugging to found that VIDEO_READY
    interrupt was continuously firing during system booting up which cause
    dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
    from aux hardware buffer which is not yet contains complete data transfer
    from sink. This cause edid corruption.
    
    Follows are the signature at kernel logs when problem happen,
    EDID has corrupt header
    panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID
    
    Changes in v2:
    -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()
    -- add more commit text
    
    Changes in v3:
    -- add Stephen suggested
    -- dp_aux_isr() return IRQ_XXX back to caller
    -- dp_ctrl_isr() return IRQ_XXX back to caller
    
    Changes in v4:
    -- split into two patches
    
    Changes in v5:
    -- delete empty line between tags
    
    Changes in v6:
    -- remove extra "that" and fixed line more than 75 char at commit text
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/516121/
    Link: https://lore.kernel.org/r/1672193785-11003-2-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/virtio: Fix GEM handle creation UAF [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Fri Dec 16 15:33:55 2022 -0800

    drm/virtio: Fix GEM handle creation UAF
    
    [ Upstream commit 52531258318ed59a2dc5a43df2eaf0eb1d65438e ]
    
    Userspace can guess the handle value and try to race GEM object creation
    with handle close, resulting in a use-after-free if we dereference the
    object after dropping the handle's reference.  For that reason, dropping
    the handle's reference must be done *after* we are done dereferencing
    the object.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
    Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: clocks: imx8mp: Add ID for usb suspend clock [+ + +]
Author: Li Jun <jun.li@nxp.com>
Date:   Fri Sep 30 22:54:21 2022 +0800

    dt-bindings: clocks: imx8mp: Add ID for usb suspend clock
    
    [ Upstream commit 5c1f7f1090947d494c30042123e0ec846f696336 ]
    
    usb suspend clock has a gate shared with usb_root_clk.
    
    Fixes: 9c140d9926761 ("clk: imx: Add support for i.MX8MP clock driver")
    Cc: stable@vger.kernel.org # v5.19+
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/1664549663-20364-1-git-send-email-jun.li@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/device: Fix period calculation in edac_device_reset_delay_period() [+ + +]
Author: Eliav Farber <farbere@amazon.com>
Date:   Thu Oct 20 12:44:58 2022 +0000

    EDAC/device: Fix period calculation in edac_device_reset_delay_period()
    
    commit e84077437902ec99eba0a6b516df772653f142c7 upstream.
    
    Fix period calculation in case user sets a value of 1000.  The input of
    round_jiffies_relative() should be in jiffies and not in milli-seconds.
    
      [ bp: Use the same code pattern as in edac_device_workq_setup() for
        clarity. ]
    
    Fixes: c4cf3b454eca ("EDAC: Rework workqueue handling")
    Signed-off-by: Eliav Farber <farbere@amazon.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20221020124458.22153-1-farbere@amazon.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
efi: fix NULL-deref in init error path [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Dec 19 10:10:04 2022 +0100

    efi: fix NULL-deref in init error path
    
    [ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ]
    
    In cases where runtime services are not supported or have been disabled,
    the runtime services workqueue will never have been allocated.
    
    Do not try to destroy the workqueue unconditionally in the unlikely
    event that EFI initialisation fails to avoid dereferencing a NULL
    pointer.
    
    Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails")
    Cc: stable@vger.kernel.org
    Cc: Li Heng <liheng40@huawei.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

efi: tpm: Avoid READ_ONCE() for accessing the event log [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Jan 9 10:44:31 2023 +0100

    efi: tpm: Avoid READ_ONCE() for accessing the event log
    
    commit d3f450533bbcb6dd4d7d59cadc9b61b7321e4ac1 upstream.
    
    Nathan reports that recent kernels built with LTO will crash when doing
    EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a
    misaligned load from the TPM event log, which is annotated with
    READ_ONCE(), and under LTO, this gets translated into a LDAR instruction
    which does not tolerate misaligned accesses.
    
    Interestingly, this does not happen when booting the same kernel
    straight from the UEFI shell, and so the fact that the event log may
    appear misaligned in memory may be caused by a bug in GRUB or SHIM.
    
    However, using READ_ONCE() to access firmware tables is slightly unusual
    in any case, and here, we only need to ensure that 'event' is not
    dereferenced again after it gets unmapped, but this is already taken
    care of by the implicit barrier() semantics of the early_memunmap()
    call.
    
    Cc: <stable@vger.kernel.org>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Jarkko Sakkinen <jarkko@kernel.org>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1782
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ext4: fix uninititialized value in 'ext4_evict_inode' [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Nov 17 15:36:03 2022 +0800

    ext4: fix uninititialized value in 'ext4_evict_inode'
    
    [ Upstream commit 7ea71af94eaaaf6d9aed24bc94a05b977a741cb9 ]
    
    Syzbot found the following issue:
    =====================================================
    BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180
     ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180
     evict+0x365/0x9a0 fs/inode.c:664
     iput_final fs/inode.c:1747 [inline]
     iput+0x985/0xdd0 fs/inode.c:1773
     __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361
     ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844
     vfs_mknod+0x79d/0x830 fs/namei.c:3914
     do_mknodat+0x47d/0xaa0
     __do_sys_mknodat fs/namei.c:3992 [inline]
     __se_sys_mknodat fs/namei.c:3989 [inline]
     __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989
     do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
     __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
     do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
     entry_SYSENTER_compat_after_hwframe+0x70/0x82
    
    Uninit was created at:
     __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578
     alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285
     alloc_slab_page mm/slub.c:1794 [inline]
     allocate_slab+0x1b5/0x1010 mm/slub.c:1939
     new_slab mm/slub.c:1992 [inline]
     ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180
     __slab_alloc mm/slub.c:3279 [inline]
     slab_alloc_node mm/slub.c:3364 [inline]
     slab_alloc mm/slub.c:3406 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
     kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429
     alloc_inode_sb include/linux/fs.h:3117 [inline]
     ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321
     alloc_inode+0x83/0x440 fs/inode.c:259
     new_inode_pseudo fs/inode.c:1018 [inline]
     new_inode+0x3b/0x430 fs/inode.c:1046
     __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959
     ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992
     vfs_mkdir+0x62a/0x870 fs/namei.c:4035
     do_mkdirat+0x466/0x7b0 fs/namei.c:4060
     __do_sys_mkdirat fs/namei.c:4075 [inline]
     __se_sys_mkdirat fs/namei.c:4073 [inline]
     __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073
     do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
     __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
     do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
     entry_SYSENTER_compat_after_hwframe+0x70/0x82
    
    CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    =====================================================
    
    Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed
    before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after
    6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which
    will lead to access uninit-value.
    To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.
    
    Reported-by: syzbot+57b25da729eb0b88177d@syzkaller.appspotmail.com
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Fixes: 6bc0d63dad7f ("ext4: remove EA inode entry from mbcache on inode eviction")
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20221117073603.2598882-1-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hvc/xen: lock console list traversal [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Nov 30 17:36:02 2022 +0100

    hvc/xen: lock console list traversal
    
    [ Upstream commit c0dccad87cf68fc6012aec7567e354353097ec1a ]
    
    The currently lockless access to the xen console list in
    vtermno_to_xencons() is incorrect, as additions and removals from the
    list can happen anytime, and as such the traversal of the list to get
    the private console data for a given termno needs to happen with the
    lock held.  Note users that modify the list already do so with the
    lock taken.
    
    Adjust current lock takers to use the _irq{save,restore} helpers,
    since the context in which vtermno_to_xencons() is called can have
    interrupts disabled.  Use the _irq{save,restore} set of helpers to
    switch the current callers to disable interrupts in the locked region.
    I haven't checked if existing users could instead use the _irq
    variant, as I think it's safer to use _irq{save,restore} upfront.
    
    While there switch from using list_for_each_entry_safe to
    list_for_each_entry: the current entry cursor won't be removed as
    part of the code in the loop body, so using the _safe variant is
    pointless.
    
    Fixes: 02e19f9c7cac ('hvc_xen: implement multiconsole support')
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/20221130163611.14686-1-roger.pau@citrix.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/io-wq: free worker if task_work creation is canceled [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 2 16:49:46 2023 -0700

    io_uring/io-wq: free worker if task_work creation is canceled
    
    commit af82425c6a2d2f347c79b63ce74fca6dc6be157f upstream.
    
    If we cancel the task_work, the worker will never come into existance.
    As this is the last reference to it, ensure that we get it freed
    appropriately.
    
    Cc: stable@vger.kernel.org
    Reported-by: 진호 <wnwlsgh98@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring/io-wq: only free worker if it was allocated for creation [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Jan 8 10:39:17 2023 -0700

    io_uring/io-wq: only free worker if it was allocated for creation
    
    commit e6db6f9398dadcbc06318a133d4c44a2d3844e61 upstream.
    
    We have two types of task_work based creation, one is using an existing
    worker to setup a new one (eg when going to sleep and we have no free
    workers), and the other is allocating a new worker. Only the latter
    should be freed when we cancel task_work creation for a new worker.
    
    Fixes: af82425c6a2d ("io_uring/io-wq: free worker if task_work creation is canceled")
    Reported-by: syzbot+d56ec896af3637bdb7e4@syzkaller.appspotmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/amd: Add PCI segment support for ivrs_[ioapic/hpet/acpihid] commands [+ + +]
Author: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Date:   Wed Jul 6 17:08:22 2022 +0530

    iommu/amd: Add PCI segment support for ivrs_[ioapic/hpet/acpihid] commands
    
    [ Upstream commit bbe3a106580c21bc883fb0c9fa3da01534392fe8 ]
    
    By default, PCI segment is zero and can be omitted. To support system
    with non-zero PCI segment ID, modify the parsing functions to allow
    PCI segment ID.
    
    Co-developed-by: Vasant Hegde <vasant.hegde@amd.com>
    Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Link: https://lore.kernel.org/r/20220706113825.25582-33-vasant.hegde@amd.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: 1198d2316dc4 ("iommu/amd: Fix ill-formed ivrs_ioapic, ivrs_hpet and ivrs_acpihid options")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/amd: Fix ill-formed ivrs_ioapic, ivrs_hpet and ivrs_acpihid options [+ + +]
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Mon Sep 19 10:56:38 2022 -0500

    iommu/amd: Fix ill-formed ivrs_ioapic, ivrs_hpet and ivrs_acpihid options
    
    [ Upstream commit 1198d2316dc4265a97d0e8445a22c7a6d17580a4 ]
    
    Currently, these options cause the following libkmod error:
    
    libkmod: ERROR ../libkmod/libkmod-config.c:489 kcmdline_parse_result: \
            Ignoring bad option on kernel command line while parsing module \
            name: 'ivrs_xxxx[XX:XX'
    
    Fix by introducing a new parameter format for these options and
    throw a warning for the deprecated format.
    
    Users are still allowed to omit the PCI Segment if zero.
    
    Adding a Link: to the reason why we're modding the syntax parsing
    in the driver and not in libkmod.
    
    Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/linux-modules/20200310082308.14318-2-lucas.demarchi@intel.com/
    Reported-by: Kim Phillips <kim.phillips@amd.com>
    Co-developed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Link: https://lore.kernel.org/r/20220919155638.391481-2-kim.phillips@amd.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/mediatek-v1: Add error handle for mtk_iommu_probe [+ + +]
Author: Yong Wu <yong.wu@mediatek.com>
Date:   Mon Apr 12 14:48:43 2021 +0800

    iommu/mediatek-v1: Add error handle for mtk_iommu_probe
    
    [ Upstream commit ac304c070c54413efabf29f9e73c54576d329774 ]
    
    In the original code, we lack the error handle. This patch adds them.
    
    Signed-off-by: Yong Wu <yong.wu@mediatek.com>
    Link: https://lore.kernel.org/r/20210412064843.11614-2-yong.wu@mediatek.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: 142e821f68cf ("iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Dec 19 19:06:22 2022 +0100

    iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe()
    
    [ Upstream commit 142e821f68cf5da79ce722cb9c1323afae30e185 ]
    
    A clk, prepared and enabled in mtk_iommu_v1_hw_init(), is not released in
    the error handling path of mtk_iommu_v1_probe().
    
    Add the corresponding clk_disable_unprepare(), as already done in the
    remove function.
    
    Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Yong Wu <yong.wu@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Link: https://lore.kernel.org/r/593e7b7d97c6e064b29716b091a9d4fd122241fb.1671473163.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: raw: Deduct extension header length in rawv6_push_pending_frames [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jan 10 08:59:06 2023 +0800

    ipv6: raw: Deduct extension header length in rawv6_push_pending_frames
    
    commit cb3e9864cdbe35ff6378966660edbcbac955fe17 upstream.
    
    The total cork length created by ip6_append_data includes extension
    headers, so we must exclude them when comparing them against the
    IPV6_CHECKSUM offset which does not include extension headers.
    
    Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
    Fixes: 357b40a18b04 ("[IPV6]: IPV6_CHECKSUM socket option can corrupt kernel memory")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ixgbe: fix pci device refcount leak [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 29 09:57:48 2022 +0800

    ixgbe: fix pci device refcount leak
    
    commit b93fb4405fcb5112c5739c5349afb52ec7f15c07 upstream.
    
    As the comment of pci_get_domain_bus_and_slot() says, it
    returns a PCI device with refcount incremented, when finish
    using it, the caller must decrement the reference count by
    calling pci_dev_put().
    
    In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
    pci_dev_put() is called to avoid leak.
    
    Fixes: 8fa10ef01260 ("ixgbe: register a mdiobus")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: arm64: Fix S1PTW handling on RO memslots [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Dec 20 14:03:52 2022 +0000

    KVM: arm64: Fix S1PTW handling on RO memslots
    
    commit 406504c7b0405d74d74c15a667cd4c4620c3e7a9 upstream.
    
    A recent development on the EFI front has resulted in guests having
    their page tables baked in the firmware binary, and mapped into the
    IPA space as part of a read-only memslot. Not only is this legitimate,
    but it also results in added security, so thumbs up.
    
    It is possible to take an S1PTW translation fault if the S1 PTs are
    unmapped at stage-2. However, KVM unconditionally treats S1PTW as a
    write to correctly handle hardware AF/DB updates to the S1 PTs.
    Furthermore, KVM injects an exception into the guest for S1PTW writes.
    In the aforementioned case this results in the guest taking an abort
    it won't recover from, as the S1 PTs mapping the vectors suffer from
    the same problem.
    
    So clearly our handling is... wrong.
    
    Instead, switch to a two-pronged approach:
    
    - On S1PTW translation fault, handle the fault as a read
    
    - On S1PTW permission fault, handle the fault as a write
    
    This is of no consequence to SW that *writes* to its PTs (the write
    will trigger a non-S1PTW fault), and SW that uses RO PTs will not
    use HW-assisted AF/DB anyway, as that'd be wrong.
    
    Only in the case described in c4ad98e4b72c ("KVM: arm64: Assume write
    fault on S1PTW permission fault on instruction fetch") do we end-up
    with two back-to-back faults (page being evicted and faulted back).
    I don't think this is a case worth optimising for.
    
    Fixes: c4ad98e4b72c ("KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch")
    Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Regression-tested-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Sat Oct 22 04:17:53 2022 -0400

    KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID
    
    [ Upstream commit 45e966fcca03ecdcccac7cb236e16eea38cc18af ]
    
    Passing the host topology to the guest is almost certainly wrong
    and will confuse the scheduler.  In addition, several fields of
    these CPUID leaves vary on each processor; it is simply impossible to
    return the right values from KVM_GET_SUPPORTED_CPUID in such a way that
    they can be passed to KVM_SET_CPUID2.
    
    The values that will most likely prevent confusion are all zeroes.
    Userspace will have to override it anyway if it wishes to present a
    specific topology to the guest.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.10.164 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 18 11:45:02 2023 +0100

    Linux 5.10.164
    
    Link: https://lore.kernel.org/r/20230116154743.577276578@linuxfoundation.org
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Link: https://lore.kernel.org/r/20230117124526.766388541@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: Always release pages to the buddy allocator in memblock_free_late(). [+ + +]
Author: Aaron Thompson <dev@aaront.org>
Date:   Fri Jan 6 22:22:44 2023 +0000

    mm: Always release pages to the buddy allocator in memblock_free_late().
    
    [ Upstream commit 115d9d77bb0f9152c60b6e8646369fa7f6167593 ]
    
    If CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled, memblock_free_pages()
    only releases pages to the buddy allocator if they are not in the
    deferred range. This is correct for free pages (as defined by
    for_each_free_mem_pfn_range_in_zone()) because free pages in the
    deferred range will be initialized and released as part of the deferred
    init process. memblock_free_pages() is called by memblock_free_late(),
    which is used to free reserved ranges after memblock_free_all() has
    run. All pages in reserved ranges have been initialized at that point,
    and accordingly, those pages are not touched by the deferred init
    process. This means that currently, if the pages that
    memblock_free_late() intends to release are in the deferred range, they
    will never be released to the buddy allocator. They will forever be
    reserved.
    
    In addition, memblock_free_pages() calls kmsan_memblock_free_pages(),
    which is also correct for free pages but is not correct for reserved
    pages. KMSAN metadata for reserved pages is initialized by
    kmsan_init_shadow(), which runs shortly before memblock_free_all().
    
    For both of these reasons, memblock_free_pages() should only be called
    for free pages, and memblock_free_late() should call __free_pages_core()
    directly instead.
    
    One case where this issue can occur in the wild is EFI boot on
    x86_64. The x86 EFI code reserves all EFI boot services memory ranges
    via memblock_reserve() and frees them later via memblock_free_late()
    (efi_reserve_boot_services() and efi_free_boot_services(),
    respectively). If any of those ranges happens to fall within the
    deferred init range, the pages will not be released and that memory will
    be unavailable.
    
    For example, on an Amazon EC2 t3.micro VM (1 GB) booting via EFI:
    
    v6.2-rc2:
      # grep -E 'Node|spanned|present|managed' /proc/zoneinfo
      Node 0, zone      DMA
              spanned  4095
              present  3999
              managed  3840
      Node 0, zone    DMA32
              spanned  246652
              present  245868
              managed  178867
    
    v6.2-rc2 + patch:
      # grep -E 'Node|spanned|present|managed' /proc/zoneinfo
      Node 0, zone      DMA
              spanned  4095
              present  3999
              managed  3840
      Node 0, zone    DMA32
              spanned  246652
              present  245868
              managed  222816   # +43,949 pages
    
    Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set")
    Signed-off-by: Aaron Thompson <dev@aaront.org>
    Link: https://lore.kernel.org/r/01010185892de53e-e379acfb-7044-4b24-b30a-e2657c1ba989-000000@us-west-2.amazonses.com
    Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Fix ptp max frequency adjustment range [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Mon Dec 5 14:26:09 2022 -0800

    net/mlx5: Fix ptp max frequency adjustment range
    
    [ Upstream commit fe91d57277eef8bb4aca05acfa337b4a51d0bba4 ]
    
    .max_adj of ptp_clock_info acts as an absolute value for the amount in ppb
    that can be set for a single call of .adjfine. This means that a single
    call to .getfine cannot be greater than .max_adj or less than -(.max_adj).
    Provides correct value for max frequency adjustment value supported by
    devices.
    
    Fixes: 3d8c38af1493 ("net/mlx5e: Add PTP Hardware Clock (PHC) support")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Don't support encap rules with gbp option [+ + +]
Author: Gavin Li <gavinl@nvidia.com>
Date:   Tue Dec 27 04:54:09 2022 +0200

    net/mlx5e: Don't support encap rules with gbp option
    
    [ Upstream commit d515d63cae2cd186acf40deaa8ef33067bb7f637 ]
    
    Previously, encap rules with gbp option would be offloaded by mistake but
    driver does not support gbp option offload.
    
    To fix this issue, check if the encap rule has gbp option and don't
    offload the rule
    
    Fixes: d8f9dfae49ce ("net: sched: allow flower to match vxlan options")
    Signed-off-by: Gavin Li <gavinl@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_mpls: Fix warning during failed attribute validation [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Sat Jan 7 19:10:04 2023 +0200

    net/sched: act_mpls: Fix warning during failed attribute validation
    
    [ Upstream commit 9e17f99220d111ea031b44153fdfe364b0024ff2 ]
    
    The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
    validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
    combination according to the comment above 'struct nla_policy':
    
    "
    Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
       NLA_BINARY           Validation function called for the attribute.
       All other            Unused - but note that it's a union
    "
    
    This can trigger the warning [1] in nla_get_range_unsigned() when
    validation of the attribute fails. Despite being of 'NLA_U32' type, the
    associated 'min'/'max' fields in the policy are negative as they are
    aliased by the 'validate' field.
    
    Fix by changing the attribute type to 'NLA_BINARY' which is consistent
    with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
    As a result, move the length validation to the validation function.
    
    No regressions in MPLS tests:
    
     # ./tdc.py -f tc-tests/actions/mpls.json
     [...]
     # echo $?
     0
    
    [1]
    WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
    nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
    Modules linked in:
    CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
    RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
    [...]
    Call Trace:
     <TASK>
     __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
     netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
     netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
     netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
     netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
     rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg net/socket.c:734 [inline]
     ____sys_sendmsg+0x38f/0x500 net/socket.c:2482
     ___sys_sendmsg net/socket.c:2536 [inline]
     __sys_sendmsg+0x197/0x230 net/socket.c:2565
     __do_sys_sendmsg net/socket.c:2574 [inline]
     __se_sys_sendmsg net/socket.c:2572 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Link: https://lore.kernel.org/netdev/CAO4mrfdmjvRUNbDyP0R03_DrD_eFCLCguz6OxZ2TYRSv0K9gxA@mail.gmail.com/
    Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
    Reported-by: Wei Chen <harperchen1110@gmail.com>
    Tested-by: Wei Chen <harperchen1110@gmail.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/20230107171004.608436-1-idosch@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function. [+ + +]
Author: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Date:   Wed Jan 11 11:57:39 2023 +0000

    netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.
    
    commit 9ea4b476cea1b7d461d16dda25ca3c7e616e2d15 upstream.
    
    When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of
    an arithmetic expression 2 << (netmask - mask_bits - 1) is subject
    to overflow due to a failure casting operands to a larger data type
    before performing the arithmetic.
    
    Note that it's harmless since the value will be checked at the next step.
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: b9fed748185a ("netfilter: ipset: Check and reject crazy /0 input parameters")
    Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jan 11 17:07:33 2023 +0100

    netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits
    
    commit 696e1a48b1a1b01edad542a1ef293665864a4dd0 upstream.
    
    If the offset + length goes over the ethernet + vlan header, then the
    length is adjusted to copy the bytes that are within the boundaries of
    the vlan_ethhdr scratchpad area. The remaining bytes beyond ethernet +
    vlan header are copied directly from the skbuff data area.
    
    Fix incorrect arithmetic operator: subtract, not add, the size of the
    vlan header in case of double-tagged packets to adjust the length
    accordingly to address CVE-2023-0179.
    
    Reported-by: Davide Ornaghi <d.ornaghi97@gmail.com>
    Fixes: f6ae9f120dad ("netfilter: nft_payload: add C-VLAN support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() [+ + +]
Author: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Date:   Fri Jan 6 17:23:44 2023 +0900

    nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
    
    [ Upstream commit 9dab880d675b9d0dd56c6428e4e8352a3339371d ]
    
    Fix a use-after-free that occurs in hcd when in_urb sent from
    pn533_usb_send_frame() is completed earlier than out_urb. Its callback
    frees the skb data in pn533_send_async_complete() that is used as a
    transfer buffer of out_urb. Wait before sending in_urb until the
    callback of out_urb is called. To modify the callback of out_urb alone,
    separate the complete function of out_urb and ack_urb.
    
    Found by a modified version of syzkaller.
    
    BUG: KASAN: use-after-free in dummy_timer
    Call Trace:
     memcpy (mm/kasan/shadow.c:65)
     dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
     transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
     dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
     arch_static_branch (arch/x86/include/asm/jump_label.h:27)
     static_key_false (include/linux/jump_label.h:207)
     timer_expire_exit (include/trace/events/timer.h:127)
     call_timer_fn (kernel/time/timer.c:1475)
     expire_timers (kernel/time/timer.c:1519)
     __run_timers (kernel/time/timer.c:1790)
     run_timer_softirq (kernel/time/timer.c:1803)
    
    Fixes: c46ee38620a2 ("NFC: pn533: add NXP pn533 nfc device driver")
    Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable [+ + +]
Author: Angela Czubak <aczubak@marvell.com>
Date:   Thu Jan 5 21:31:07 2023 +0530

    octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable
    
    [ Upstream commit b4e9b8763e417db31c7088103cc557d55cb7a8f5 ]
    
    PF netdev can request AF to enable or disable reception and transmission
    on assigned CGX::LMAC. The current code instead of disabling or enabling
    'reception and transmission' also disables/enable the LMAC. This patch
    fixes this issue.
    
    Fixes: 1435f66a28b4 ("octeontx2-af: CGX Rx/Tx enable/disable mbox handlers")
    Signed-off-by: Angela Czubak <aczubak@marvell.com>
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20230105160107.17638-1-hkelam@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: Map NIX block from CGX connection [+ + +]
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Thu Oct 29 10:45:43 2020 +0530

    octeontx2-af: Map NIX block from CGX connection
    
    [ Upstream commit c5a73b632b901c4b07d156bb8a8a2c5517678f35 ]
    
    Firmware configures NIX block mapping for all CGXs
    to achieve maximum throughput. This patch reads
    the configuration and create mapping between RVU
    PF and NIX blocks. And for LBK VFs assign NIX0 for
    even numbered VFs and NIX1 for odd numbered VFs.
    
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: Rakesh Babu <rsaladi2@marvell.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: b4e9b8763e41 ("octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: Update get/set resource count functions [+ + +]
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Thu Oct 29 10:45:40 2020 +0530

    octeontx2-af: Update get/set resource count functions
    
    [ Upstream commit cdd41e878526797df29903fe592d6a26b096ac7d ]
    
    Since multiple blocks of same type are present in
    98xx, modify functions which get resource count and
    which update resource count to work with individual
    block address instead of block type.
    
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: Rakesh Babu <rsaladi2@marvell.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: b4e9b8763e41 ("octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf auxtrace: Fix address filter duplicate symbol selection [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Jan 10 20:56:59 2023 +0200

    perf auxtrace: Fix address filter duplicate symbol selection
    
    commit cf129830ee820f7fc90b98df193cd49d49344d09 upstream.
    
    When a match has been made to the nth duplicate symbol, return
    success not error.
    
    Example:
    
      Before:
    
        $ cat file.c
        cat: file.c: No such file or directory
        $ cat file1.c
        #include <stdio.h>
    
        static void func(void)
        {
                printf("First func\n");
        }
    
        void other(void);
    
        int main()
        {
                func();
                other();
                return 0;
        }
        $ cat file2.c
        #include <stdio.h>
    
        static void func(void)
        {
                printf("Second func\n");
        }
    
        void other(void)
        {
                func();
        }
    
        $ gcc -Wall -Wextra -o test file1.c file2.c
        $ perf record -e intel_pt//u --filter 'filter func @ ./test' -- ./test
        Multiple symbols with name 'func'
        #1      0x1149  l       func
                        which is near           main
        #2      0x1179  l       func
                        which is near           other
        Disambiguate symbol name by inserting #n after the name e.g. func #2
        Or select a global symbol by inserting #0 or #g or #G
        Failed to parse address filter: 'filter func @ ./test'
        Filter format is: filter|start|stop|tracestop <start symbol or address> [/ <end symbol or size>] [@<file name>]
        Where multiple filters are separated by space or comma.
        $ perf record -e intel_pt//u --filter 'filter func #2 @ ./test' -- ./test
        Failed to parse address filter: 'filter func #2 @ ./test'
        Filter format is: filter|start|stop|tracestop <start symbol or address> [/ <end symbol or size>] [@<file name>]
        Where multiple filters are separated by space or comma.
    
      After:
    
        $ perf record -e intel_pt//u --filter 'filter func #2 @ ./test' -- ./test
        First func
        Second func
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.016 MB perf.data ]
        $ perf script --itrace=b -Ftime,flags,ip,sym,addr --ns
        1231062.526977619:   tr strt                               0 [unknown] =>     558495708179 func
        1231062.526977619:   tr end  call               558495708188 func =>     558495708050 _init
        1231062.526979286:   tr strt                               0 [unknown] =>     55849570818d func
        1231062.526979286:   tr end  return             55849570818f func =>     55849570819d other
    
    Fixes: 1b36c03e356936d6 ("perf record: Add support for using symbols in address filters")
    Reported-by: Dmitrii Dolgov <9erthalion6@gmail.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Dmitry Dolgov <9erthalion6@gmail.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230110185659.15979-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Dec 13 13:29:43 2022 +0100

    platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe
    
    commit ad75bd85b1db69c97eefea07b375567821f6ef58 upstream.
    
    The 0x153 version of the kbd backlight control SNC handle has no separate
    address to probe if the backlight is there.
    
    This turns the probe call into a set keyboard backlight call with a value
    of 0 turning off the keyboard backlight.
    
    Skip probing when there is no separate probe address to avoid this.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1583752
    Fixes: 800f20170dcf ("Keyboard backlight control for some Vaio Fit models")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Mattia Dongili <malattia@linux.it>
    Link: https://lore.kernel.org/r/20221213122943.11123-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section [+ + +]
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Fri Jan 6 12:21:57 2023 +0530

    powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
    
    commit 76d588dddc459fefa1da96e0a081a397c5c8e216 upstream.
    
    Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP
    and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
    
    Command to trigger the warning:
      # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
    
       Performance counter stats for 'sleep 5':
    
                       0      thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
    
             5.002117947 seconds time elapsed
    
             0.000131000 seconds user
             0.001063000 seconds sys
    
    Below is snippet of the warning in dmesg:
    
      BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
      in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec
      preempt_count: 2, expected: 0
      4 locks held by perf-exec/2869:
       #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90
       #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0
       #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510
       #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510
      irq event stamp: 4806
      hardirqs last  enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0
      hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510
      softirqs last  enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0
      softirqs last disabled at (0): [<0000000000000000>] 0x0
      CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61
      Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
      Call Trace:
        dump_stack_lvl+0x98/0xe0 (unreliable)
        __might_resched+0x2f8/0x310
        __mutex_lock+0x6c/0x13f0
        thread_imc_event_add+0xf4/0x1b0
        event_sched_in+0xe0/0x210
        merge_sched_in+0x1f0/0x600
        visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0
        ctx_flexible_sched_in+0xcc/0x140
        ctx_sched_in+0x20c/0x2a0
        ctx_resched+0x104/0x1c0
        perf_event_exec+0x340/0x510
        begin_new_exec+0x730/0xef0
        load_elf_binary+0x3f8/0x1e10
      ...
      do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0
      WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0
      CPU: 36 PID: 2869 Comm: sleep Tainted: G        W          6.2.0-rc2-00011-g1247637727f2 #61
      Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
      NIP:  c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670
      REGS: c00000004d2134e0 TRAP: 0700   Tainted: G        W           (6.2.0-rc2-00011-g1247637727f2)
      MSR:  9000000000021033 <SF,HV,ME,IR,DR,RI,LE>  CR: 48002824  XER: 00000000
      CFAR: c00000000013fb64 IRQMASK: 1
    
    The above warning triggered because the current imc-pmu code uses mutex
    lock in interrupt disabled sections. The function mutex_lock()
    internally calls __might_resched(), which will check if IRQs are
    disabled and in case IRQs are disabled, it will trigger the warning.
    
    Fix the issue by changing the mutex lock to spinlock.
    
    Fixes: 8f95faaac56c ("powerpc/powernv: Detect and create IMC device")
    Reported-by: Michael Petlan <mpetlan@redhat.com>
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    [mpe: Fix comments, trim oops in change log, add reported-by tags]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230106065157.182648-1-kjain@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
regulator: da9211: Use irq handler when ready [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Sun Nov 27 22:06:02 2022 +0100

    regulator: da9211: Use irq handler when ready
    
    [ Upstream commit 02228f6aa6a64d588bc31e3267d05ff184d772eb ]
    
    If the system does not come from reset (like when it is kexec()), the
    regulator might have an IRQ waiting for us.
    
    If we enable the IRQ handler before its structures are ready, we crash.
    
    This patch fixes:
    
    [    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078
    [    1.316096] Call trace:
    [    1.316101]  blocking_notifier_call_chain+0x20/0xa8
    [    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests
    [    1.327823]  regulator_notifier_call_chain+0x1c/0x2c
    [    1.327825]  da9211_irq_handler+0x68/0xf8
    [    1.327829]  irq_thread+0x11c/0x234
    [    1.327833]  kthread+0x13c/0x154
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
    Link: https://lore.kernel.org/r/20221124-da9211-v2-0-1779e3c5d491@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout" [+ + +]
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Thu Dec 22 21:53:02 2022 +0100

    Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout"
    
    commit b659b613cea2ae39746ca8bd2b69d1985dd9d770 upstream.
    
    This reverts commit 8a7b31d545d3a15f0e6f5984ae16f0ca4fd76aac.
    
    This patch results in some qemu test failures, specifically xilinx-zynq-a9
    machine and zynq-zc702 as well as zynq-zed devicetree files, when trying
    to boot from USB drive.
    
    Link: https://lore.kernel.org/lkml/20221220194334.GA942039@roeck-us.net/
    Fixes: 8a7b31d545d3 ("usb: ulpi: defer ulpi_register on ulpi_read_id timeout")
    Cc: stable@vger.kernel.org
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
    Link: https://lore.kernel.org/r/20221222205302.45761-1-ftoth@exalondelft.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Thu Jan 5 15:44:20 2023 +0100

    s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops
    
    commit 82d3edb50a11bf3c5ef63294d5358ba230181413 upstream.
    
    The current cmpxchg_double() loops within the perf hw sampling code do not
    have READ_ONCE() semantics to read the old value from memory. This allows
    the compiler to generate code which reads the "old" value several times
    from memory, which again allows for inconsistencies.
    
    For example:
    
            /* Reset trailer (using compare-double-and-swap) */
            do {
                    te_flags = te->flags & ~SDB_TE_BUFFER_FULL_MASK;
                    te_flags |= SDB_TE_ALERT_REQ_MASK;
            } while (!cmpxchg_double(&te->flags, &te->overflow,
                     te->flags, te->overflow,
                     te_flags, 0ULL));
    
    The compiler could generate code where te->flags used within the
    cmpxchg_double() call may be refetched from memory and which is not
    necessarily identical to the previous read version which was used to
    generate te_flags. Which in turn means that an incorrect update could
    happen.
    
    Fix this by adding READ_ONCE() semantics to all cmpxchg_double()
    loops. Given that READ_ONCE() cannot generate code on s390 which atomically
    reads 16 bytes, use a private compare-and-swap-double implementation to
    achieve that.
    
    Also replace cmpxchg_double() with the private implementation to be able to
    re-use the old value within the loops.
    
    As a side effect this converts the whole code to only use bit fields
    to read and modify bits within the hws trailer header.
    
    Reported-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com>
    Reviewed-by: Thomas Richter <tmricht@linux.ibm.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/linux-s390/Y71QJBhNTIatvxUT@osiris/T/#ma14e2a5f7aa8ed4b94b6f9576799b3ad9c60f333
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/kexec: fix ipl report address for kdump [+ + +]
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Mon Nov 14 11:40:08 2022 +0100

    s390/kexec: fix ipl report address for kdump
    
    commit c2337a40e04dde1692b5b0a46ecc59f89aaba8a1 upstream.
    
    This commit addresses the following erroneous situation with file-based
    kdump executed on a system with a valid IPL report.
    
    On s390, a kdump kernel, its initrd and IPL report if present are loaded
    into a special and reserved on boot memory region - crashkernel. When
    a system crashes and kdump was activated before, the purgatory code
    is entered first which swaps the crashkernel and [0 - crashkernel size]
    memory regions. Only after that the kdump kernel is entered. For this
    reason, the pointer to an IPL report in lowcore must point to the IPL report
    after the swap and not to the address of the IPL report that was located in
    crashkernel memory region before the swap. Failing to do so, makes the
    kdump's decompressor try to read memory from the crashkernel memory region
    which already contains the production's kernel memory.
    
    The situation described above caused spontaneous kdump failures/hangs
    on systems where the Secure IPL is activated because on such systems
    an IPL report is always present. In that case kdump's decompressor tried
    to parse an IPL report which frequently lead to illegal memory accesses
    because an IPL report contains addresses to various data.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel")
    Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple() [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Jan 9 11:51:20 2023 +0100

    s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()
    
    commit e3f360db08d55a14112bd27454e616a24296a8b0 upstream.
    
    Make sure that *ptr__ within arch_this_cpu_to_op_simple() is only
    dereferenced once by using READ_ONCE(). Otherwise the compiler could
    generate incorrect code.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tipc: fix unexpected link reset due to discovery messages [+ + +]
Author: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Date:   Thu Jan 5 06:02:51 2023 +0000

    tipc: fix unexpected link reset due to discovery messages
    
    [ Upstream commit c244c092f1ed2acfb5af3d3da81e22367d3dd733 ]
    
    This unexpected behavior is observed:
    
    node 1                    | node 2
    ------                    | ------
    link is established       | link is established
    reboot                    | link is reset
    up                        | send discovery message
    receive discovery message |
    link is established       | link is established
    send discovery message    |
                              | receive discovery message
                              | link is reset (unexpected)
                              | send reset message
    link is reset             |
    
    It is due to delayed re-discovery as described in function
    tipc_node_check_dest(): "this link endpoint has already reset
    and re-established contact with the peer, before receiving a
    discovery message from that node."
    
    However, commit 598411d70f85 has changed the condition for calling
    tipc_node_link_down() which was the acceptance of new media address.
    
    This commit fixes this by restoring the old and correct behavior.
    
    Fixes: 598411d70f85 ("tipc: make resetting of links non-atomic")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: ulpi: defer ulpi_register on ulpi_read_id timeout [+ + +]
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Mon Dec 5 21:15:26 2022 +0100

    usb: ulpi: defer ulpi_register on ulpi_read_id timeout
    
    [ Upstream commit 8a7b31d545d3a15f0e6f5984ae16f0ca4fd76aac ]
    
    Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral
    if extcon is present") Dual Role support on Intel Merrifield platform
    broke due to rearranging the call to dwc3_get_extcon().
    
    It appears to be caused by ulpi_read_id() on the first test write failing
    with -ETIMEDOUT. Currently ulpi_read_id() expects to discover the phy via
    DT when the test write fails and returns 0 in that case, even if DT does not
    provide the phy. As a result usb probe completes without phy.
    
    Make ulpi_read_id() return -ETIMEDOUT to its user if the first test write
    fails. The user should then handle it appropriately. A follow up patch
    will make dwc3_core_init() set -EPROBE_DEFER in this case and bail out.
    
    Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
    Cc: stable@vger.kernel.org
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
    Link: https://lore.kernel.org/r/20221205201527.13525-2-ftoth@exalondelft.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/boot: Avoid using Intel mnemonics in AT&T syntax asm [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jan 10 12:15:40 2023 +0100

    x86/boot: Avoid using Intel mnemonics in AT&T syntax asm
    
    commit 7c6dd961d0c8e7e8f9fdc65071fb09ece702e18d upstream.
    
    With 'GNU assembler (GNU Binutils for Debian) 2.39.90.20221231' the
    build now reports:
    
      arch/x86/realmode/rm/../../boot/bioscall.S: Assembler messages:
      arch/x86/realmode/rm/../../boot/bioscall.S:35: Warning: found `movsd'; assuming `movsl' was meant
      arch/x86/realmode/rm/../../boot/bioscall.S:70: Warning: found `movsd'; assuming `movsl' was meant
    
      arch/x86/boot/bioscall.S: Assembler messages:
      arch/x86/boot/bioscall.S:35: Warning: found `movsd'; assuming `movsl' was meant
      arch/x86/boot/bioscall.S:70: Warning: found `movsd'; assuming `movsl' was meant
    
    Which is due to:
    
      PR gas/29525
    
      Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
      templates taking operands, mixed IsString/non-IsString template groups
      (with memory operands) cannot occur anymore. With that
      maybe_adjust_templates() becomes unnecessary (and is hence being
      removed).
    
    More details: https://sourceware.org/bugzilla/show_bug.cgi?id=29525
    
    Borislav Petkov further explains:
    
      " the particular problem here is is that the 'd' suffix is
        "conflicting" in the sense that you can have SSE mnemonics like movsD %xmm...
        and the same thing also for string ops (which is the case here) so apparently
        the agreement in binutils land is to use the always accepted suffixes 'l' or 'q'
        and phase out 'd' slowly... "
    
    Fixes: 7a734e7dd93b ("x86, setup: "glove box" BIOS calls -- infrastructure")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/Y71I3Ex2pvIxMpsP@hirez.programming.kicks-ass.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/resctrl: Fix task CLOSID/RMID update race [+ + +]
Author: Peter Newman <peternewman@google.com>
Date:   Tue Dec 20 17:11:23 2022 +0100

    x86/resctrl: Fix task CLOSID/RMID update race
    
    [ Upstream commit fe1f0714385fbcf76b0cbceb02b7277d842014fc ]
    
    When the user moves a running task to a new rdtgroup using the task's
    file interface or by deleting its rdtgroup, the resulting change in
    CLOSID/RMID must be immediately propagated to the PQR_ASSOC MSR on the
    task(s) CPUs.
    
    x86 allows reordering loads with prior stores, so if the task starts
    running between a task_curr() check that the CPU hoisted before the
    stores in the CLOSID/RMID update then it can start running with the old
    CLOSID/RMID until it is switched again because __rdtgroup_move_task()
    failed to determine that it needs to be interrupted to obtain the new
    CLOSID/RMID.
    
    Refer to the diagram below:
    
    CPU 0                                   CPU 1
    -----                                   -----
    __rdtgroup_move_task():
      curr <- t1->cpu->rq->curr
                                            __schedule():
                                              rq->curr <- t1
                                            resctrl_sched_in():
                                              t1->{closid,rmid} -> {1,1}
      t1->{closid,rmid} <- {2,2}
      if (curr == t1) // false
       IPI(t1->cpu)
    
    A similar race impacts rdt_move_group_tasks(), which updates tasks in a
    deleted rdtgroup.
    
    In both cases, use smp_mb() to order the task_struct::{closid,rmid}
    stores before the loads in task_curr().  In particular, in the
    rdt_move_group_tasks() case, simply execute an smp_mb() on every
    iteration with a matching task.
    
    It is possible to use a single smp_mb() in rdt_move_group_tasks(), but
    this would require two passes and a means of remembering which
    task_structs were updated in the first loop. However, benchmarking
    results below showed too little performance impact in the simple
    approach to justify implementing the two-pass approach.
    
    Times below were collected using `perf stat` to measure the time to
    remove a group containing a 1600-task, parallel workload.
    
    CPU: Intel(R) Xeon(R) Platinum P-8136 CPU @ 2.00GHz (112 threads)
    
      # mkdir /sys/fs/resctrl/test
      # echo $$ > /sys/fs/resctrl/test/tasks
      # perf bench sched messaging -g 40 -l 100000
    
    task-clock time ranges collected using:
    
      # perf stat rmdir /sys/fs/resctrl/test
    
    Baseline:                     1.54 - 1.60 ms
    smp_mb() every matching task: 1.57 - 1.67 ms
    
      [ bp: Massage commit message. ]
    
    Fixes: ae28d1aae48a ("x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR")
    Fixes: 0efc89be9471 ("x86/intel_rdt: Update task closid immediately on CPU in rmdir and unmount")
    Signed-off-by: Peter Newman <peternewman@google.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Babu Moger <babu.moger@amd.com>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20221220161123.432120-1-peternewman@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/resctrl: Use task_curr() instead of task_struct->on_cpu to prevent unnecessary IPI [+ + +]
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Thu Dec 17 14:31:20 2020 -0800

    x86/resctrl: Use task_curr() instead of task_struct->on_cpu to prevent unnecessary IPI
    
    [ Upstream commit e0ad6dc8969f790f14bddcfd7ea284b7e5f88a16 ]
    
    James reported in [1] that there could be two tasks running on the same CPU
    with task_struct->on_cpu set. Using task_struct->on_cpu as a test if a task
    is running on a CPU may thus match the old task for a CPU while the
    scheduler is running and IPI it unnecessarily.
    
    task_curr() is the correct helper to use. While doing so move the #ifdef
    check of the CONFIG_SMP symbol to be a C conditional used to determine
    if this helper should be used to ensure the code is always checked for
    correctness by the compiler.
    
    [1] https://lore.kernel.org/lkml/a782d2f3-d2f6-795f-f4b1-9462205fd581@arm.com
    
    Reported-by: James Morse <james.morse@arm.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/e9e68ce1441a73401e08b641cc3b9a3cf13fe6d4.1608243147.git.reinette.chatre@intel.com
    Stable-dep-of: fe1f0714385f ("x86/resctrl: Fix task CLOSID/RMID update race")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xfrm: fix rcu lock in xfrm_notify_userpolicy() [+ + +]
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Wed Sep 22 10:50:06 2021 +0200

    xfrm: fix rcu lock in xfrm_notify_userpolicy()
    
    commit 93ec1320b0170d7a207eda2d119c669b673401ed upstream.
    
    As stated in the comment above xfrm_nlmsg_multicast(), rcu read lock must
    be held before calling this function.
    
    Reported-by: syzbot+3d9866419b4aa8f985d6@syzkaller.appspotmail.com
    Fixes: 703b94b93c19 ("xfrm: notify default policy on update")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci: Add xhci_reset_halted_ep() helper function [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:32 2021 +0200

    xhci: Add xhci_reset_halted_ep() helper function
    
    [ Upstream commit d8ac95001bea683d2088acb3e61613a27b8d2d5f ]
    
    Create a separate helper function to issue reset endpont commands
    to clear halted endpoints.
    
    This is useful for cases where a halted endpoint is discovered while
    completing another command, and the endpoint halt needs to be cleared
    with a endpoint reset first.
    
    No functional changes
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-16-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: adjust parameters passed to cleanup_halted_endpoint() [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:20 2021 +0200

    xhci: adjust parameters passed to cleanup_halted_endpoint()
    
    [ Upstream commit d70f4231b81eeb6dd78bd913ff42729b524eec51 ]
    
    Instead of passing slot id and endpoint index to
    cleanup_halted_endpoint() pass the endpoint structure pointer
    as it's already known.
    
    Avoids again digging out the endpoint structure based on
    slot id and endpoint index, and passing them along the
    call chain for this purpose only.
    
    Add slot_id to the virt_dev structure so that it
    can easily be found from a virt_dev, or its child, the
    virt_ep endpoint structure.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: Avoid parsing transfer events several times [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:18 2021 +0200

    xhci: Avoid parsing transfer events several times
    
    [ Upstream commit ab58f3bb6aaaf98ba81d5c627ac25c08ff4ed4f1 ]
    
    When handling transfer events the event is passed along the handling
    callpath and parsed again in several occasions.
    
    The event contains slot_id and endpoint index, from which the driver
    endpoint structure can be found. There wasn't however a way to get the
    endpoint index or parent usb device from this endpoint structure.
    
    A lot of extra event parsing, and thus some DMA doublefetch cases,
    and excess variables and code can be avoided by adding endpoint index
    and parent usb virt device pointer to the endpoint structure.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: get isochronous ring directly from endpoint structure [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:19 2021 +0200

    xhci: get isochronous ring directly from endpoint structure
    
    [ Upstream commit d4dff8043ea5b93a30cb9b19d4407bd506a6877a ]
    
    isochronous endpoints do not support streams, meaning that
    there is only one ring per endpoint.
    
    Avoid double-fetching the transfer event DMA to get the
    ring. Also makes passing the event to skip_isoc_td() uncecessary.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: move and rename xhci_cleanup_halted_endpoint() [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:37 2021 +0200

    xhci: move and rename xhci_cleanup_halted_endpoint()
    
    [ Upstream commit 7c6c334e6fc8cd99e780fd74cd29687886a81862 ]
    
    Halted endpoints can be discoverd both when handling transfer events and
    command completion events. Move code that handles halted endpoints before
    both of those event handlers.
    
    Rename the function to xhci_handle_halted_ep() to better describe
    what it does. Try to reserve "cleanup" word in function names for last
    stage cleanup activities.
    
    No functional changes
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-21-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: move xhci_td_cleanup so it can be called by more functions [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:33 2021 +0200

    xhci: move xhci_td_cleanup so it can be called by more functions
    
    [ Upstream commit 69eaf9e79fa7c7ff4b1eb626493ce5a81e467520 ]
    
    No funtional changes
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-17-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: Prevent infinite loop in transaction errors recovery for streams [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed Nov 30 11:19:43 2022 +0200

    xhci: Prevent infinite loop in transaction errors recovery for streams
    
    [ Upstream commit a1575120972ecd7baa6af6a69e4e7ea9213bde7c ]
    
    Make sure to also limit the amount of soft reset retries for transaction
    errors on streams in cases where the transaction error event doesn't point
    to any specific TRB.
    
    In these cases we don't know the TRB or stream ring, but we do know which
    endpoint had the error.
    
    To keep error counting simple and functional, move the current err_count
    from ring structure to endpoint structure.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20221130091944.2171610-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: store TD status in the td struct instead of passing it along [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jan 29 15:00:35 2021 +0200

    xhci: store TD status in the td struct instead of passing it along
    
    [ Upstream commit a6ccd1fd4bd4fca37eaa3d76bef940d6332919bc ]
    
    In cases where the TD can't be given back in current handler we want
    to be able to store it until its time to return the TD.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210129130044.206855-19-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: a1575120972e ("xhci: Prevent infinite loop in transaction errors recovery for streams")
    Signed-off-by: Sasha Levin <sashal@kernel.org>