Changelog in Linux kernel 6.1.97

 
ACPI: x86: Force StorageD3Enable on more products [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Thu May 9 13:45:02 2024 -0500

    ACPI: x86: Force StorageD3Enable on more products
    
    [ Upstream commit e79a10652bbd320649da705ca1ea0c04351af403 ]
    
    A Rembrandt-based HP thin client is reported to have problems where
    the NVME disk isn't present after resume from s2idle.
    
    This is because the NVME disk wasn't put into D3 at suspend, and
    that happened because the StorageD3Enable _DSD was missing in the BIOS.
    
    As AMD's architecture requires that the NVME is in D3 for s2idle, adjust
    the criteria for force_storage_d3 to match *all* Zen SoCs when the FADT
    advertises low power idle support.
    
    This will ensure that any future products with this BIOS deficiency don't
    need to be added to the allow list of overrides.
    
    Cc: All applicable <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Acked-by: Hans de Goede <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Mar 31 11:08:42 2023 -0500

    ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable
    
    [ Upstream commit 10b6b4a8ac6120ec36555fd286eed577f7632e3b ]
    
    Picasso was the first APU that introduced s2idle support from AMD,
    and it was predating before vendors started to use `StorageD3Enable`
    in their firmware.
    
    Windows doesn't have problems with this hardware and NVME so it was
    likely on the list of hardcoded CPUs to use this behavior in Windows.
    
    Add it to the list for Linux to avoid NVME resume issues.
    
    Reported-by: Stuart Axon <[email protected]>
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2449
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: emux: improve patch ioctl data validation [+ + +]
Author: Oswald Buddenhagen <[email protected]>
Date:   Sat Apr 6 08:48:20 2024 +0200

    ALSA: emux: improve patch ioctl data validation
    
    [ Upstream commit 89b32ccb12ae67e630c6453d778ec30a592a212f ]
    
    In load_data(), make the validation of and skipping over the main info
    block match that in load_guspatch().
    
    In load_guspatch(), add checking that the specified patch length matches
    the actually supplied data, like load_data() already did.
    
    Signed-off-by: Oswald Buddenhagen <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook 645/665 G11. [+ + +]
Author: Dirk Su <[email protected]>
Date:   Wed Jun 26 10:14:36 2024 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook 645/665 G11.
    
    commit 3cd59d8ef8df7d7a079f54d56502dae8f716b39b upstream.
    
    HP EliteBook 645/665 G11 needs ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to
    make mic-mute/audio-mute working.
    
    Signed-off-by: Dirk Su <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: dts: rockchip: Add sound-dai-cells for RK3368 [+ + +]
Author: Alex Bee <[email protected]>
Date:   Sun Jun 23 11:01:15 2024 +0200

    arm64: dts: rockchip: Add sound-dai-cells for RK3368
    
    [ Upstream commit 8d7ec44aa5d1eb94a30319074762a1740440cdc8 ]
    
    Add the missing #sound-dai-cells for RK3368's I2S and S/PDIF controllers.
    
    Fixes: f7d89dfe1e31 ("arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs")
    Fixes: 0328d68ea76d ("arm64: dts: rockchip: add rk3368 spdif node")
    Signed-off-by: Alex Bee <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E [+ + +]
Author: FUKAUMI Naoki <[email protected]>
Date:   Wed Jun 19 14:00:46 2024 +0900

    arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E
    
    [ Upstream commit 02afd3d5b9fa4ffed284c0f7e7bec609097804fc ]
    
    use GPIO0_A2 as interrupt pin for PMIC. GPIO2_A6 was used for
    pre-production board.
    
    Fixes: b918e81f2145 ("arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E")
    Signed-off-by: FUKAUMI Naoki <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Fix SD NAND and eMMC init on rk3308-rock-pi-s [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Tue May 21 21:10:06 2024 +0000

    arm64: dts: rockchip: Fix SD NAND and eMMC init on rk3308-rock-pi-s
    
    [ Upstream commit 1fb98c855ccd7bc7f50c7a9626fbb8440454760b ]
    
    Radxa ROCK Pi S have optional onboard SD NAND on board revision v1.1,
    v1.2 and v1.3, revision v1.5 changed to use optional onboard eMMC.
    
    The optional SD NAND typically fails to initialize:
    
      mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
      mmc0: error -110 whilst initialising SD card
      mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
      mmc0: error -110 whilst initialising SD card
      mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
      mmc0: error -110 whilst initialising SD card
      mmc_host mmc0: Bus speed (slot 0) = 100000Hz (slot req 100000Hz, actual 100000HZ div = 0)
      mmc0: error -110 whilst initialising SD card
    
    Add pinctrl and cap-sd-highspeed to fix SD NAND initialization. Also
    drop bus-width and mmc-hs200-1_8v to fix eMMC initialization on the new
    v1.5 board revision, only 3v3 signal voltage is used.
    
    Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support")
    Signed-off-by: Jonas Karlman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Rename LED related pinctrl nodes on rk3308-rock-pi-s [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Tue May 21 21:10:09 2024 +0000

    arm64: dts: rockchip: Rename LED related pinctrl nodes on rk3308-rock-pi-s
    
    [ Upstream commit d2a52f678883fe4bc00bca89366b1ba504750abf ]
    
    The nodename, <name>-gpio, of referenced pinctrl nodes for the two LEDs
    on the ROCK Pi S cause DT schema validation error:
    
      leds: green-led-gpio: {'rockchip,pins': [[0, 6, 0, 90]], 'phandle': [[98]]} is not of type 'array'
            from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml#
      leds: heartbeat-led-gpio: {'rockchip,pins': [[0, 5, 0, 90]], 'phandle': [[99]]} is not of type 'array'
            from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml#
    
    Rename the pinctrl nodes and symbols to pass DT schema validation, also
    extend LED nodes with information about color and function.
    
    Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support")
    Signed-off-by: Jonas Karlman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node [+ + +]
Author: Johan Jonker <[email protected]>
Date:   Thu Jun 13 20:08:10 2024 +0200

    ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
    
    [ Upstream commit cca46f811d0000c1522a5e18ea48c27a15e45c05 ]
    
    '#sound-dai-cells' is required to properly interpret
    the list of DAI specified in the 'sound-dai' property,
    so add them to the 'hdmi' node for 'rk3066a.dtsi'.
    
    Fixes: fadc78062477 ("ARM: dts: rockchip: add rk3066 hdmi nodes")
    Signed-off-by: Johan Jonker <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: amd: acp: remove i2s configuration check in acp_i2s_probe() [+ + +]
Author: Vijendar Mukunda <[email protected]>
Date:   Mon Jun 17 12:58:35 2024 +0530

    ASoC: amd: acp: remove i2s configuration check in acp_i2s_probe()
    
    [ Upstream commit 70fa3900c3ed92158628710e81d274e5cb52f92b ]
    
    ACP supports different pin configurations for I2S IO. Checking ACP pin
    configuration value against specific value breaks the functionality for
    other I2S pin configurations. This check is no longer required in i2s dai
    driver probe call as i2s configuration check will be verified during acp
    platform device creation sequence.
    Remove i2s_mode check in acp_i2s_probe() function.
    
    Fixes: b24484c18b10 ("ASoC: amd: acp: ACP code generic to support newer platforms")
    Signed-off-by: Vijendar Mukunda <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: fsl-asoc-card: set priv->pdev before using it [+ + +]
Author: Elinor Montmasson <[email protected]>
Date:   Thu Jun 20 15:25:03 2024 +0200

    ASoC: fsl-asoc-card: set priv->pdev before using it
    
    [ Upstream commit 90f3feb24172185f1832636264943e8b5e289245 ]
    
    priv->pdev pointer was set after being used in
    fsl_asoc_card_audmux_init().
    Move this assignment at the start of the probe function, so
    sub-functions can correctly use pdev through priv.
    
    fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the
    dev struct, used with dev_err macros.
    As priv is zero-initialised, there would be a NULL pointer dereference.
    Note that if priv->dev is dereferenced before assignment but never used,
    for example if there is no error to be printed, the driver won't crash
    probably due to compiler optimisations.
    
    Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support")
    Signed-off-by: Elinor Montmasson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rockchip: i2s-tdm: Fix trcm mode by setting clock on right mclk [+ + +]
Author: Alibek Omarov <[email protected]>
Date:   Tue Jun 4 21:47:52 2024 +0300

    ASoC: rockchip: i2s-tdm: Fix trcm mode by setting clock on right mclk
    
    [ Upstream commit ccd8d753f0fe8f16745fa2b6be5946349731d901 ]
    
    When TRCM mode is enabled, I2S RX and TX clocks are synchronized through
    selected clock source. Without this fix BCLK and LRCK might get parented
    to an uninitialized MCLK and the DAI will receive data at wrong pace.
    
    However, unlike in original i2s-tdm driver, there is no need to manually
    synchronize mclk_rx and mclk_tx, as only one gets used anyway.
    
    Tested on a board with RK3568 SoC and Silergy SY24145S codec with enabled and
    disabled TRCM mode.
    
    Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates")
    Signed-off-by: Alibek Omarov <[email protected]>
    Reviewed-by: Luca Ceresoli <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: ahci: Clean up sysfs file on error [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Sat Jun 29 14:42:14 2024 +0200

    ata: ahci: Clean up sysfs file on error
    
    commit eeb25a09c5e0805d92e4ebd12c4b0ad0df1b0295 upstream.
    
    .probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
    if probe() fails after this call, we currently never call
    sysfs_remove_file_from_group().
    
    (The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
    does not help, as .remove() is not called on .probe() error.)
    
    Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
    time we insmod the module we will get:
    
    sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
    CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 #43
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x5d/0x80
     sysfs_warn_dup.cold+0x17/0x23
     sysfs_add_file_mode_ns+0x11a/0x130
     sysfs_add_file_to_group+0x7e/0xc0
     ahci_init_one+0x31f/0xd40 [ahci]
    
    Fixes: 894fba7f434a ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
    Cc: [email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ata: libata-core: Fix double free on error [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Sat Jun 29 14:42:13 2024 +0200

    ata: libata-core: Fix double free on error
    
    commit ab9e0c529eb7cafebdd31fe1644524e80a48b05d upstream.
    
    If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
    to the err_out label, which will call devres_release_group().
    devres_release_group() will trigger a call to ata_host_release().
    ata_host_release() calls kfree(host), so executing the kfree(host) in
    ata_host_alloc() will lead to a double free:
    
    kernel BUG at mm/slub.c:553!
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    RIP: 0010:kfree+0x2cf/0x2f0
    Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
    RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
    RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
    RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
    RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
    R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
    FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? __die_body.cold+0x19/0x27
     ? die+0x2e/0x50
     ? do_trap+0xca/0x110
     ? do_error_trap+0x6a/0x90
     ? kfree+0x2cf/0x2f0
     ? exc_invalid_op+0x50/0x70
     ? kfree+0x2cf/0x2f0
     ? asm_exc_invalid_op+0x1a/0x20
     ? ata_host_alloc+0xf5/0x120 [libata]
     ? ata_host_alloc+0xf5/0x120 [libata]
     ? kfree+0x2cf/0x2f0
     ata_host_alloc+0xf5/0x120 [libata]
     ata_host_alloc_pinfo+0x14/0xa0 [libata]
     ahci_init_one+0x6c9/0xd20 [ahci]
    
    Ensure that we will not call kfree(host) twice, by performing the kfree()
    only if the devres_open_group() call failed.
    
    Fixes: dafd6c496381 ("libata: ensure host is free'd on error exit paths")
    Cc: [email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
batman-adv: Don't accept TT entries for out-of-spec VIDs [+ + +]
Author: Sven Eckelmann <[email protected]>
Date:   Sat May 4 21:57:30 2024 +0200

    batman-adv: Don't accept TT entries for out-of-spec VIDs
    
    commit 537a350d14321c8cca5efbf0a33a404fec3a9f9e upstream.
    
    The internal handling of VLAN IDs in batman-adv is only specified for
    following encodings:
    
    * VLAN is used
      - bit 15 is 1
      - bit 11 - bit 0 is the VLAN ID (0-4095)
      - remaining bits are 0
    * No VLAN is used
      - bit 15 is 0
      - remaining bits are 0
    
    batman-adv was only preparing new translation table entries (based on its
    soft interface information) using this encoding format. But the receive
    path was never checking if entries in the roam or TT TVLVs were also
    following this encoding.
    
    It was therefore possible to create more than the expected maximum of 4096
    + 1 entries in the originator VLAN list. Simply by setting the "remaining
    bits" to "random" values in corresponding TVLV.
    
    Cc: [email protected]
    Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
    Reported-by: Linus Lüssing <[email protected]>
    Signed-off-by: Sven Eckelmann <[email protected]>
    Signed-off-by: Simon Wunderlich <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bpf: Add a check for struct bpf_fib_lookup size [+ + +]
Author: Anton Protopopov <[email protected]>
Date:   Tue Mar 26 10:17:42 2024 +0000

    bpf: Add a check for struct bpf_fib_lookup size
    
    [ Upstream commit 59b418c7063d30e0a3e1f592d47df096db83185c ]
    
    The struct bpf_fib_lookup should not grow outside of its 64 bytes.
    Add a static assert to validate this.
    
    Suggested-by: David Ahern <[email protected]>
    Signed-off-by: Anton Protopopov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix overrunning reservations in ringbuf [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Jun 21 16:08:27 2024 +0200

    bpf: Fix overrunning reservations in ringbuf
    
    [ Upstream commit cfa1a2329a691ffd991fcf7248a57d752e712881 ]
    
    The BPF ring buffer internally is implemented as a power-of-2 sized circular
    buffer, with two logical and ever-increasing counters: consumer_pos is the
    consumer counter to show which logical position the consumer consumed the
    data, and producer_pos which is the producer counter denoting the amount of
    data reserved by all producers.
    
    Each time a record is reserved, the producer that "owns" the record will
    successfully advance producer counter. In user space each time a record is
    read, the consumer of the data advanced the consumer counter once it finished
    processing. Both counters are stored in separate pages so that from user
    space, the producer counter is read-only and the consumer counter is read-write.
    
    One aspect that simplifies and thus speeds up the implementation of both
    producers and consumers is how the data area is mapped twice contiguously
    back-to-back in the virtual memory, allowing to not take any special measures
    for samples that have to wrap around at the end of the circular buffer data
    area, because the next page after the last data page would be first data page
    again, and thus the sample will still appear completely contiguous in virtual
    memory.
    
    Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for
    book-keeping the length and offset, and is inaccessible to the BPF program.
    Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`
    for the BPF program to use. Bing-Jhong and Muhammad reported that it is however
    possible to make a second allocated memory chunk overlapping with the first
    chunk and as a result, the BPF program is now able to edit first chunk's
    header.
    
    For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size
    of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to
    bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in
    [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets
    allocate a chunk B with size 0x3000. This will succeed because consumer_pos
    was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`
    check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able
    to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned
    earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data
    pages. This means that chunk B at [0x4000,0x4008] is chunk A's header.
    bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then
    locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk
    B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong
    page and could cause a crash.
    
    Fix it by calculating the oldest pending_pos and check whether the range
    from the oldest outstanding record to the newest would span beyond the ring
    buffer size. If that is the case, then reject the request. We've tested with
    the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)
    before/after the fix and while it seems a bit slower on some benchmarks, it
    is still not significantly enough to matter.
    
    Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
    Reported-by: Bing-Jhong Billy Jheng <[email protected]>
    Reported-by: Muhammad Ramdhan <[email protected]>
    Co-developed-by: Bing-Jhong Billy Jheng <[email protected]>
    Co-developed-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Bing-Jhong Billy Jheng <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode [+ + +]
Author: Martin KaFai Lau <[email protected]>
Date:   Thu Mar 28 11:58:01 2024 -0700

    bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode
    
    [ Upstream commit e8742081db7d01f980c6161ae1e8a1dbc1e30979 ]
    
    syzbot reported uninit memory usages during map_{lookup,delete}_elem.
    
    ==========
    BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]
    BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796
    __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]
    dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796
    ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline]
    bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38
    ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
    __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237
    ==========
    
    The reproducer should be in the interpreter mode.
    
    The C reproducer is trying to run the following bpf prog:
    
        0: (18) r0 = 0x0
        2: (18) r1 = map[id:49]
        4: (b7) r8 = 16777216
        5: (7b) *(u64 *)(r10 -8) = r8
        6: (bf) r2 = r10
        7: (07) r2 += -229
                ^^^^^^^^^^
    
        8: (b7) r3 = 8
        9: (b7) r4 = 0
       10: (85) call dev_map_lookup_elem#1543472
       11: (95) exit
    
    It is due to the "void *key" (r2) passed to the helper. bpf allows uninit
    stack memory access for bpf prog with the right privileges. This patch
    uses kmsan_unpoison_memory() to mark the stack as initialized.
    
    This should address different syzbot reports on the uninit "void *key"
    argument during map_{lookup,delete}_elem.
    
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Tested-by: [email protected]
    Suggested-by: Yonghong Song <[email protected]>
    Suggested-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Fri Mar 8 06:38:07 2024 +0100

    bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
    
    [ Upstream commit 7d2cc63eca0c993c99d18893214abf8f85d566d8 ]
    
    set_memory_ro() can fail, leaving memory unprotected.
    
    Check its return and take it into account as an error.
    
    Link: https://github.com/KSPP/linux/issues/7
    Signed-off-by: Christophe Leroy <[email protected]>
    Cc: [email protected] <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Message-ID: <286def78955e04382b227cb3e4b6ba272a7442e3.1709850515.git.christophe.leroy@csgroup.eu>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: zoned: fix initial free space detection [+ + +]
Author: Naohiro Aota <[email protected]>
Date:   Tue Jun 11 17:17:30 2024 +0900

    btrfs: zoned: fix initial free space detection
    
    commit b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a upstream.
    
    When creating a new block group, it calls btrfs_add_new_free_space() to add
    the entire block group range into the free space accounting.
    __btrfs_add_free_space_zoned() checks if size == block_group->length to
    detect the initial free space adding, and proceed that case properly.
    
    However, if the zone_capacity == zone_size and the over-write speed is fast
    enough, the entire zone can be over-written within one transaction. That
    confuses __btrfs_add_free_space_zoned() to handle it as an initial free
    space accounting. As a result, that block group becomes a strange state: 0
    used bytes, 0 zone_unusable bytes, but alloc_offset == zone_capacity (no
    allocation anymore).
    
    The initial free space accounting can properly be checked by checking
    alloc_offset too.
    
    Fixes: 98173255bddd ("btrfs: zoned: calculate free space from zone capacity")
    CC: [email protected] # 6.1+
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Naohiro Aota <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
can: mcp251xfd: fix infinite loop when xmit fails [+ + +]
Author: Vitor Soares <[email protected]>
Date:   Fri May 17 14:43:55 2024 +0100

    can: mcp251xfd: fix infinite loop when xmit fails
    
    commit d8fb63e46c884c898a38f061c2330f7729e75510 upstream.
    
    When the mcp251xfd_start_xmit() function fails, the driver stops
    processing messages, and the interrupt routine does not return,
    running indefinitely even after killing the running application.
    
    Error messages:
    [  441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16
    [  441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).
    ... and repeat forever.
    
    The issue can be triggered when multiple devices share the same SPI
    interface. And there is concurrent access to the bus.
    
    The problem occurs because tx_ring->head increments even if
    mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX
    package while still expecting a response in
    mcp251xfd_handle_tefif_one().
    
    Resolve the issue by starting a workqueue to write the tx obj
    synchronously if err = -EBUSY. In case of another error, decrement
    tx_ring->head, remove skb from the echo stack, and drop the message.
    
    Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
    Cc: [email protected]
    Signed-off-by: Vitor Soares <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    [mkl: use more imperative wording in patch description]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
counter: ti-eqep: enable clock at probe [+ + +]
Author: David Lechner <[email protected]>
Date:   Fri Jun 21 17:22:40 2024 -0500

    counter: ti-eqep: enable clock at probe
    
    [ Upstream commit 0cf81c73e4c6a4861128a8f27861176ec312af4e ]
    
    The TI eQEP clock is both a functional and interface clock. Since it is
    required for the device to function, we should be enabling it at probe.
    
    Up to now, we've just been lucky that the clock was enabled by something
    else on the system already.
    
    Fixes: f213729f6796 ("counter: new TI eQEP driver")
    Reviewed-by: Judith Mendez <[email protected]>
    Signed-off-by: David Lechner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: William Breathitt Gray <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked() [+ + +]
Author: Yuntao Wang <[email protected]>
Date:   Wed May 15 21:45:54 2024 +0800

    cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked()
    
    commit 932d8476399f622aa0767a4a0a9e78e5341dc0e1 upstream.
    
    Commit 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare
    stage") added a dynamic range for the prepare states, but did not handle
    the assignment of the dynstate variable in __cpuhp_setup_state_cpuslocked().
    
    This causes the corresponding startup callback not to be invoked when
    calling __cpuhp_setup_state_cpuslocked() with the CPUHP_BP_PREPARE_DYN
    parameter, even though it should be.
    
    Currently, the users of __cpuhp_setup_state_cpuslocked(), for one reason or
    another, have not triggered this bug.
    
    Fixes: 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare stage")
    Signed-off-by: Yuntao Wang <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is missing [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu Jun 20 18:14:53 2024 +0200

    cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is missing
    
    commit a1ff59784b277795a613beaa5d3dd9c5595c69a7 upstream.
    
    It is reported that single-thread performance on some hybrid systems
    dropped significantly after commit 7feec7430edd ("ACPI: CPPC: Only probe
    for _CPC if CPPC v2 is acked") which prevented _CPC from being used if
    the support for it had not been confirmed by the platform firmware.
    
    The problem is that if the platform firmware does not confirm CPPC v2
    support, cppc_get_perf_caps() returns an error which prevents the
    intel_pstate driver from enabling ITMT.  Consequently, the scheduler
    does not get any hints on CPU performance differences, so in a hybrid
    system some tasks may run on CPUs with lower capacity even though they
    should be running on high-capacity CPUs.
    
    To address this, modify intel_pstate to use the information from
    MSR_HWP_CAPABILITIES to enable ITMT if CPPC is not available (which is
    done already if the highest performance number coming from CPPC is not
    realistic).
    
    Fixes: 7feec7430edd ("ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked")
    Closes: https://lore.kernel.org/linux-acpi/[email protected]
    Link: https://lore.kernel.org/linux-acpi/ZnD22b3Br1ng7alf@kf-XE
    Reported-by: Aaron Rainbolt <[email protected]>
    Tested-by: Aaron Rainbolt <[email protected]>
    Cc: 5.19+ <[email protected]> # 5.19+
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
crypto: ecdh - explicitly zeroize private_key [+ + +]
Author: Joachim Vandersmissen <[email protected]>
Date:   Thu Mar 28 11:24:30 2024 -0500

    crypto: ecdh - explicitly zeroize private_key
    
    [ Upstream commit 73e5984e540a76a2ee1868b91590c922da8c24c9 ]
    
    private_key is overwritten with the key parameter passed in by the
    caller (if present), or alternatively a newly generated private key.
    However, it is possible that the caller provides a key (or the newly
    generated key) which is shorter than the previous key. In that
    scenario, some key material from the previous key would not be
    overwritten. The easiest solution is to explicitly zeroize the entire
    private_key array first.
    
    Note that this patch slightly changes the behavior of this function:
    previously, if the ecc_gen_privkey failed, the old private_key would
    remain. Now, the private_key is always zeroized. This behavior is
    consistent with the case where params.key is set and ecc_is_key_valid
    fails.
    
    Signed-off-by: Joachim Vandersmissen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
csky, hexagon: fix broken sys_sync_file_range [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 14 09:54:20 2024 +0200

    csky, hexagon: fix broken sys_sync_file_range
    
    commit 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff upstream.
    
    Both of these architectures require u64 function arguments to be
    passed in even/odd pairs of registers or stack slots, which in case of
    sync_file_range would result in a seven-argument system call that is
    not currently possible. The system call is therefore incompatible with
    all existing binaries.
    
    While it would be possible to implement support for seven arguments
    like on mips, it seems better to use a six-argument version, either
    with the normal argument order but misaligned as on most architectures
    or with the reordered sync_file_range2() calling conventions as on
    arm and powerpc.
    
    Cc: [email protected]
    Acked-by: Guo Ren <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd/amdgpu: Fix style errors in amdgpu_drv.c & amdgpu_device.c [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Wed Apr 19 16:12:45 2023 +0530

    drm/amd/amdgpu: Fix style errors in amdgpu_drv.c & amdgpu_device.c
    
    [ Upstream commit 47fc644f801e4414753a9b7e87ed41f991cd68c3 ]
    
    Fix following checkpatch style errors in amdgpu_drv.c &
    amdgpu_device.c
    
    ERROR: exactly one space required after that #ifdef
    ERROR: spaces required around that '+=' (ctx:WxV)
    ERROR: space required before the open brace '{'
    ERROR: spaces required around that '||' (ctx:VxE)
    ERROR: space prohibited before that close parenthesis ')'
    ERROR: space required before the open parenthesis '('
    ERROR: space required before the open brace '{'
    ERROR: code indent should use tabs where possible
    
    Cc: Christian König <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: Mario Limonciello <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 74fa02c4a5ea ("drm/amdgpu: Fix pci state save during mode-1 reset")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/atomfirmware: fix parsing of vram_info [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Fri Jun 14 13:48:26 2024 -0400

    drm/amdgpu/atomfirmware: fix parsing of vram_info
    
    commit f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 upstream.
    
    v3.x changed the how vram width was encoded.  The previous
    implementation actually worked correctly for most boards.
    Fix the implementation to work correctly everywhere.
    
    This fixes the vram width reported in the kernel log on
    some boards.
    
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: avoid using null object of framebuffer [+ + +]
Author: Julia Zhang <[email protected]>
Date:   Mon Jun 3 19:31:09 2024 +0800

    drm/amdgpu: avoid using null object of framebuffer
    
    commit bcfa48ff785bd121316592b131ff6531e3e696bb upstream.
    
    Instead of using state->fb->obj[0] directly, get object from framebuffer
    by calling drm_gem_fb_get_obj() and return error code when object is
    null to avoid using null object of framebuffer.
    
    Reported-by: Fusheng Huang <[email protected]>
    Signed-off-by: Julia Zhang <[email protected]>
    Reviewed-by: Huang Rui <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: Fix pci state save during mode-1 reset [+ + +]
Author: Lijo Lazar <[email protected]>
Date:   Tue Jun 18 14:04:38 2024 +0530

    drm/amdgpu: Fix pci state save during mode-1 reset
    
    [ Upstream commit 74fa02c4a5ea1ade5156a6ce494d3ea83881c2d8 ]
    
    Cache the PCI state before bus master is disabled. The saved state is
    later used for other cases like restoring config space after mode-2
    reset.
    
    Fixes: 5c03e5843e6b ("drm/amdgpu:add smu mode1/2 support for aldebaran")
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Feifei Xu <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/gt: Fix potential UAF by revoke of fence registers [+ + +]
Author: Janusz Krzysztofik <[email protected]>
Date:   Mon Jun 3 21:54:45 2024 +0200

    drm/i915/gt: Fix potential UAF by revoke of fence registers
    
    commit 996c3412a06578e9d779a16b9e79ace18125ab50 upstream.
    
    CI has been sporadically reporting the following issue triggered by
    igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
    
    <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
    ...
    <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
    <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
    <3> [414.070354] Unable to pin Y-tiled fence; err:-4
    <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
    ...
    <4>[  609.603992] ------------[ cut here ]------------
    <2>[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
    <4>[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    <4>[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
    <4>[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
    <4>[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]
    <4>[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
    ...
    <4>[  609.604271] Call Trace:
    <4>[  609.604273]  <TASK>
    ...
    <4>[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]
    <4>[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]
    <4>[  609.604977]  force_unbind+0x24/0xa0 [i915]
    <4>[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]
    <4>[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
    <4>[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
    <4>[  609.605440]  process_scheduled_works+0x351/0x690
    ...
    
    In the past, there were similar failures reported by CI from other IGT
    tests, observed on other platforms.
    
    Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
    before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
    idleness of vma->active via fence_update().   That commit introduced
    vma->fence->active in order for the fence_update() to be able to wait
    selectively on that one instead of vma->active since only idleness of
    fence registers was needed.  But then, another commit 0d86ee35097a
    ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
    fence_update() in i915_vma_revoke_fence() with only fence_write(), and
    also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
    No justification was provided on why we might then expect idleness of
    vma->fence->active without first waiting on it.
    
    The issue can be potentially caused by a race among revocation of fence
    registers on one side and sequential execution of signal callbacks invoked
    on completion of a request that was using them on the other, still
    processed in parallel to revocation of those fence registers.  Fix it by
    waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
    
    Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
    Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021
    Signed-off-by: Janusz Krzysztofik <[email protected]>
    Cc: [email protected] # v5.8+
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes [+ + +]
Author: Ma Ke <[email protected]>
Date:   Tue Jun 25 16:10:29 2024 +0800

    drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
    
    commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream.
    
    In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
    assigned to mode, which will lead to a possible NULL pointer dereference
    on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
    Add a check to avoid null pointer dereference.
    
    Cc: [email protected]
    Signed-off-by: Ma Ke <[email protected]>
    Signed-off-by: Lyude Paul <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes [+ + +]
Author: Ma Ke <[email protected]>
Date:   Tue Jun 25 16:18:28 2024 +0800

    drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
    
    commit 66edf3fb331b6c55439b10f9862987b0916b3726 upstream.
    
    In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
    assigned to mode, which will lead to a possible NULL pointer dereference
    on failure of drm_mode_duplicate(). Add a check to avoid npd.
    
    Cc: [email protected]
    Signed-off-by: Ma Ke <[email protected]>
    Signed-off-by: Lyude Paul <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Sun Mar 17 17:48:39 2024 +0200

    drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
    
    [ Upstream commit ee7860cd8b5763017f8dc785c2851fecb7a0c565 ]
    
    The ilitek-ili9881c controls the reset GPIO using the non-sleeping
    gpiod_set_value() function. This complains loudly when the GPIO
    controller needs to sleep. As the caller can sleep, use
    gpiod_set_value_cansleep() to fix the issue.
    
    Signed-off-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: simple: Add missing display timing flags for KOE TX26D202VM0BWA [+ + +]
Author: Liu Ying <[email protected]>
Date:   Mon Jun 24 09:56:12 2024 +0800

    drm/panel: simple: Add missing display timing flags for KOE TX26D202VM0BWA
    
    [ Upstream commit 37ce99b77762256ec9fda58d58fd613230151456 ]
    
    KOE TX26D202VM0BWA panel spec indicates the DE signal is active high in
    timing chart, so add DISPLAY_FLAGS_DE_HIGH flag in display timing flags.
    This aligns display_timing with panel_desc.
    
    Fixes: 8a07052440c2 ("drm/panel: simple: Add support for KOE TX26D202VM0BWA panel")
    Signed-off-by: Liu Ying <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/radeon_display: Decrease the size of allocated memory [+ + +]
Author: Erick Archer <[email protected]>
Date:   Sat Mar 30 17:34:47 2024 +0100

    drm/radeon/radeon_display: Decrease the size of allocated memory
    
    [ Upstream commit ae6a233092747e9652eb793d92f79d0820e01c6a ]
    
    This is an effort to get rid of all multiplications from allocation
    functions in order to prevent integer overflows [1] [2].
    
    In this case, the memory allocated to store RADEONFB_CONN_LIMIT pointers
    to "drm_connector" structures can be avoided. This is because this
    memory area is never accessed.
    
    Also, in the kzalloc function, it is preferred to use sizeof(*pointer)
    instead of sizeof(type) due to the type of the variable can change and
    one needs not change the former (unlike the latter).
    
    At the same time take advantage to remove the "#if 0" block, the code
    where the removed memory area was accessed, and the RADEONFB_CONN_LIMIT
    constant due to now is never used.
    
    Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
    Link: https://github.com/KSPP/linux/issues/160 [2]
    Acked-by: Christian König <[email protected]>
    Signed-off-by: Erick Archer <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: i2c: atmel,at91sam: correct path to i2c-controller schema [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Thu Jun 20 13:34:49 2024 +0200

    dt-bindings: i2c: atmel,at91sam: correct path to i2c-controller schema
    
    [ Upstream commit d4e001ffeccfc128c715057e866f301ac9b95728 ]
    
    The referenced i2c-controller.yaml schema is provided by dtschema
    package (outside of Linux kernel), so use full path to reference it.
    
    Cc: [email protected]
    Fixes: 7ea75dd386be ("dt-bindings: i2c: convert i2c-at91 to json-schema")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Conor Dooley <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: i2c: Drop unneeded quotes [+ + +]
Author: Rob Herring <[email protected]>
Date:   Wed Mar 22 12:35:29 2023 -0500

    dt-bindings: i2c: Drop unneeded quotes
    
    [ Upstream commit fc114c75680da73c3815512d880f69cecc9a9b87 ]
    
    Cleanup bindings dropping unneeded quotes. Once all these are fixed,
    checking for this can be enabled in yamllint.
    
    Signed-off-by: Rob Herring <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Nicolas Ferre <[email protected]>
    Reviewed-by: Alain Volmat <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Stable-dep-of: d4e001ffeccf ("dt-bindings: i2c: atmel,at91sam: correct path to i2c-controller schema")
    Signed-off-by: Sasha Levin <[email protected]>

 
efi/x86: Free EFI memory map only when installing a new one. [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Mon Jun 10 16:02:13 2024 +0200

    efi/x86: Free EFI memory map only when installing a new one.
    
    commit 75dde792d6f6c2d0af50278bd374bf0c512fe196 upstream.
    
    The logic in __efi_memmap_init() is shared between two different
    execution flows:
    - mapping the EFI memory map early or late into the kernel VA space, so
      that its entries can be accessed;
    - the x86 specific cloning of the EFI memory map in order to insert new
      entries that are created as a result of making a memory reservation
      via a call to efi_mem_reserve().
    
    In the former case, the underlying memory containing the kernel's view
    of the EFI memory map (which may be heavily modified by the kernel
    itself on x86) is not modified at all, and the only thing that changes
    is the virtual mapping of this memory, which is different between early
    and late boot.
    
    In the latter case, an entirely new allocation is created that carries a
    new, updated version of the kernel's view of the EFI memory map. When
    installing this new version, the old version will no longer be
    referenced, and if the memory was allocated by the kernel, it will leak
    unless it gets freed.
    
    The logic that implements this freeing currently lives on the code path
    that is shared between these two use cases, but it should only apply to
    the latter. So move it to the correct spot.
    
    While at it, drop the dummy definition for non-x86 architectures, as
    that is no longer needed.
    
    Cc: <[email protected]>
    Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks")
    Tested-by: Ashish Kalra <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
efi: memmap: Move manipulation routines into x86 arch tree [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Sat Oct 1 19:09:24 2022 +0200

    efi: memmap: Move manipulation routines into x86 arch tree
    
    commit fdc6d38d64a20c542b1867ebeb8dd03b98829336 upstream.
    
    The EFI memory map is a description of the memory layout as provided by
    the firmware, and only x86 manipulates it in various different ways for
    its own memory bookkeeping. So let's move the memmap routines that are
    only used by x86 into the x86 arch tree.
    
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Sat Oct 1 17:17:36 2022 +0200

    efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures
    
    commit d85e3e34940788578eeffd94e8b7e1d28e7278e9 upstream.
    
    Currently, the EFI_PARAVIRT flag is only used by Xen dom0 boot on x86,
    even though other architectures also support pseudo-EFI boot, where the
    core kernel is invoked directly and provided with a set of data tables
    that resemble the ones constructed by the EFI stub, which never actually
    runs in that case.
    
    Let's fix this inconsistency, and always set this flag when booting dom0
    via the EFI boot path. Note that Xen on x86 does not provide the EFI
    memory map in this case, whereas other architectures do, so move the
    associated EFI_PARAVIRT check into the x86 platform code.
    
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Fix race for duplicate reqsk on identical SYN [+ + +]
Author: luoxuanqiang <[email protected]>
Date:   Fri Jun 21 09:39:29 2024 +0800

    Fix race for duplicate reqsk on identical SYN
    
    [ Upstream commit ff46e3b4421923937b7f6e44ffcd3549a074f321 ]
    
    When bonding is configured in BOND_MODE_BROADCAST mode, if two identical
    SYN packets are received at the same time and processed on different CPUs,
    it can potentially create the same sk (sock) but two different reqsk
    (request_sock) in tcp_conn_request().
    
    These two different reqsk will respond with two SYNACK packets, and since
    the generation of the seq (ISN) incorporates a timestamp, the final two
    SYNACK packets will have different seq values.
    
    The consequence is that when the Client receives and replies with an ACK
    to the earlier SYNACK packet, we will reset(RST) it.
    
    ========================================================================
    
    This behavior is consistently reproducible in my local setup,
    which comprises:
    
                      | NETA1 ------ NETB1 |
    PC_A --- bond --- |                    | --- bond --- PC_B
                      | NETA2 ------ NETB2 |
    
    - PC_A is the Server and has two network cards, NETA1 and NETA2. I have
      bonded these two cards using BOND_MODE_BROADCAST mode and configured
      them to be handled by different CPU.
    
    - PC_B is the Client, also equipped with two network cards, NETB1 and
      NETB2, which are also bonded and configured in BOND_MODE_BROADCAST mode.
    
    If the client attempts a TCP connection to the server, it might encounter
    a failure. Capturing packets from the server side reveals:
    
    10.10.10.10.45182 > localhost: Flags [S], seq 320236027,
    10.10.10.10.45182 > localhost: Flags [S], seq 320236027,
    localhost > 10.10.10.10.45182: Flags [S.], seq 2967855116,
    localhost > 10.10.10.10.45182: Flags [S.], seq 2967855123, <==
    10.10.10.10.45182 > localhost: Flags [.], ack 4294967290,
    10.10.10.10.45182 > localhost: Flags [.], ack 4294967290,
    localhost > 10.10.10.10.45182: Flags [R], seq 2967855117, <==
    localhost > 10.10.10.10.45182: Flags [R], seq 2967855117,
    
    Two SYNACKs with different seq numbers are sent by localhost,
    resulting in an anomaly.
    
    ========================================================================
    
    The attempted solution is as follows:
    Add a return value to inet_csk_reqsk_queue_hash_add() to confirm if the
    ehash insertion is successful (Up to now, the reason for unsuccessful
    insertion is that a reqsk for the same connection has already been
    inserted). If the insertion fails, release the reqsk.
    
    Due to the refcnt, Kuniyuki suggests also adding a return value check
    for the DCCP module; if ehash insertion fails, indicating a successful
    insertion of the same connection, simply release the reqsk as well.
    
    Simultaneously, In the reqsk_queue_hash_req(), the start of the
    req->rsk_timer is adjusted to be after successful insertion.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: luoxuanqiang <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ftruncate: pass a signed offset [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jun 19 11:34:09 2024 +0200

    ftruncate: pass a signed offset
    
    commit 4b8e88e563b5f666446d002ad0dc1e6e8e7102b0 upstream.
    
    The old ftruncate() syscall, using the 32-bit off_t misses a sign
    extension when called in compat mode on 64-bit architectures.  As a
    result, passing a negative length accidentally succeeds in truncating
    to file size between 2GiB and 4GiB.
    
    Changing the type of the compat syscall to the signed compat_off_t
    changes the behavior so it instead returns -EINVAL.
    
    The native entry point, the truncate() syscall and the corresponding
    loff_t based variants are all correct already and do not suffer
    from this mistake.
    
    Fixes: 3f6d078d4acc ("fix compat truncate/ftruncate")
    Reviewed-by: Christian Brauner <[email protected]>
    Cc: [email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gfs2: Fix slab-use-after-free in gfs2_qd_dealloc [+ + +]
Author: Juntong Deng <[email protected]>
Date:   Mon Oct 30 05:10:06 2023 +0800

    gfs2: Fix slab-use-after-free in gfs2_qd_dealloc
    
    commit bdcb8aa434c6d36b5c215d02a9ef07551be25a37 upstream.
    
    In gfs2_put_super(), whether withdrawn or not, the quota should
    be cleaned up by gfs2_quota_cleanup().
    
    Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu
    callback) has run for all gfs2_quota_data objects, resulting in
    use-after-free.
    
    Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called
    by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling
    gfs2_make_fs_ro(), there is no need to call them again.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=29c47e9e51895928698c
    Signed-off-by: Juntong Deng <[email protected]>
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Clayton Casciato <[email protected]>

 
gpio: davinci: Validate the obtained number of IRQs [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Tue Jun 18 17:43:44 2024 +0300

    gpio: davinci: Validate the obtained number of IRQs
    
    [ Upstream commit 7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164 ]
    
    Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken
    DT due to any error this value can be any. Without this value validation
    there can be out of chips->irqs array boundaries access in
    davinci_gpio_probe().
    
    Validate the obtained nirq value so that it won't exceed the maximum
    number of IRQs per bank.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1) [+ + +]
Author: Kent Gibson <[email protected]>
Date:   Wed Jun 26 13:29:22 2024 +0800

    gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1)
    
    [ Upstream commit 9919cce62f68e6ab68dc2a975b5dc670f8ca7d40 ]
    
    linehandle_set_config() behaves badly when direction is not set.
    The configuration validation is borrowed from linehandle_create(), where,
    to verify the intent of the user, the direction must be set to in order
    to effect a change to the electrical configuration of a line. But, when
    applied to reconfiguration, that validation does not allow for the unset
    direction case, making it possible to clear flags set previously without
    specifying the line direction.
    
    Adding to the inconsistency, those changes are not immediately applied by
    linehandle_set_config(), but will take effect when the line value is next
    get or set.
    
    For example, by requesting a configuration with no flags set, an output
    line with GPIOHANDLE_REQUEST_ACTIVE_LOW and GPIOHANDLE_REQUEST_OPEN_DRAIN
    requested could have those flags cleared, inverting the sense of the line
    and changing the line drive to push-pull on the next line value set.
    
    Ensure the intent of the user by disallowing configurations which do not
    have direction set, returning an error to userspace to indicate that the
    configuration is invalid.
    
    And, for clarity, use lflags, a local copy of gcnf.flags, throughout when
    dealing with the requested flags, rather than a mixture of both.
    
    Fixes: e588bb1eae31 ("gpio: add new SET_CONFIG ioctl() to gpio chardev")
    Signed-off-by: Kent Gibson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hexagon: fix fadvise64_64 calling conventions [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Jun 20 15:24:11 2024 +0200

    hexagon: fix fadvise64_64 calling conventions
    
    commit 896842284c6ccba25ec9d78b7b6e62cdd507c083 upstream.
    
    fadvise64_64() has two 64-bit arguments at the wrong alignment
    for hexagon, which turns them into a 7-argument syscall that is
    not supported by Linux.
    
    The downstream musl port for hexagon actually asks for a 6-argument
    version the same way we do it on arm, csky, powerpc, so make the
    kernel do it the same way to avoid having to change both.
    
    Link: https://github.com/quic/musl/blob/hexagon/arch/hexagon/syscall_arch.h#L78
    Cc: [email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: testunit: discard write requests while old command is running [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Thu Jun 27 13:14:48 2024 +0200

    i2c: testunit: discard write requests while old command is running
    
    [ Upstream commit c116deafd1a5cc1e9739099eb32114e90623209c ]
    
    When clearing registers on new write requests was added, the protection
    for currently running commands was missed leading to concurrent access
    to the testunit registers. Check the flag beforehand.
    
    Fixes: b39ab96aa894 ("i2c: testunit: add support for block process calls")
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: testunit: don't erase registers after STOP [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Thu Jun 27 13:14:47 2024 +0200

    i2c: testunit: don't erase registers after STOP
    
    [ Upstream commit c422b6a630240f706063e0ecbb894aa8491b1fa1 ]
    
    STOP fallsthrough to WRITE_REQUESTED but this became problematic when
    clearing the testunit registers was added to the latter. Actually, there
    is no reason to clear the testunit state after STOP. Doing it when a new
    WRITE_REQUESTED arrives is enough. So, no need to fallthrough, at all.
    
    Fixes: b39ab96aa894 ("i2c: testunit: add support for block process calls")
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ibmvnic: Free any outstanding tx skbs during scrq reset [+ + +]
Author: Nick Child <[email protected]>
Date:   Thu Jun 20 10:23:12 2024 -0500

    ibmvnic: Free any outstanding tx skbs during scrq reset
    
    [ Upstream commit 49bbeb5719c2f56907d3a9623b47c6c15c2c431d ]
    
    There are 2 types of outstanding tx skb's:
    Type 1: Packets that are sitting in the drivers ind_buff that are
    waiting to be batch sent to the NIC. During a device reset, these are
    freed with a call to ibmvnic_tx_scrq_clean_buffer()
    Type 2: Packets that have been sent to the NIC and are awaiting a TX
    completion IRQ. These are free'd during a reset with a call to
    clean_tx_pools()
    
    During any reset which requires us to free the tx irq, ensure that the
    Type 2 skb references are freed. Since the irq is released, it is
    impossible for the NIC to inform of any completions.
    
    Furthermore, later in the reset process is a call to init_tx_pools()
    which marks every entry in the tx pool as free (ie not outstanding).
    So if the driver is to make a call to init_tx_pools(), it must first
    be sure that the tx pool is empty of skb references.
    
    This issue was discovered by observing the following in the logs during
    EEH testing:
            TX free map points to untracked skb (tso_pool 0 idx=4)
            TX free map points to untracked skb (tso_pool 0 idx=5)
            TX free map points to untracked skb (tso_pool 1 idx=36)
    
    Fixes: 65d6470d139a ("ibmvnic: clean pending indirect buffs during reset")
    Signed-off-by: Nick Child <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: accel: fxls8962af: select IIO_BUFFER & IIO_KFIFO_BUF [+ + +]
Author: Alexander Sverdlin <[email protected]>
Date:   Wed Jun 5 22:38:06 2024 +0200

    iio: accel: fxls8962af: select IIO_BUFFER & IIO_KFIFO_BUF
    
    commit a821d7111e3f7c8869961b606714a299bfe20014 upstream.
    
    Provide missing symbols to the module:
    ERROR: modpost: iio_push_to_buffers [drivers/iio/accel/fxls8962af-core.ko] undefined!
    ERROR: modpost: devm_iio_kfifo_buffer_setup_ext [drivers/iio/accel/fxls8962af-core.ko] undefined!
    
    Cc: [email protected]
    Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling")
    Signed-off-by: Alexander Sverdlin <[email protected]>
    Reviewed-by: Sean Nyekjaer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: adc: ad7266: Fix variable checking bug [+ + +]
Author: Fernando Yang <[email protected]>
Date:   Mon Jun 3 15:07:54 2024 -0300

    iio: adc: ad7266: Fix variable checking bug
    
    commit a2b86132955268b2a1703082fbc2d4832fc001b8 upstream.
    
    The ret variable was not checked after iio_device_release_direct_mode(),
    which could possibly cause errors
    
    Fixes: c70df20e3159 ("iio: adc: ad7266: claim direct mode during sensor read")
    Signed-off-by: Fernando Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: chemical: bme680: Fix calibration data variable [+ + +]
Author: Vasileios Amoiridis <[email protected]>
Date:   Thu Jun 6 23:22:54 2024 +0200

    iio: chemical: bme680: Fix calibration data variable
    
    commit b47c0fee73a810c4503c4a94ea34858a1d865bba upstream.
    
    According to the BME68x Sensor API [1], the h6 calibration
    data variable should be an unsigned integer of size 8.
    
    [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x_defs.h#L789
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: chemical: bme680: Fix overflows in compensate() functions [+ + +]
Author: Vasileios Amoiridis <[email protected]>
Date:   Thu Jun 6 23:22:55 2024 +0200

    iio: chemical: bme680: Fix overflows in compensate() functions
    
    commit fdd478c3ae98c3f13628e110dce9b6cfb0d9b3c8 upstream.
    
    There are cases in the compensate functions of the driver that
    there could be overflows of variables due to bit shifting ops.
    These implications were initially discussed here [1] and they
    were mentioned in log message of Commit 1b3bd8592780 ("iio:
    chemical: Add support for Bosch BME680 sensor").
    
    [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: chemical: bme680: Fix pressure value output [+ + +]
Author: Vasileios Amoiridis <[email protected]>
Date:   Thu Jun 6 23:22:53 2024 +0200

    iio: chemical: bme680: Fix pressure value output
    
    commit ae1f7b93b52095be6776d0f34957b4f35dda44d9 upstream.
    
    The IIO standard units are measured in kPa while the driver
    is using hPa.
    
    Apart from checking the userspace value itself, it is mentioned also
    in the Bosch API [1] that the pressure value is in Pascal.
    
    [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x_defs.h#L742
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: chemical: bme680: Fix sensor data read operation [+ + +]
Author: Vasileios Amoiridis <[email protected]>
Date:   Thu Jun 6 23:22:56 2024 +0200

    iio: chemical: bme680: Fix sensor data read operation
    
    commit 4241665e6ea063a9c1d734de790121a71db763fc upstream.
    
    A read operation is happening as follows:
    
    a) Set sensor to forced mode
    b) Sensor measures values and update data registers and sleeps again
    c) Read data registers
    
    In the current implementation the read operation happens immediately
    after the sensor is set to forced mode so the sensor does not have
    the time to update properly the registers. This leads to the following
    2 problems:
    
    1) The first ever value which is read by the register is always wrong
    2) Every read operation, puts the register into forced mode and reads
    the data that were calculated in the previous conversion.
    
    This behaviour was tested in 2 ways:
    
    1) The internal meas_status_0 register was read before and after every
    read operation in order to verify that the data were ready even before
    the register was set to forced mode and also to check that after the
    forced mode was set the new data were not yet ready.
    
    2) Physically changing the temperature and measuring the temperature
    
    This commit adds the waiting time in between the set of the forced mode
    and the read of the data. The function is taken from the Bosch BME68x
    Sensor API [1].
    
    [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L490
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: xilinx-ams: Don't include ams_ctrl_channels in scan_mask [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Mon Mar 11 12:28:00 2024 -0400

    iio: xilinx-ams: Don't include ams_ctrl_channels in scan_mask
    
    [ Upstream commit 89b898c627a49b978a4c323ea6856eacfc21f6ba ]
    
    ams_enable_channel_sequence constructs a "scan_mask" for all the PS and
    PL channels. This works out fine, since scan_index for these channels is
    less than 64. However, it also includes the ams_ctrl_channels, where
    scan_index is greater than 64, triggering undefined behavior. Since we
    don't need these channels anyway, just exclude them.
    
    Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
    Signed-off-by: Sean Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ima: Fix use-after-free on a dentry's dname.name [+ + +]
Author: Stefan Berger <[email protected]>
Date:   Fri Mar 22 10:03:12 2024 -0400

    ima: Fix use-after-free on a dentry's dname.name
    
    [ Upstream commit be84f32bb2c981ca670922e047cdde1488b233de ]
    
    ->d_name.name can change on rename and the earlier value can be freed;
    there are conditions sufficient to stabilize it (->d_lock on dentry,
    ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,
    rename_lock), but none of those are met at any of the sites. Take a stable
    snapshot of the name instead.
    
    Link: https://lore.kernel.org/all/20240202182732.GE2087318@ZenIV/
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Stefan Berger <[email protected]>
    Signed-off-by: Mimi Zohar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: ili210x - fix ili251x_read_touch_data() return value [+ + +]
Author: John Keeping <[email protected]>
Date:   Thu May 23 09:56:24 2024 +0100

    Input: ili210x - fix ili251x_read_touch_data() return value
    
    [ Upstream commit 9f0fad0382124e7e23b3c730fa78818c22c89c0a ]
    
    The caller of this function treats all non-zero values as an error, so
    the return value of i2c_master_recv() cannot be returned directly.
    
    This fixes touch reporting when there are more than 6 active touches.
    
    Fixes: ef536abd3afd1 ("Input: ili210x - define and use chip operations structure")
    Signed-off-by: John Keeping <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/loongson-liointc: Set different ISRs for different cores [+ + +]
Author: Huacai Chen <[email protected]>
Date:   Sat Jun 22 12:33:38 2024 +0800

    irqchip/loongson-liointc: Set different ISRs for different cores
    
    commit a9c3ee5d0fdb069b54902300df6ac822027f3b0a upstream.
    
    The liointc hardware provides separate Interrupt Status Registers (ISR) for
    each core. The current code uses always the ISR of core #0, which works
    during boot because by default all interrupts are routed to core #0.
    
    When the interrupt routing changes in the firmware configuration then this
    causes interrupts to be lost because they are not configured in the
    corresponding core.
    
    Use the core index to access the correct ISR instead of a hardcoded 0.
    
    [ tglx: Massaged changelog ]
    
    Fixes: 0858ed035a85 ("irqchip/loongson-liointc: Add ACPI init support")
    Co-developed-by: Tianli Xiong <[email protected]>
    Signed-off-by: Tianli Xiong <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kbuild: Install dtb files as 0644 in Makefile.dtbinst [+ + +]
Author: Dragan Simic <[email protected]>
Date:   Mon Jun 10 07:21:12 2024 +0200

    kbuild: Install dtb files as 0644 in Makefile.dtbinst
    
    commit 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e upstream.
    
    The compiled dtb files aren't executable, so install them with 0644 as their
    permission mode, instead of defaulting to 0755 for the permission mode and
    installing them with the executable bits set.
    
    Some Linux distributions, including Debian, [1][2][3] already include fixes
    in their kernel package build recipes to change the dtb file permissions to
    0644 in their kernel packages.  These changes, when additionally propagated
    into the long-term kernel versions, will allow such distributions to remove
    their downstream fixes.
    
    [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642
    [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749
    [3] https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.8.12-1/debian/rules.real#L193
    
    Cc: Diederik de Haas <[email protected]>
    Cc: <[email protected]>
    Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more")
    Signed-off-by: Dragan Simic <[email protected]>
    Reviewed-by: Nicolas Schier <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.1.97 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Jul 5 09:32:02 2024 +0200

    Linux 6.1.97
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Kelsey Steele <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
media: dvbdev: Initialize sbuf [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Mon Mar 25 14:50:25 2024 +0000

    media: dvbdev: Initialize sbuf
    
    [ Upstream commit 17d1316de0d7dc1bdc5d6e3ad4efd30a9bf1a381 ]
    
    Because the size passed to copy_from_user() cannot be known beforehand,
    it needs to be checked during runtime with check_object_size. That makes
    gcc believe that the content of sbuf can be used before init.
    
    Fix:
    ./include/linux/thread_info.h:215:17: warning: ‘sbuf’ may be used uninitialized [-Wmaybe-uninitialized]
    
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
MIPS: pci: lantiq: restore reset gpio polarity [+ + +]
Author: Martin Schiller <[email protected]>
Date:   Fri Jun 7 11:04:00 2024 +0200

    MIPS: pci: lantiq: restore reset gpio polarity
    
    [ Upstream commit 277a0363120276645ae598d8d5fea7265e076ae9 ]
    
    Commit 90c2d2eb7ab5 ("MIPS: pci: lantiq: switch to using gpiod API") not
    only switched to the gpiod API, but also inverted / changed the polarity
    of the GPIO.
    
    According to the PCI specification, the RST# pin is an active-low
    signal. However, most of the device trees that have been widely used for
    a long time (mainly in the openWrt project) define this GPIO as
    active-high and the old driver code inverted the signal internally.
    
    Apparently there are actually boards where the reset gpio must be
    operated inverted. For this reason, we cannot use the GPIOD_OUT_LOW/HIGH
    flag for initialization. Instead, we must explicitly set the gpio to
    value 1 in order to take into account any "GPIO_ACTIVE_LOW" flag that
    may have been set.
    
    In order to remain compatible with all these existing device trees, we
    should therefore keep the logic as it was before the commit.
    
    Fixes: 90c2d2eb7ab5 ("MIPS: pci: lantiq: switch to using gpiod API")
    Cc: [email protected]
    Signed-off-by: Martin Schiller <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Fri Jun 21 09:19:14 2024 +0200

    mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems
    
    [ Upstream commit c28947de2bed40217cf256c5d0d16880054fcf13 ]
    
    The following two shared buffer operations make use of the Shared Buffer
    Status Register (SBSR):
    
     # devlink sb occupancy snapshot pci/0000:01:00.0
     # devlink sb occupancy clearmax pci/0000:01:00.0
    
    The register has two masks of 256 bits to denote on which ingress /
    egress ports the register should operate on. Spectrum-4 has more than
    256 ports, so the register was extended by cited commit with a new
    'port_page' field.
    
    However, when filling the register's payload, the driver specifies the
    ports as absolute numbers and not relative to the first port of the port
    page, resulting in memory corruptions [1].
    
    Fix by specifying the ports relative to the first port of the port page.
    
    [1]
    BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0
    Read of size 1 at addr ffff8881068cb00f by task devlink/1566
    [...]
    Call Trace:
     <TASK>
     dump_stack_lvl+0xc6/0x120
     print_report+0xce/0x670
     kasan_report+0xd7/0x110
     mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0
     mlxsw_devlink_sb_occ_snapshot+0x75/0xb0
     devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0
     genl_family_rcv_msg_doit+0x20c/0x300
     genl_rcv_msg+0x567/0x800
     netlink_rcv_skb+0x170/0x450
     genl_rcv+0x2d/0x40
     netlink_unicast+0x547/0x830
     netlink_sendmsg+0x8d4/0xdb0
     __sys_sendto+0x49b/0x510
     __x64_sys_sendto+0xe5/0x1c0
     do_syscall_64+0xc1/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    [...]
    Allocated by task 1:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0x8f/0xa0
     copy_verifier_state+0xbc2/0xfb0
     do_check_common+0x2c51/0xc7e0
     bpf_check+0x5107/0x9960
     bpf_prog_load+0xf0e/0x2690
     __sys_bpf+0x1a61/0x49d0
     __x64_sys_bpf+0x7d/0xc0
     do_syscall_64+0xc1/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 1:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     poison_slab_object+0x109/0x170
     __kasan_slab_free+0x14/0x30
     kfree+0xca/0x2b0
     free_verifier_state+0xce/0x270
     do_check_common+0x4828/0xc7e0
     bpf_check+0x5107/0x9960
     bpf_prog_load+0xf0e/0x2690
     __sys_bpf+0x1a61/0x49d0
     __x64_sys_bpf+0x7d/0xc0
     do_syscall_64+0xc1/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: f8538aec88b4 ("mlxsw: Add support for more than 256 ports in SBSR register")
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Petr Machata <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/page_alloc: Separate THP PCP into movable and non-movable categories [+ + +]
Author: yangge <[email protected]>
Date:   Thu Jun 20 08:59:50 2024 +0800

    mm/page_alloc: Separate THP PCP into movable and non-movable categories
    
    commit bf14ed81f571f8dba31cd72ab2e50fbcc877cc31 upstream.
    
    Since commit 5d0a661d808f ("mm/page_alloc: use only one PCP list for
    THP-sized allocations") no longer differentiates the migration type of
    pages in THP-sized PCP list, it's possible that non-movable allocation
    requests may get a CMA page from the list, in some cases, it's not
    acceptable.
    
    If a large number of CMA memory are configured in system (for example, the
    CMA memory accounts for 50% of the system memory), starting a virtual
    machine with device passthrough will get stuck.  During starting the
    virtual machine, it will call pin_user_pages_remote(..., FOLL_LONGTERM,
    ...) to pin memory.  Normally if a page is present and in CMA area,
    pin_user_pages_remote() will migrate the page from CMA area to non-CMA
    area because of FOLL_LONGTERM flag.  But if non-movable allocation
    requests return CMA memory, migrate_longterm_unpinnable_pages() will
    migrate a CMA page to another CMA page, which will fail to pass the check
    in check_and_migrate_movable_pages() and cause migration endless.
    
    Call trace:
    pin_user_pages_remote
    --__gup_longterm_locked // endless loops in this function
    ----_get_user_pages_locked
    ----check_and_migrate_movable_pages
    ------migrate_longterm_unpinnable_pages
    --------alloc_migration_target
    
    This problem will also have a negative impact on CMA itself.  For example,
    when CMA is borrowed by THP, and we need to reclaim it through cma_alloc()
    or dma_alloc_coherent(), we must move those pages out to ensure CMA's
    users can retrieve that contigous memory.  Currently, CMA's memory is
    occupied by non-movable pages, meaning we can't relocate them.  As a
    result, cma_alloc() is more likely to fail.
    
    To fix the problem above, we add one PCP list for THP, which will not
    introduce a new cacheline for struct per_cpu_pages.  THP will have 2 PCP
    lists, one PCP list is used by MOVABLE allocation, and the other PCP list
    is used by UNMOVABLE allocation.  MOVABLE allocation contains GPF_MOVABLE,
    and UNMOVABLE allocation contains GFP_UNMOVABLE and GFP_RECLAIMABLE.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 5d0a661d808f ("mm/page_alloc: use only one PCP list for THP-sized allocations")
    Signed-off-by: yangge <[email protected]>
    Cc: Baolin Wang <[email protected]>
    Cc: Barry Song <[email protected]>
    Cc: Mel Gorman <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmc: sdhci-brcmstb: check R1_STATUS for erase/trim/discard [+ + +]
Author: Kamal Dasu <[email protected]>
Date:   Mon Jun 3 18:08:34 2024 -0400

    mmc: sdhci-brcmstb: check R1_STATUS for erase/trim/discard
    
    commit d77dc388cd61dfdafe30b98025fa827498378199 upstream.
    
    When erase/trim/discard completion was converted to mmc_poll_for_busy(),
    optional support to poll with the host_ops->card_busy() callback was also
    added.
    
    The common sdhci's ->card_busy() turns out not to be working as expected
    for the sdhci-brcmstb variant, as it keeps returning busy beyond the card's
    busy period. In particular, this leads to the below splat for
    mmc_do_erase() when running a discard (BLKSECDISCARD) operation during
    mkfs.f2fs:
    
        Info: [/dev/mmcblk1p9] Discarding device
        [   39.597258] sysrq: Show Blocked State
        [   39.601183] task:mkfs.f2fs       state:D stack:0     pid:1561  tgid:1561  ppid:1542   flags:0x0000000d
        [   39.610609] Call trace:
        [   39.613098]  __switch_to+0xd8/0xf4
        [   39.616582]  __schedule+0x440/0x4f4
        [   39.620137]  schedule+0x2c/0x48
        [   39.623341]  schedule_hrtimeout_range_clock+0xe0/0x114
        [   39.628562]  schedule_hrtimeout_range+0x10/0x18
        [   39.633169]  usleep_range_state+0x5c/0x90
        [   39.637253]  __mmc_poll_for_busy+0xec/0x128
        [   39.641514]  mmc_poll_for_busy+0x48/0x70
        [   39.645511]  mmc_do_erase+0x1ec/0x210
        [   39.649237]  mmc_erase+0x1b4/0x1d4
        [   39.652701]  mmc_blk_mq_issue_rq+0x35c/0x6ac
        [   39.657037]  mmc_mq_queue_rq+0x18c/0x214
        [   39.661022]  blk_mq_dispatch_rq_list+0x3a8/0x528
        [   39.665722]  __blk_mq_sched_dispatch_requests+0x3a0/0x4ac
        [   39.671198]  blk_mq_sched_dispatch_requests+0x28/0x5c
        [   39.676322]  blk_mq_run_hw_queue+0x11c/0x12c
        [   39.680668]  blk_mq_flush_plug_list+0x200/0x33c
        [   39.685278]  blk_add_rq_to_plug+0x68/0xd8
        [   39.689365]  blk_mq_submit_bio+0x3a4/0x458
        [   39.693539]  __submit_bio+0x1c/0x80
        [   39.697096]  submit_bio_noacct_nocheck+0x94/0x174
        [   39.701875]  submit_bio_noacct+0x1b0/0x22c
        [   39.706042]  submit_bio+0xac/0xe8
        [   39.709424]  blk_next_bio+0x4c/0x5c
        [   39.712973]  blkdev_issue_secure_erase+0x118/0x170
        [   39.717835]  blkdev_common_ioctl+0x374/0x728
        [   39.722175]  blkdev_ioctl+0x8c/0x2b0
        [   39.725816]  vfs_ioctl+0x24/0x40
        [   39.729117]  __arm64_sys_ioctl+0x5c/0x8c
        [   39.733114]  invoke_syscall+0x68/0xec
        [   39.736839]  el0_svc_common.constprop.0+0x70/0xd8
        [   39.741609]  do_el0_svc+0x18/0x20
        [   39.744981]  el0_svc+0x68/0x94
        [   39.748107]  el0t_64_sync_handler+0x88/0x124
        [   39.752455]  el0t_64_sync+0x168/0x16c
    
    To fix the problem let's override the host_ops->card_busy() callback by
    setting it to NULL, which forces the mmc core to poll with a CMD13 and
    checking the R1_STATUS in the mmc_busy_cb() function.
    
    Signed-off-by: Kamal Dasu <[email protected]>
    Fixes: 0d84c3e6a5b2 ("mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    [Ulf: Clarified the commit message]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-pci: Convert PCIBIOS_* return codes to errnos [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Mon May 27 16:24:41 2024 +0300

    mmc: sdhci-pci: Convert PCIBIOS_* return codes to errnos
    
    commit ebc4fc34eae8ddfbef49f2bdaced1bf4167ef80d upstream.
    
    jmicron_pmos() and sdhci_pci_probe() use pci_{read,write}_config_byte()
    that return PCIBIOS_* codes. The return code is then returned as is by
    jmicron_probe() and sdhci_pci_probe(). Similarly, the return code is
    also returned as is from jmicron_resume(). Both probe and resume
    functions should return normal errnos.
    
    Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
    errno before returning them the fix these issues.
    
    Fixes: 7582041ff3d4 ("mmc: sdhci-pci: fix simple_return.cocci warnings")
    Fixes: 45211e215984 ("sdhci: toggle JMicron PMOS setting")
    Cc: [email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci: Do not invert write-protect twice [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Jun 14 11:00:49 2024 +0300

    mmc: sdhci: Do not invert write-protect twice
    
    commit fbd64f902b93fe9658b855b9892ae59ef6ea22b9 upstream.
    
    mmc_of_parse() reads device property "wp-inverted" and sets
    MMC_CAP2_RO_ACTIVE_HIGH if it is true. MMC_CAP2_RO_ACTIVE_HIGH is used
    to invert a write-protect (AKA read-only) GPIO value.
    
    sdhci_get_property() also reads "wp-inverted" and sets
    SDHCI_QUIRK_INVERTED_WRITE_PROTECT which is used to invert the
    write-protect value as well but also acts upon a value read out from the
    SDHCI_PRESENT_STATE register.
    
    Many drivers call both mmc_of_parse() and sdhci_get_property(),
    so that both MMC_CAP2_RO_ACTIVE_HIGH and
    SDHCI_QUIRK_INVERTED_WRITE_PROTECT will be set if the controller has
    device property "wp-inverted".
    
    Amend the logic in sdhci_check_ro() to allow for that possibility,
    so that the write-protect value is not inverted twice.
    
    Also do not invert the value if it is a negative error value. Note that
    callers treat an error the same as not-write-protected, so the result is
    functionally the same in that case.
    
    Also do not invert the value if sdhci host operation ->get_ro() is used.
    None of the users of that callback set SDHCI_QUIRK_INVERTED_WRITE_PROTECT
    directly or indirectly, but two do call mmc_gpio_get_ro(), so leave it to
    them to deal with that if they ever set SDHCI_QUIRK_INVERTED_WRITE_PROTECT
    in the future.
    
    Fixes: 6d5cd068ee59 ("mmc: sdhci: use WP GPIO in sdhci_check_ro()")
    Signed-off-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci: Do not lock spinlock around mmc_gpio_get_ro() [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Jun 14 11:00:50 2024 +0300

    mmc: sdhci: Do not lock spinlock around mmc_gpio_get_ro()
    
    commit ab069ce125965a5e282f7b53b86aee76ab32975c upstream.
    
    sdhci_check_ro() can call mmc_gpio_get_ro() while holding the sdhci
    host->lock spinlock. That would be a problem if the GPIO access done by
    mmc_gpio_get_ro() needed to sleep.
    
    However, host->lock is not needed anyway. The mmc core ensures that host
    operations do not race with each other, and asynchronous callbacks like the
    interrupt handler, software timeouts, completion work etc, cannot affect
    sdhci_check_ro().
    
    So remove the locking.
    
    Fixes: 6d5cd068ee59 ("mmc: sdhci: use WP GPIO in sdhci_check_ro()")
    Signed-off-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mtd: partitions: redboot: Added conversion of operands to a larger type [+ + +]
Author: Denis Arefev <[email protected]>
Date:   Fri Mar 15 12:37:58 2024 +0300

    mtd: partitions: redboot: Added conversion of operands to a larger type
    
    [ Upstream commit 1162bc2f8f5de7da23d18aa4b7fbd4e93c369c50 ]
    
    The value of an arithmetic expression directory * master->erasesize is
    subject to overflow due to a failure to cast operands to a larger data
    type before perfroming arithmetic
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Denis Arefev <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
net/dpaa2: Avoid explicit cpumask var allocation on stack [+ + +]
Author: Dawei Li <[email protected]>
Date:   Sun Mar 31 13:34:41 2024 +0800

    net/dpaa2: Avoid explicit cpumask var allocation on stack
    
    [ Upstream commit d33fe1714a44ff540629b149d8fab4ac6967585c ]
    
    For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
    variable on stack is not recommended since it can cause potential stack
    overflow.
    
    Instead, kernel code should always use *cpumask_var API(s) to allocate
    cpumask var in config-neutral way, leaving allocation strategy to
    CONFIG_CPUMASK_OFFSTACK.
    
    Use *cpumask_var API(s) to address it.
    
    Signed-off-by: Dawei Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/iucv: Avoid explicit cpumask var allocation on stack [+ + +]
Author: Dawei Li <[email protected]>
Date:   Sun Mar 31 13:34:40 2024 +0800

    net/iucv: Avoid explicit cpumask var allocation on stack
    
    [ Upstream commit be4e1304419c99a164b4c0e101c7c2a756b635b9 ]
    
    For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
    variable on stack is not recommended since it can cause potential stack
    overflow.
    
    Instead, kernel code should always use *cpumask_var API(s) to allocate
    cpumask var in config-neutral way, leaving allocation strategy to
    CONFIG_CPUMASK_OFFSTACK.
    
    Use *cpumask_var API(s) to address it.
    
    Signed-off-by: Dawei Li <[email protected]>
    Reviewed-by: Alexandra Winter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new [+ + +]
Author: Oleksij Rempel <[email protected]>
Date:   Fri Nov 17 13:49:59 2023 +0100

    net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
    
    commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream.
    
    This patch enhances error handling in scenarios with RTS (Request to
    Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
    backtraces with a new error handling method. This provides clearer error
    messages and allows for the early termination of problematic sessions.
    Previously, sessions were only released at the end of j1939_xtp_rx_rts().
    
    Potentially this could be reproduced with something like:
    testj1939 -r vcan0:0x80 &
    while true; do
            # send first RTS
            cansend vcan0 18EC8090#1014000303002301;
            # send second RTS
            cansend vcan0 18EC8090#1014000303002301;
            # send abort
            cansend vcan0 18EC8090#ff00000000002301;
    done
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Reported-by: [email protected]
    Cc: [email protected]
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: can: j1939: Initialize unused data in j1939_send_one() [+ + +]
Author: Shigeru Yoshida <[email protected]>
Date:   Fri May 17 12:59:53 2024 +0900

    net: can: j1939: Initialize unused data in j1939_send_one()
    
    commit b7cdf1dd5d2a2d8200efd98d1893684db48fe134 upstream.
    
    syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
    creates full frame including unused data, but it doesn't initialize
    it. This causes the kernel-infoleak issue. Fix this by initializing
    unused data.
    
    [1]
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
    BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
    BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
    BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
    BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
    BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
     instrument_copy_to_user include/linux/instrumented.h:114 [inline]
     copy_to_user_iter lib/iov_iter.c:24 [inline]
     iterate_ubuf include/linux/iov_iter.h:29 [inline]
     iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
     iterate_and_advance include/linux/iov_iter.h:271 [inline]
     _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
     copy_to_iter include/linux/uio.h:196 [inline]
     memcpy_to_msg include/linux/skbuff.h:4113 [inline]
     raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
     sock_recvmsg_nosec net/socket.c:1046 [inline]
     sock_recvmsg+0x2c4/0x340 net/socket.c:1068
     ____sys_recvmsg+0x18a/0x620 net/socket.c:2803
     ___sys_recvmsg+0x223/0x840 net/socket.c:2845
     do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
     __sys_recvmmsg net/socket.c:3018 [inline]
     __do_sys_recvmmsg net/socket.c:3041 [inline]
     __se_sys_recvmmsg net/socket.c:3034 [inline]
     __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
     x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
     slab_post_alloc_hook mm/slub.c:3804 [inline]
     slab_alloc_node mm/slub.c:3845 [inline]
     kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
     kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
     __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
     alloc_skb include/linux/skbuff.h:1313 [inline]
     alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
     sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
     sock_alloc_send_skb include/net/sock.h:1842 [inline]
     j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
     j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
     j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x30f/0x380 net/socket.c:745
     ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
     __sys_sendmsg net/socket.c:2667 [inline]
     __do_sys_sendmsg net/socket.c:2676 [inline]
     __se_sys_sendmsg net/socket.c:2674 [inline]
     __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
     x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Bytes 12-15 of 16 are uninitialized
    Memory access of size 16 starts at ffff888120969690
    Data copied to user address 00000000200017c0
    
    CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=5681e40d297b30f5b513
    Acked-by: Oleksij Rempel <[email protected]>
    Signed-off-by: Shigeru Yoshida <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Cc: [email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: can: j1939: recover socket queue on CAN bus error during BAM transmission [+ + +]
Author: Oleksij Rempel <[email protected]>
Date:   Tue May 28 09:06:48 2024 +0200

    net: can: j1939: recover socket queue on CAN bus error during BAM transmission
    
    commit 9ad1da14ab3bf23087ae45fe399d84a109ddb81a upstream.
    
    Addresses an issue where a CAN bus error during a BAM transmission
    could stall the socket queue, preventing further transmissions even
    after the bus error is resolved. The fix activates the next queued
    session after the error recovery, allowing communication to continue.
    
    Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol")
    Cc: [email protected]
    Reported-by: Alexander Hölzl <[email protected]>
    Tested-by: Alexander Hölzl <[email protected]>
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Cc: [email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: microchip: fix initial port flush problem [+ + +]
Author: Tristram Ha <[email protected]>
Date:   Tue Jun 18 17:16:42 2024 -0700

    net: dsa: microchip: fix initial port flush problem
    
    [ Upstream commit ad53f5f54f351e967128edbc431f0f26427172cf ]
    
    The very first flush in any port will flush all learned addresses in all
    ports.  This can be observed by unplugging the cable from one port while
    additional ports are connected and dumping the fdb entries.
    
    This problem is caused by the initially wrong value programmed to the
    REG_SW_LUE_CTRL_1 register.  Setting SW_FLUSH_STP_TABLE and
    SW_FLUSH_MSTP_TABLE bits does not have an immediate effect.  It is when
    ksz9477_flush_dyn_mac_table() is called then the SW_FLUSH_STP_TABLE bit
    takes effect and flushes all learned entries.  After that call both bits
    are reset and so the next port flush will not cause such problem again.
    
    Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
    Signed-off-by: Tristram Ha <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: microchip: fix wrong register write when masking interrupt [+ + +]
Author: Tristram Ha <[email protected]>
Date:   Fri Jun 21 15:34:22 2024 -0700

    net: dsa: microchip: fix wrong register write when masking interrupt
    
    [ Upstream commit b1c4b4d45263241ec6c2405a8df8265d4b58e707 ]
    
    The switch global port interrupt mask, REG_SW_PORT_INT_MASK__4, is
    defined as 0x001C in ksz9477_reg.h.  The designers used 32-bit value in
    anticipation for increase of port count in future product but currently
    the maximum port count is 7 and the effective value is 0x7F in register
    0x001F.  Each port has its own interrupt mask and is defined as 0x#01F.
    It uses only 4 bits for different interrupts.
    
    The developer who implemented the current interrupt mechanism in the
    switch driver noticed there are similarities between the mechanism to
    mask port interrupts in global interrupt and individual interrupts in
    each port and so used the same code to handle these interrupts.  He
    updated the code to use the new macro REG_SW_PORT_INT_MASK__1 which is
    defined as 0x1F in ksz_common.h but he forgot to update the 32-bit write
    to 8-bit as now the mask registers are 0x1F and 0x#01F.
    
    In addition all KSZ switches other than the KSZ9897/KSZ9893 and LAN937X
    families use only 8-bit access and so this common code will eventually
    be changed to accommodate them.
    
    Fixes: e1add7dd6183 ("net: dsa: microchip: use common irq routines for girq and pirq")
    Signed-off-by: Tristram Ha <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: microchip: use collision based back pressure mode [+ + +]
Author: Enguerrand de Ribaucourt <[email protected]>
Date:   Fri Jun 21 16:43:21 2024 +0200

    net: dsa: microchip: use collision based back pressure mode
    
    [ Upstream commit d963c95bc9840d070a788c35e41b715a648717f7 ]
    
    Errata DS80000758 states that carrier sense back pressure mode can cause
    link down issues in 100BASE-TX half duplex mode. The datasheet also
    recommends to always use the collision based back pressure mode.
    
    Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
    Signed-off-by: Enguerrand de Ribaucourt <[email protected]>
    Reviewed-by: Woojung Huh <[email protected]>
    Acked-by: Arun Ramadoss <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: micrel: add Microchip KSZ 9477 to the device table [+ + +]
Author: Enguerrand de Ribaucourt <[email protected]>
Date:   Fri Jun 21 16:43:20 2024 +0200

    net: phy: micrel: add Microchip KSZ 9477 to the device table
    
    [ Upstream commit 54a4e5c16382e871c01dd82b47e930fdce30406b ]
    
    PHY_ID_KSZ9477 was supported but not added to the device table passed to
    MODULE_DEVICE_TABLE.
    
    Fixes: fc3973a1fa09 ("phy: micrel: add Microchip KSZ 9477 Switch PHY support")
    Signed-off-by: Enguerrand de Ribaucourt <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: ax88179_178a: improve link status logs [+ + +]
Author: Jose Ignacio Tornos Martinez <[email protected]>
Date:   Thu Jun 20 15:34:31 2024 +0200

    net: usb: ax88179_178a: improve link status logs
    
    commit 058722ee350c0bdd664e467156feb2bf5d9cc271 upstream.
    
    Avoid spurious link status logs that may ultimately be wrong; for example,
    if the link is set to down with the cable plugged, then the cable is
    unplugged and after this the link is set to up, the last new log that is
    appearing is incorrectly telling that the link is up.
    
    In order to avoid errors, show link status logs after link_reset
    processing, and in order to avoid spurious as much as possible, only show
    the link loss when some link status change is detected.
    
    cc: [email protected]
    Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
    Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Wed Jun 26 23:15:38 2024 +0200

    netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
    
    [ Upstream commit 7931d32955e09d0a11b1fe0b6aac1bfa061c005c ]
    
    register store validation for NFT_DATA_VALUE is conditional, however,
    the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This
    only requires a new helper function to infer the register type from the
    set datatype so this conditional check can be removed. Otherwise,
    pointer to chain object can be leaked through the registers.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Reported-by: Linus Torvalds <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: use timestamp to check for set element timeout [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Thu Jun 27 01:53:13 2024 +0200

    netfilter: nf_tables: use timestamp to check for set element timeout
    
    commit 7395dfacfff65e9938ac0889dafa1ab01e987d15 upstream
    
    Add a timestamp field at the beginning of the transaction, store it
    in the nftables per-netns area.
    
    Update set backend .insert, .deactivate and sync gc path to use the
    timestamp, this avoids that an element expires while control plane
    transaction is still unfinished.
    
    .lookup and .update, which are used from packet path, still use the
    current time to check if the element has expired. And .get path and dump
    also since this runs lockless under rcu read size lock. Then, there is
    async gc which also needs to check the current time since it runs
    asynchronously from a workqueue.
    
    Fixes: c3e1b005ed1c ("netfilter: nf_tables: add set element timeout support")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs: drop the incorrect assertion in nfs_swap_rw() [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Tue Jun 18 18:56:47 2024 +1200

    nfs: drop the incorrect assertion in nfs_swap_rw()
    
    commit 54e7d59841dab977f6cb1183d658b1b82c9f4e94 upstream.
    
    Since commit 2282679fb20b ("mm: submit multipage write for SWP_FS_OPS
    swap-space"), we can plug multiple pages then unplug them all together.
    That means iov_iter_count(iter) could be way bigger than PAGE_SIZE, it
    actually equals the size of iov_iter_npages(iter, INT_MAX).
    
    Note this issue has nothing to do with large folios as we don't support
    THP_SWPOUT to non-block devices.
    
    [[email protected]: figure out the cause and correct the commit message]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 2282679fb20b ("mm: submit multipage write for SWP_FS_OPS swap-space")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Barry Song <[email protected]>
    Closes: https://lore.kernel.org/linux-mm/[email protected]/
    Reviewed-by: Martin Wege <[email protected]>
    Cc: NeilBrown <[email protected]>
    Cc: Anna Schumaker <[email protected]>
    Cc: Steve French <[email protected]>
    Cc: Trond Myklebust <[email protected]>
    Cc: Chuanhua Han <[email protected]>
    Cc: Ryan Roberts <[email protected]>
    Cc: Chris Li <[email protected]>
    Cc: "Huang, Ying" <[email protected]>
    Cc: Jeff Layton <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvme: fixup comment for nvme RDMA Provider Type [+ + +]
Author: Hannes Reinecke <[email protected]>
Date:   Mon Jun 17 09:27:27 2024 +0200

    nvme: fixup comment for nvme RDMA Provider Type
    
    [ Upstream commit f80a55fa90fa76d01e3fffaa5d0413e522ab9a00 ]
    
    PRTYPE is the provider type, not the QP service type.
    
    Fixes: eb793e2c9286 ("nvme.h: add NVMe over Fabrics definitions")
    Signed-off-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ocfs2: fix DIO failure due to insufficient transaction credits [+ + +]
Author: Jan Kara <[email protected]>
Date:   Fri Jun 14 16:52:43 2024 +0200

    ocfs2: fix DIO failure due to insufficient transaction credits
    
    commit be346c1a6eeb49d8fda827d2a9522124c2f72f36 upstream.
    
    The code in ocfs2_dio_end_io_write() estimates number of necessary
    transaction credits using ocfs2_calc_extend_credits().  This however does
    not take into account that the IO could be arbitrarily large and can
    contain arbitrary number of extents.
    
    Extent tree manipulations do often extend the current transaction but not
    in all of the cases.  For example if we have only single block extents in
    the tree, ocfs2_mark_extent_written() will end up calling
    ocfs2_replace_extent_rec() all the time and we will never extend the
    current transaction and eventually exhaust all the transaction credits if
    the IO contains many single block extents.  Once that happens a
    WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
    jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
    this error.  This was actually triggered by one of our customers on a
    heavily fragmented OCFS2 filesystem.
    
    To fix the issue make sure the transaction always has enough credits for
    one extent insert before each call of ocfs2_mark_extent_written().
    
    Heming Zhao said:
    
    ------
    PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
    
    PID: xxx  TASK: xxxx  CPU: 5  COMMAND: "SubmitThread-CA"
      #0 machine_kexec at ffffffff8c069932
      #1 __crash_kexec at ffffffff8c1338fa
      #2 panic at ffffffff8c1d69b9
      #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
      #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
      #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
      #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
      #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
      #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
      #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
    #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
    #11 dio_complete at ffffffff8c2b9fa7
    #12 do_blockdev_direct_IO at ffffffff8c2bc09f
    #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
    #14 generic_file_direct_write at ffffffff8c1dcf14
    #15 __generic_file_write_iter at ffffffff8c1dd07b
    #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
    #17 aio_write at ffffffff8c2cc72e
    #18 kmem_cache_alloc at ffffffff8c248dde
    #19 do_io_submit at ffffffff8c2ccada
    #20 do_syscall_64 at ffffffff8c004984
    #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: c15471f79506 ("ocfs2: fix sparse file & data ordering issue in direct io")
    Signed-off-by: Jan Kara <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Reviewed-by: Heming Zhao <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
parisc: use correct compat recv/recvfrom syscalls [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jun 19 14:27:55 2024 +0200

    parisc: use correct compat recv/recvfrom syscalls
    
    [ Upstream commit 20a50787349fadf66ac5c48f62e58d753878d2bb ]
    
    Johannes missed parisc back when he introduced the compat version
    of these syscalls, so receiving cmsg messages that require a compat
    conversion is still broken.
    
    Use the correct calls like the other architectures do.
    
    Fixes: 1dacc76d0014 ("net/compat/wext: send different messages to compat tasks")
    Acked-by: Helge Deller <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

parisc: use generic sys_fanotify_mark implementation [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 7 13:40:45 2024 +0200

    parisc: use generic sys_fanotify_mark implementation
    
    [ Upstream commit 403f17a330732a666ae793f3b15bc75bb5540524 ]
    
    The sys_fanotify_mark() syscall on parisc uses the reverse word order
    for the two halves of the 64-bit argument compared to all syscalls on
    all 32-bit architectures. As far as I can tell, the problem is that
    the function arguments on parisc are sorted backwards (26, 25, 24, 23,
    ...) compared to everyone else, so the calling conventions of using an
    even/odd register pair in native word order result in the lower word
    coming first in function arguments, matching the expected behavior
    on little-endian architectures. The system call conventions however
    ended up matching what the other 32-bit architectures do.
    
    A glibc cleanup in 2020 changed the userspace behavior in a way that
    handles all architectures consistently, but this inadvertently broke
    parisc32 by changing to the same method as everyone else.
    
    The change made it into glibc-2.35 and subsequently into debian 12
    (bookworm), which is the latest stable release. This means we
    need to choose between reverting the glibc change or changing the
    kernel to match it again, but either hange will leave some systems
    broken.
    
    Pick the option that is more likely to help current and future
    users and change the kernel to match current glibc. This also
    means the behavior is now consistent across architectures, but
    it breaks running new kernels with old glibc builds before 2.35.
    
    Link: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d150181d73d9
    Link: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/arch/parisc/kernel/sys_parisc.c?h=57b1dfbd5b4a39d
    Cc: Adhemerval Zanella <[email protected]>
    Tested-by: Helge Deller <[email protected]>
    Acked-by: Helge Deller <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>

 
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER [+ + +]
Author: Hagar Hemdan <[email protected]>
Date:   Tue Jun 4 08:58:38 2024 +0000

    pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
    
    [ Upstream commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 ]
    
    In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
    add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
    calls pinctrl_free(). However, pinctrl_free() attempts to acquire
    pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
    a potential deadlock.
    
    This patch resolves the issue by releasing pinctrl_maps_mutex before
    calling pinctrl_free(), preventing the deadlock.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
    Suggested-by: Maximilian Heyne <[email protected]>
    Signed-off-by: Hagar Hemdan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: qcom: spmi-gpio: drop broken pm8008 support [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Wed May 29 18:29:52 2024 +0200

    pinctrl: qcom: spmi-gpio: drop broken pm8008 support
    
    commit 8da86499d4cd125a9561f9cd1de7fba99b0aecbf upstream.
    
    The SPMI GPIO driver assumes that the parent device is an SPMI device
    and accesses random data when backcasting the parent struct device
    pointer for non-SPMI devices.
    
    Fortunately this does not seem to cause any issues currently when the
    parent device is an I2C client like the PM8008, but this could change if
    the structures are reorganised (e.g. using structure randomisation).
    
    Notably the interrupt implementation is also broken for non-SPMI devices.
    
    Also note that the two GPIO pins on PM8008 are used for interrupts and
    reset so their practical use should be limited.
    
    Drop the broken GPIO support for PM8008 for now.
    
    Fixes: ea119e5a482a ("pinctrl: qcom-pmic-gpio: Add support for pm8008")
    Cc: [email protected]      # 5.13
    Reviewed-by: Bryan O'Donoghue <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins [+ + +]
Author: Huang-Huang Bao <[email protected]>
Date:   Thu Jun 6 20:57:52 2024 +0800

    pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins
    
    [ Upstream commit e8448a6c817c2aa6c6af785b1d45678bd5977e8d ]
    
    The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width,
    correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is
    recalculated so it remain unchanged.
    
    The pinmux bits for those pins are not explicitly specified in RK3328
    TRM, however we can get hint from pad name and its correspinding IOMUX
    setting for pins in interface descriptions. The correspinding IOMIX
    settings for GPIO2-B0 to GPIO2-B6 can be found in the same row next to
    occurrences of following pad names in RK3328 TRM.
    
    GPIO2-B0: IO_SPIclkm0_GPIO2B0vccio5
    GPIO2-B1: IO_SPItxdm0_GPIO2B1vccio5
    GPIO2-B2: IO_SPIrxdm0_GPIO2B2vccio5
    GPIO2-B3: IO_SPIcsn0m0_GPIO2B3vccio5
    GPIO2-B4: IO_SPIcsn1m0_FLASHvol_sel_GPIO2B4vccio5
    GPIO2-B5: IO_ I2C2sda_TSADCshut_GPIO2B5vccio5
    GPIO2-B6: IO_ I2C2scl_GPIO2B6vccio5
    
    This fix has been tested on NanoPi R2S for fixing confliting pinmux bits
    between GPIO2-B7 with GPIO2-B5.
    
    Signed-off-by: Huang-Huang Bao <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins [+ + +]
Author: Huang-Huang Bao <[email protected]>
Date:   Thu Jun 6 20:57:53 2024 +0800

    pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins
    
    [ Upstream commit 5ef6914e0bf578357b4c906ffe6b26e7eedb8ccf ]
    
    The pinmux bits for GPIO3-B1 to GPIO3-B6 pins are not explicitly
    specified in RK3328 TRM, however we can get hint from pad name and its
    correspinding IOMUX setting for pins in interface descriptions. The
    correspinding IOMIX settings for these pins can be found in the same
    row next to occurrences of following pad names in RK3328 TRM.
    
    GPIO3-B1:  IO_TSPd5m0_CIFdata5m0_GPIO3B1vccio6
    GPIO3-B2: IO_TSPd6m0_CIFdata6m0_GPIO3B2vccio6
    GPIO3-B3: IO_TSPd7m0_CIFdata7m0_GPIO3B3vccio6
    GPIO3-B4: IO_CARDclkm0_GPIO3B4vccio6
    GPIO3-B5: IO_CARDrstm0_GPIO3B5vccio6
    GPIO3-B6: IO_CARDdetm0_GPIO3B6vccio6
    
    Add pinmux data to rk3328_mux_recalced_data as mux register offset for
    these pins does not follow rockchip convention.
    
    Signed-off-by: Huang-Huang Bao <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: rockchip: fix pinmux reset in rockchip_pmx_set [+ + +]
Author: Huang-Huang Bao <[email protected]>
Date:   Thu Jun 6 20:57:55 2024 +0800

    pinctrl: rockchip: fix pinmux reset in rockchip_pmx_set
    
    [ Upstream commit 4ea4d4808e342ddf89ba24b93ffa2057005aaced ]
    
    rockchip_pmx_set reset all pinmuxs in group to 0 in the case of error,
    add missing bank data retrieval in that code to avoid setting mux on
    unexpected pins.
    
    Fixes: 14797189b35e ("pinctrl: rockchip: add return value to rockchip_set_mux")
    Reviewed-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Huang-Huang Bao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: rockchip: use dedicated pinctrl type for RK3328 [+ + +]
Author: Huang-Huang Bao <[email protected]>
Date:   Thu Jun 6 20:57:54 2024 +0800

    pinctrl: rockchip: use dedicated pinctrl type for RK3328
    
    [ Upstream commit 01b4b1d1cec48ef4c26616c2fc4600b2c9fec05a ]
    
    rk3328_pin_ctrl uses type of RK3288 which has a hack in
    rockchip_pinctrl_suspend and rockchip_pinctrl_resume to restore GPIO6-C6
    at assume, the hack is not applicable to RK3328 as GPIO6 is not even
    exist in it. So use a dedicated pinctrl type to skip this hack.
    
    Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
    Reviewed-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Huang-Huang Bao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc: restore some missing spu syscalls [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Apr 24 16:36:13 2024 +0200

    powerpc: restore some missing spu syscalls
    
    [ Upstream commit b1e31c134a8ab2e8f5fd62323b6b45a950ac704d ]
    
    A couple of system calls were inadventently removed from the table during
    a bugfix for 32-bit powerpc entry. Restore the original behavior.
    
    Fixes: e23750623835 ("powerpc/32: fix syscall wrappers with 64-bit arguments of unaligned register-pairs")
    Acked-by: Michael Ellerman <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pwm: stm32: Refuse too small period requests [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Fri Jun 21 16:37:12 2024 +0200

    pwm: stm32: Refuse too small period requests
    
    commit c45fcf46ca2368dafe7e5c513a711a6f0f974308 upstream.
    
    If period_ns is small, prd might well become 0. Catch that case because
    otherwise with
    
            regmap_write(priv->regmap, TIM_ARR, prd - 1);
    
    a few lines down quite a big period is configured.
    
    Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
    Cc: [email protected]
    Reviewed-by: Trevor Gamblin <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/b86f62f099983646f97eeb6bfc0117bb2d0c340d.1718979150.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
randomize_kstack: Remove non-functional per-arch entropy filtering [+ + +]
Author: Kees Cook <[email protected]>
Date:   Wed Jun 19 14:47:15 2024 -0700

    randomize_kstack: Remove non-functional per-arch entropy filtering
    
    [ Upstream commit 6db1208bf95b4c091897b597c415e11edeab2e2d ]
    
    An unintended consequence of commit 9c573cd31343 ("randomize_kstack:
    Improve entropy diffusion") was that the per-architecture entropy size
    filtering reduced how many bits were being added to the mix, rather than
    how many bits were being used during the offsetting. All architectures
    fell back to the existing default of 0x3FF (10 bits), which will consume
    at most 1KiB of stack space. It seems that this is working just fine,
    so let's avoid the confusion and update everything to use the default.
    
    The prior intent of the per-architecture limits were:
    
      arm64: capped at 0x1FF (9 bits), 5 bits effective
      powerpc: uncapped (10 bits), 6 or 7 bits effective
      riscv: uncapped (10 bits), 6 bits effective
      x86: capped at 0xFF (8 bits), 5 (x86_64) or 6 (ia32) bits effective
      s390: capped at 0xFF (8 bits), undocumented effective entropy
    
    Current discussion has led to just dropping the original per-architecture
    filters. The additional entropy appears to be safe for arm64, x86,
    and s390. Quoting Arnd, "There is no point pretending that 15.75KB is
    somehow safe to use while 15.00KB is not."
    
    Co-developed-by: Yuntao Liu <[email protected]>
    Signed-off-by: Yuntao Liu <[email protected]>
    Fixes: 9c573cd31343 ("randomize_kstack: Improve entropy diffusion")
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Arnd Bergmann <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Acked-by: Heiko Carstens <[email protected]> # s390
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/restrack: Fix potential invalid address access [+ + +]
Author: Wenchao Hao <[email protected]>
Date:   Mon Mar 18 17:23:20 2024 +0800

    RDMA/restrack: Fix potential invalid address access
    
    [ Upstream commit ca537a34775c103f7b14d7bbd976403f1d1525d8 ]
    
    struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
    in ib_create_cq(), while if the module exited but forgot del this
    rdma_restrack_entry, it would cause a invalid address access in
    rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
    
    These code is used to help find one forgotten PD release in one of the
    ULPs. But it is not needed anymore, so delete them.
    
    Signed-off-by: Wenchao Hao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "cpufreq: amd-pstate: Fix the inconsistency in max frequency units" [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Jul 2 11:14:23 2024 +0200

    Revert "cpufreq: amd-pstate: Fix the inconsistency in max frequency units"
    
    This reverts commit 82590ce3a0d0f26d06b0a70886ca2d444e64acbf which is
    commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream.
    
    It causes a regression in kernels older than 6.9.y, so drop it from
    here.
    
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Lars Wendler <[email protected]>
    Cc: Dhananjay Ugwekar <[email protected]>
    Cc: Mario Limonciello <[email protected]>
    Cc: Gautham R. Shenoy <[email protected]>
    Cc: Peter Jung <[email protected]>
    Cc: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "MIPS: pci: lantiq: restore reset gpio polarity" [+ + +]
Author: Thomas Bogendoerfer <[email protected]>
Date:   Thu Jun 13 10:17:09 2024 +0200

    Revert "MIPS: pci: lantiq: restore reset gpio polarity"
    
    commit 6e5aee08bd2517397c9572243a816664f2ead547 upstream.
    
    This reverts commit 277a0363120276645ae598d8d5fea7265e076ae9.
    
    While fixing old boards with broken DTs, this change will break
    newer ones with correct gpio polarity annotation.
    
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv: stacktrace: convert arch_stack_walk() to noinstr [+ + +]
Author: Andy Chiu <[email protected]>
Date:   Thu Jun 13 15:11:06 2024 +0800

    riscv: stacktrace: convert arch_stack_walk() to noinstr
    
    [ Upstream commit 23b2188920a25e88d447dd7d819a0b0f62fb4455 ]
    
    arch_stack_walk() is called intensively in function_graph when the
    kernel is compiled with CONFIG_TRACE_IRQFLAGS. As a result, the kernel
    logs a lot of arch_stack_walk and its sub-functions into the ftrace
    buffer. However, these functions should not appear on the trace log
    because they are part of the ftrace itself. This patch references what
    arm64 does for the smae function. So it further prevent the re-enter
    kprobe issue, which is also possible on riscv.
    
    Related-to: commit 0fbcd8abf337 ("arm64: Prohibit instrumentation on arch_stack_walk()")
    Fixes: 680341382da5 ("riscv: add CALLER_ADDRx support")
    Signed-off-by: Andy Chiu <[email protected]>
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/pci: Add missing virt_to_phys() for directed DIBV [+ + +]
Author: Niklas Schnelle <[email protected]>
Date:   Tue Jun 11 14:06:31 2024 +0200

    s390/pci: Add missing virt_to_phys() for directed DIBV
    
    [ Upstream commit 4181b51c38875de9f6f11248fa0bcf3246c19c82 ]
    
    In commit 4e4dc65ab578 ("s390/pci: use phys_to_virt() for AIBVs/DIBVs")
    the setting of dibv_addr was missed when adding virt_to_phys(). This
    only affects systems with directed interrupt delivery enabled which are
    not generally available.
    
    Fixes: 4e4dc65ab578 ("s390/pci: use phys_to_virt() for AIBVs/DIBVs")
    Reviewed-by: Heiko Carstens <[email protected]>
    Signed-off-by: Niklas Schnelle <[email protected]>
    Signed-off-by: Vasily Gorbik <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250_omap: Fix Errata i2310 with RX FIFO level check [+ + +]
Author: Udit Kumar <[email protected]>
Date:   Tue Jun 25 21:37:25 2024 +0530

    serial: 8250_omap: Fix Errata i2310 with RX FIFO level check
    
    commit c128a1b0523b685c8856ddc0ac0e1caef1fdeee5 upstream.
    
    Errata i2310[0] says, Erroneous timeout can be triggered,
    if this Erroneous interrupt is not cleared then it may leads
    to storm of interrupts.
    
    Commit 9d141c1e6157 ("serial: 8250_omap: Implementation of Errata i2310")
    which added the workaround but missed ensuring RX FIFO is really empty
    before applying the errata workaround as recommended in the errata text.
    Fix this by adding back check for UART_OMAP_RX_LVL to be 0 for
    workaround to take effect.
    
    [0] https://www.ti.com/lit/pdf/sprz536 page 23
    
    Fixes: 9d141c1e6157 ("serial: 8250_omap: Implementation of Errata i2310")
    Cc: [email protected]
    Reported-by: Vignesh Raghavendra <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Udit Kumar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: 8250_omap: Implementation of Errata i2310 [+ + +]
Author: Udit Kumar <[email protected]>
Date:   Wed Jun 19 16:29:03 2024 +0530

    serial: 8250_omap: Implementation of Errata i2310
    
    commit 9d141c1e615795eeb93cd35501ad144ee997a826 upstream.
    
    As per Errata i2310[0], Erroneous timeout can be triggered,
    if this Erroneous interrupt is not cleared then it may leads
    to storm of interrupts, therefore apply Errata i2310 solution.
    
    [0] https://www.ti.com/lit/pdf/sprz536 page 23
    
    Fixes: b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs")
    Cc: [email protected]
    Signed-off-by: Udit Kumar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: imx: only set receiver level if it is zero [+ + +]
Author: Stefan Eichenberger <[email protected]>
Date:   Wed Jul 3 13:25:40 2024 +0200

    serial: imx: only set receiver level if it is zero
    
    commit 9706fc87b4cff0ac4f5d5d62327be83fe72e3108 upstream.
    
    With commit a81dbd0463ec ("serial: imx: set receiver level before
    starting uart") we set the receiver level to its default value. This
    caused a regression when using SDMA, where the receiver level is 9
    instead of 8 (default). This change will first check if the receiver
    level is zero and only then set it to the default. This still avoids the
    interrupt storm when the receiver level is zero.
    
    Fixes: a81dbd0463ec ("serial: imx: set receiver level before starting uart")
    Cc: stable <[email protected]>
    Signed-off-by: Stefan Eichenberger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: imx: set receiver level before starting uart [+ + +]
Author: Stefan Eichenberger <[email protected]>
Date:   Fri Jun 21 17:37:49 2024 +0200

    serial: imx: set receiver level before starting uart
    
    commit a81dbd0463eca317eee44985a66aa6cc2ce5c101 upstream.
    
    Set the receiver level to something > 0 before calling imx_uart_start_rx
    in rs485_config. This is necessary to avoid an interrupt storm that
    might prevent the system from booting. This was seen on an i.MX7 device
    when the rs485-rts-active-low property was active in the device tree.
    
    Fixes: 6d215f83e5fc ("serial: imx: warn user when using unsupported configuration")
    Cc: stable <[email protected]>
    Signed-off-by: Stefan Eichenberger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sh: rework sync_file_range ABI [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Jun 11 22:12:43 2024 +0200

    sh: rework sync_file_range ABI
    
    commit 30766f1105d6d2459c3b9fe34a3e52b637a72950 upstream.
    
    The unusual function calling conventions on SuperH ended up causing
    sync_file_range to have the wrong argument order, with the 'flags'
    argument getting sorted before 'nbytes' by the compiler.
    
    In userspace, I found that musl, glibc, uclibc and strace all expect the
    normal calling conventions with 'nbytes' last, so changing the kernel
    to match them should make all of those work.
    
    In order to be able to also fix libc implementations to work with existing
    kernels, they need to be able to tell which ABI is used. An easy way
    to do this is to add yet another system call using the sync_file_range2
    ABI that works the same on all architectures.
    
    Old user binaries can now work on new kernels, and new binaries can
    try the new sync_file_range2() to work with new kernels or fall back
    to the old sync_file_range() version if that doesn't exist.
    
    Cc: [email protected]
    Fixes: 75c92acdd5b1 ("sh: Wire up new syscalls.")
    Acked-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
soc: ti: wkup_m3_ipc: Send NULL dummy message instead of pointer message [+ + +]
Author: Andrew Davis <[email protected]>
Date:   Mon Mar 25 11:55:07 2024 -0500

    soc: ti: wkup_m3_ipc: Send NULL dummy message instead of pointer message
    
    [ Upstream commit ddbf3204f600a4d1f153498f618369fca352ae00 ]
    
    mbox_send_message() sends a u32 bit message, not a pointer to a message.
    We only convert to a pointer type as a generic type. If we want to send
    a dummy message of 0, then simply send 0 (NULL).
    
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sparc: fix compat recv/recvfrom syscalls [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jun 19 12:49:39 2024 +0200

    sparc: fix compat recv/recvfrom syscalls
    
    [ Upstream commit d6fbd26fb872ec518d25433a12e8ce8163e20909 ]
    
    sparc has the wrong compat version of recv() and recvfrom() for both the
    direct syscalls and socketcall().
    
    The direct syscalls just need to use the compat version. For socketcall,
    the same thing could be done, but it seems better to completely remove
    the custom assembler code for it and just use the same implementation that
    everyone else has.
    
    Fixes: 1dacc76d0014 ("net/compat/wext: send different messages to compat tasks")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sparc: fix old compat_sys_select() [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jun 19 14:07:30 2024 +0200

    sparc: fix old compat_sys_select()
    
    [ Upstream commit bae6428a9fffb2023191b0723e276cf1377a7c9f ]
    
    sparc has two identical select syscalls at numbers 93 and 230, respectively.
    During the conversion to the modern syscall.tbl format, the older one of the
    two broke in compat mode, and now refers to the native 64-bit syscall.
    
    Restore the correct behavior. This has very little effect, as glibc has
    been using the newer number anyway.
    
    Fixes: 6ff645dd683a ("sparc: add system call table generation support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
syscalls: fix compat_sys_io_pgetevents_time64 usage [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Jun 20 14:16:37 2024 +0200

    syscalls: fix compat_sys_io_pgetevents_time64 usage
    
    commit d3882564a77c21eb746ba5364f3fa89b88de3d61 upstream.
    
    Using sys_io_pgetevents() as the entry point for compat mode tasks
    works almost correctly, but misses the sign extension for the min_nr
    and nr arguments.
    
    This was addressed on parisc by switching to
    compat_sys_io_pgetevents_time64() in commit 6431e92fc827 ("parisc:
    io_pgetevents_time64() needs compat syscall in 32-bit compat mode"),
    as well as by using more sophisticated system call wrappers on x86 and
    s390. However, arm64, mips, powerpc, sparc and riscv still have the
    same bug.
    
    Change all of them over to use compat_sys_io_pgetevents_time64()
    like parisc already does. This was clearly the intention when the
    function was originally added, but it got hooked up incorrectly in
    the tables.
    
    Cc: [email protected]
    Fixes: 48166e6ea47d ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
    Acked-by: Heiko Carstens <[email protected]> # s390
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

syscalls: fix sys_fanotify_mark prototype [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Sat Jun 29 21:48:41 2024 +0200

    syscalls: fix sys_fanotify_mark prototype
    
    [ Upstream commit 63e2f40c9e3187641afacde4153f54b3ee4dbc8c ]
    
    My earlier fix missed an incorrect function prototype that shows up on
    native 32-bit builds:
    
    In file included from fs/notify/fanotify/fanotify_user.c:14:
    include/linux/syscalls.h:248:25: error: conflicting types for 'sys_fanotify_mark'; have 'long int(int,  unsigned int,  u32,  u32,  int,  const char *)' {aka 'long int(int,  unsigned int,  unsigned int,  unsigned int,  int,  const char *)'}
     1924 | SYSCALL32_DEFINE6(fanotify_mark,
          | ^~~~~~~~~~~~~~~~~
    include/linux/syscalls.h:862:17: note: previous declaration of 'sys_fanotify_mark' with type 'long int(int,  unsigned int,  u64,  int, const char *)' {aka 'long int(int,  unsigned int,  long long unsigned int,  int,  const char *)'}
    
    On x86 and powerpc, the prototype is also wrong but hidden in an #ifdef,
    so it never caused problems.
    
    Add another alternative declaration that matches the conditional function
    definition.
    
    Fixes: 403f17a33073 ("parisc: use generic sys_fanotify_mark implementation")
    Cc: [email protected]
    Reported-by: Guenter Roeck <[email protected]>
    Reported-by: Geert Uytterhoeven <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: fix tcp_rcv_fastopen_synack() to enter TCP_CA_Loss for failed TFO [+ + +]
Author: Neal Cardwell <[email protected]>
Date:   Mon Jun 24 14:43:23 2024 +0000

    tcp: fix tcp_rcv_fastopen_synack() to enter TCP_CA_Loss for failed TFO
    
    [ Upstream commit 5dfe9d273932c647bdc9d664f939af9a5a398cbc ]
    
    Testing determined that the recent commit 9e046bb111f1 ("tcp: clear
    tp->retrans_stamp in tcp_rcv_fastopen_synack()") has a race, and does
    not always ensure retrans_stamp is 0 after a TFO payload retransmit.
    
    If transmit completion for the SYN+data skb happens after the client
    TCP stack receives the SYNACK (which sometimes happens), then
    retrans_stamp can erroneously remain non-zero for the lifetime of the
    connection, causing a premature ETIMEDOUT later.
    
    Testing and tracing showed that the buggy scenario is the following
    somewhat tricky sequence:
    
    + Client attempts a TFO handshake. tcp_send_syn_data() sends SYN + TFO
      cookie + data in a single packet in the syn_data skb. It hands the
      syn_data skb to tcp_transmit_skb(), which makes a clone. Crucially,
      it then reuses the same original (non-clone) syn_data skb,
      transforming it by advancing the seq by one byte and removing the
      FIN bit, and enques the resulting payload-only skb in the
      sk->tcp_rtx_queue.
    
    + Client sets retrans_stamp to the start time of the three-way
      handshake.
    
    + Cookie mismatches or server has TFO disabled, and server only ACKs
      SYN.
    
    + tcp_ack() sees SYN is acked, tcp_clean_rtx_queue() clears
      retrans_stamp.
    
    + Since the client SYN was acked but not the payload, the TFO failure
      code path in tcp_rcv_fastopen_synack() tries to retransmit the
      payload skb.  However, in some cases the transmit completion for the
      clone of the syn_data (which had SYN + TFO cookie + data) hasn't
      happened.  In those cases, skb_still_in_host_queue() returns true
      for the retransmitted TFO payload, because the clone of the syn_data
      skb has not had its tx completetion.
    
    + Because skb_still_in_host_queue() finds skb_fclone_busy() is true,
      it sets the TSQ_THROTTLED bit and the retransmit does not happen in
      the tcp_rcv_fastopen_synack() call chain.
    
    + The tcp_rcv_fastopen_synack() code next implicitly assumes the
      retransmit process is finished, and sets retrans_stamp to 0 to clear
      it, but this is later overwritten (see below).
    
    + Later, upon tx completion, tcp_tsq_write() calls
      tcp_xmit_retransmit_queue(), which puts the retransmit in flight and
      sets retrans_stamp to a non-zero value.
    
    + The client receives an ACK for the retransmitted TFO payload data.
    
    + Since we're in CA_Open and there are no dupacks/SACKs/DSACKs/ECN to
      make tcp_ack_is_dubious() true and make us call
      tcp_fastretrans_alert() and reach a code path that clears
      retrans_stamp, retrans_stamp stays nonzero.
    
    + Later, if there is a TLP, RTO, RTO sequence, then the connection
      will suffer an early ETIMEDOUT due to the erroneously ancient
      retrans_stamp.
    
    The fix: this commit refactors the code to have
    tcp_rcv_fastopen_synack() retransmit by reusing the relevant parts of
    tcp_simple_retransmit() that enter CA_Loss (without changing cwnd) and
    call tcp_xmit_retransmit_queue(). We have tcp_simple_retransmit() and
    tcp_rcv_fastopen_synack() share code in this way because in both cases
    we get a packet indicating non-congestion loss (MTU reduction or TFO
    failure) and thus in both cases we want to retransmit as many packets
    as cwnd allows, without reducing cwnd. And given that retransmits will
    set retrans_stamp to a non-zero value (and may do so in a later
    calling context due to TSQ), we also want to enter CA_Loss so that we
    track when all retransmitted packets are ACked and clear retrans_stamp
    when that happens (to ensure later recurring RTOs are using the
    correct retrans_stamp and don't declare ETIMEDOUT prematurely).
    
    Fixes: 9e046bb111f1 ("tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack()")
    Fixes: a7abf3cd76e1 ("tcp: consider using standard rtx logic in tcp_rcv_fastopen_synack()")
    Signed-off-by: Neal Cardwell <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Yuchung Cheng <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset() [+ + +]
Author: Yunseong Kim <[email protected]>
Date:   Tue Jun 25 02:33:23 2024 +0900

    tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset()
    
    commit bab4923132feb3e439ae45962979c5d9d5c7c1f1 upstream.
    
    In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
    
     qdisc->dev_queue->dev <NULL> ->name
    
    This situation simulated from bunch of veths and Bluetooth disconnection
    and reconnection.
    
    During qdisc initialization, qdisc was being set to noop_queue.
    In veth_init_queue, the initial tx_num was reduced back to one,
    causing the qdisc reset to be called with noop, which led to the kernel
    panic.
    
    I've attached the GitHub gist link that C converted syz-execprogram
    source code and 3 log of reproduced vmcore-dmesg.
    
     https://gist.github.com/yskelg/cc64562873ce249cdd0d5a358b77d740
    
    Yeoreum and I use two fuzzing tool simultaneously.
    
    One process with syz-executor : https://github.com/google/syzkaller
    
     $ ./syz-execprog -executor=./syz-executor -repeat=1 -sandbox=setuid \
        -enable=none -collide=false log1
    
    The other process with perf fuzzer:
     https://github.com/deater/perf_event_tests/tree/master/fuzzer
    
     $ perf_event_tests/fuzzer/perf_fuzzer
    
    I think this will happen on the kernel version.
    
     Linux kernel version +v6.7.10, +v6.8, +v6.9 and it could happen in v6.10.
    
    This occurred from 51270d573a8d. I think this patch is absolutely
    necessary. Previously, It was showing not intended string value of name.
    
    I've reproduced 3 time from my fedora 40 Debug Kernel with any other module
    or patched.
    
     version: 6.10.0-0.rc2.20240608gitdc772f8237f9.29.fc41.aarch64+debug
    
    [ 5287.164555] veth0_vlan: left promiscuous mode
    [ 5287.164929] veth1_macvtap: left promiscuous mode
    [ 5287.164950] veth0_macvtap: left promiscuous mode
    [ 5287.164983] veth1_vlan: left promiscuous mode
    [ 5287.165008] veth0_vlan: left promiscuous mode
    [ 5287.165450] veth1_macvtap: left promiscuous mode
    [ 5287.165472] veth0_macvtap: left promiscuous mode
    [ 5287.165502] veth1_vlan: left promiscuous mode
    …
    [ 5297.598240] bridge0: port 2(bridge_slave_1) entered blocking state
    [ 5297.598262] bridge0: port 2(bridge_slave_1) entered forwarding state
    [ 5297.598296] bridge0: port 1(bridge_slave_0) entered blocking state
    [ 5297.598313] bridge0: port 1(bridge_slave_0) entered forwarding state
    [ 5297.616090] 8021q: adding VLAN 0 to HW filter on device bond0
    [ 5297.620405] bridge0: port 1(bridge_slave_0) entered disabled state
    [ 5297.620730] bridge0: port 2(bridge_slave_1) entered disabled state
    [ 5297.627247] 8021q: adding VLAN 0 to HW filter on device team0
    [ 5297.629636] bridge0: port 1(bridge_slave_0) entered blocking state
    …
    [ 5298.002798] bridge_slave_0: left promiscuous mode
    [ 5298.002869] bridge0: port 1(bridge_slave_0) entered disabled state
    [ 5298.309444] bond0 (unregistering): (slave bond_slave_0): Releasing backup interface
    [ 5298.315206] bond0 (unregistering): (slave bond_slave_1): Releasing backup interface
    [ 5298.320207] bond0 (unregistering): Released all slaves
    [ 5298.354296] hsr_slave_0: left promiscuous mode
    [ 5298.360750] hsr_slave_1: left promiscuous mode
    [ 5298.374889] veth1_macvtap: left promiscuous mode
    [ 5298.374931] veth0_macvtap: left promiscuous mode
    [ 5298.374988] veth1_vlan: left promiscuous mode
    [ 5298.375024] veth0_vlan: left promiscuous mode
    [ 5299.109741] team0 (unregistering): Port device team_slave_1 removed
    [ 5299.185870] team0 (unregistering): Port device team_slave_0 removed
    …
    [ 5300.155443] Bluetooth: hci3: unexpected cc 0x0c03 length: 249 > 1
    [ 5300.155724] Bluetooth: hci3: unexpected cc 0x1003 length: 249 > 9
    [ 5300.155988] Bluetooth: hci3: unexpected cc 0x1001 length: 249 > 9
    ….
    [ 5301.075531] team0: Port device team_slave_1 added
    [ 5301.085515] bridge0: port 1(bridge_slave_0) entered blocking state
    [ 5301.085531] bridge0: port 1(bridge_slave_0) entered disabled state
    [ 5301.085588] bridge_slave_0: entered allmulticast mode
    [ 5301.085800] bridge_slave_0: entered promiscuous mode
    [ 5301.095617] bridge0: port 1(bridge_slave_0) entered blocking state
    [ 5301.095633] bridge0: port 1(bridge_slave_0) entered disabled state
    …
    [ 5301.149734] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
    [ 5301.173234] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
    [ 5301.180517] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
    [ 5301.193481] hsr_slave_0: entered promiscuous mode
    [ 5301.204425] hsr_slave_1: entered promiscuous mode
    [ 5301.210172] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.210185] Cannot create hsr debugfs directory
    [ 5301.224061] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
    [ 5301.246901] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
    [ 5301.255934] team0: Port device team_slave_0 added
    [ 5301.256480] team0: Port device team_slave_1 added
    [ 5301.256948] team0: Port device team_slave_0 added
    …
    [ 5301.435928] hsr_slave_0: entered promiscuous mode
    [ 5301.446029] hsr_slave_1: entered promiscuous mode
    [ 5301.455872] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.455884] Cannot create hsr debugfs directory
    [ 5301.502664] hsr_slave_0: entered promiscuous mode
    [ 5301.513675] hsr_slave_1: entered promiscuous mode
    [ 5301.526155] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.526164] Cannot create hsr debugfs directory
    [ 5301.563662] hsr_slave_0: entered promiscuous mode
    [ 5301.576129] hsr_slave_1: entered promiscuous mode
    [ 5301.580259] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.580270] Cannot create hsr debugfs directory
    [ 5301.590269] 8021q: adding VLAN 0 to HW filter on device bond0
    
    [ 5301.595872] KASAN: null-ptr-deref in range [0x0000000000000130-0x0000000000000137]
    [ 5301.595877] Mem abort info:
    [ 5301.595881]   ESR = 0x0000000096000006
    [ 5301.595885]   EC = 0x25: DABT (current EL), IL = 32 bits
    [ 5301.595889]   SET = 0, FnV = 0
    [ 5301.595893]   EA = 0, S1PTW = 0
    [ 5301.595896]   FSC = 0x06: level 2 translation fault
    [ 5301.595900] Data abort info:
    [ 5301.595903]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
    [ 5301.595907]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [ 5301.595911]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [ 5301.595915] [dfff800000000026] address between user and kernel address ranges
    [ 5301.595971] Internal error: Oops: 0000000096000006 [#1] SMP
    …
    [ 5301.596076] CPU: 2 PID: 102769 Comm:
    syz-executor.3 Kdump: loaded Tainted:
     G        W         -------  ---  6.10.0-0.rc2.20240608gitdc772f8237f9.29.fc41.aarch64+debug #1
    [ 5301.596080] Hardware name: VMware, Inc. VMware20,1/VBSA,
     BIOS VMW201.00V.21805430.BA64.2305221830 05/22/2023
    [ 5301.596082] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    [ 5301.596085] pc : strnlen+0x40/0x88
    [ 5301.596114] lr : trace_event_get_offsets_qdisc_reset+0x6c/0x2b0
    [ 5301.596124] sp : ffff8000beef6b40
    [ 5301.596126] x29: ffff8000beef6b40 x28: dfff800000000000 x27: 0000000000000001
    [ 5301.596131] x26: 6de1800082c62bd0 x25: 1ffff000110aa9e0 x24: ffff800088554f00
    [ 5301.596136] x23: ffff800088554ec0 x22: 0000000000000130 x21: 0000000000000140
    [ 5301.596140] x20: dfff800000000000 x19: ffff8000beef6c60 x18: ffff7000115106d8
    [ 5301.596143] x17: ffff800121bad000 x16: ffff800080020000 x15: 0000000000000006
    [ 5301.596147] x14: 0000000000000002 x13: ffff0001f3ed8d14 x12: ffff700017ddeda5
    [ 5301.596151] x11: 1ffff00017ddeda4 x10: ffff700017ddeda4 x9 : ffff800082cc5eec
    [ 5301.596155] x8 : 0000000000000004 x7 : 00000000f1f1f1f1 x6 : 00000000f2f2f200
    [ 5301.596158] x5 : 00000000f3f3f3f3 x4 : ffff700017dded80 x3 : 00000000f204f1f1
    [ 5301.596162] x2 : 0000000000000026 x1 : 0000000000000000 x0 : 0000000000000130
    [ 5301.596166] Call trace:
    [ 5301.596175]  strnlen+0x40/0x88
    [ 5301.596179]  trace_event_get_offsets_qdisc_reset+0x6c/0x2b0
    [ 5301.596182]  perf_trace_qdisc_reset+0xb0/0x538
    [ 5301.596184]  __traceiter_qdisc_reset+0x68/0xc0
    [ 5301.596188]  qdisc_reset+0x43c/0x5e8
    [ 5301.596190]  netif_set_real_num_tx_queues+0x288/0x770
    [ 5301.596194]  veth_init_queues+0xfc/0x130 [veth]
    [ 5301.596198]  veth_newlink+0x45c/0x850 [veth]
    [ 5301.596202]  rtnl_newlink_create+0x2c8/0x798
    [ 5301.596205]  __rtnl_newlink+0x92c/0xb60
    [ 5301.596208]  rtnl_newlink+0xd8/0x130
    [ 5301.596211]  rtnetlink_rcv_msg+0x2e0/0x890
    [ 5301.596214]  netlink_rcv_skb+0x1c4/0x380
    [ 5301.596225]  rtnetlink_rcv+0x20/0x38
    [ 5301.596227]  netlink_unicast+0x3c8/0x640
    [ 5301.596231]  netlink_sendmsg+0x658/0xa60
    [ 5301.596234]  __sock_sendmsg+0xd0/0x180
    [ 5301.596243]  __sys_sendto+0x1c0/0x280
    [ 5301.596246]  __arm64_sys_sendto+0xc8/0x150
    [ 5301.596249]  invoke_syscall+0xdc/0x268
    [ 5301.596256]  el0_svc_common.constprop.0+0x16c/0x240
    [ 5301.596259]  do_el0_svc+0x48/0x68
    [ 5301.596261]  el0_svc+0x50/0x188
    [ 5301.596265]  el0t_64_sync_handler+0x120/0x130
    [ 5301.596268]  el0t_64_sync+0x194/0x198
    [ 5301.596272] Code: eb15001f 54000120 d343fc02 12000801 (38f46842)
    [ 5301.596285] SMP: stopping secondary CPUs
    [ 5301.597053] Starting crashdump kernel...
    [ 5301.597057] Bye!
    
    After applying our patch, I didn't find any kernel panic errors.
    
    We've found a simple reproducer
    
     # echo 1 > /sys/kernel/debug/tracing/events/qdisc/qdisc_reset/enable
    
     # ip link add veth0 type veth peer name veth1
    
     Error: Unknown device type.
    
    However, without our patch applied, I tested upstream 6.10.0-rc3 kernel
    using the qdisc_reset event and the ip command on my qemu virtual machine.
    
    This 2 commands makes always kernel panic.
    
    Linux version: 6.10.0-rc3
    
    [    0.000000] Linux version 6.10.0-rc3-00164-g44ef20baed8e-dirty
    (paran@fedora) (gcc (GCC) 14.1.1 20240522 (Red Hat 14.1.1-4), GNU ld
    version 2.41-34.fc40) #20 SMP PREEMPT Sat Jun 15 16:51:25 KST 2024
    
    Kernel panic message:
    
    [  615.236484] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
    [  615.237250] Dumping ftrace buffer:
    [  615.237679]    (ftrace buffer empty)
    [  615.238097] Modules linked in: veth crct10dif_ce virtio_gpu
    virtio_dma_buf drm_shmem_helper drm_kms_helper zynqmp_fpga xilinx_can
    xilinx_spi xilinx_selectmap xilinx_core xilinx_pr_decoupler versal_fpga
    uvcvideo uvc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev
    videobuf2_common mc usbnet deflate zstd ubifs ubi rcar_canfd rcar_can
    omap_mailbox ntb_msi_test ntb_hw_epf lattice_sysconfig_spi
    lattice_sysconfig ice40_spi gpio_xilinx dwmac_altr_socfpga mdio_regmap
    stmmac_platform stmmac pcs_xpcs dfl_fme_region dfl_fme_mgr dfl_fme_br
    dfl_afu dfl fpga_region fpga_bridge can can_dev br_netfilter bridge stp
    llc atl1c ath11k_pci mhi ath11k_ahb ath11k qmi_helpers ath10k_sdio
    ath10k_pci ath10k_core ath mac80211 libarc4 cfg80211 drm fuse backlight ipv6
    Jun 22 02:36:5[3   6k152.62-4sm98k4-0k]v  kCePUr:n e1l :P IUDn:a b4le6
    8t oC ohmma: nidpl eN oketr nteali nptaedg i6n.g1 0re.0q-urecs3t- 0at0
    1v6i4r-tgu4a4le fa2d0dbraeeds0se-dir tyd f#f2f08
      615.252376] Hardware name: linux,dummy-virt (DT)
    [  615.253220] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
    BTYPE=--)
    [  615.254433] pc : strnlen+0x6c/0xe0
    [  615.255096] lr : trace_event_get_offsets_qdisc_reset+0x94/0x3d0
    [  615.256088] sp : ffff800080b269a0
    [  615.256615] x29: ffff800080b269a0 x28: ffffc070f3f98500 x27:
    0000000000000001
    [  615.257831] x26: 0000000000000010 x25: ffffc070f3f98540 x24:
    ffffc070f619cf60
    [  615.259020] x23: 0000000000000128 x22: 0000000000000138 x21:
    dfff800000000000
    [  615.260241] x20: ffffc070f631ad00 x19: 0000000000000128 x18:
    ffffc070f448b800
    [  615.261454] x17: 0000000000000000 x16: 0000000000000001 x15:
    ffffc070f4ba2a90
    [  615.262635] x14: ffff700010164d73 x13: 1ffff80e1e8d5eb3 x12:
    1ffff00010164d72
    [  615.263877] x11: ffff700010164d72 x10: dfff800000000000 x9 :
    ffffc070e85d6184
    [  615.265047] x8 : ffffc070e4402070 x7 : 000000000000f1f1 x6 :
    000000001504a6d3
    [  615.266336] x5 : ffff28ca21122140 x4 : ffffc070f5043ea8 x3 :
    0000000000000000
    [  615.267528] x2 : 0000000000000025 x1 : 0000000000000000 x0 :
    0000000000000000
    [  615.268747] Call trace:
    [  615.269180]  strnlen+0x6c/0xe0
    [  615.269767]  trace_event_get_offsets_qdisc_reset+0x94/0x3d0
    [  615.270716]  trace_event_raw_event_qdisc_reset+0xe8/0x4e8
    [  615.271667]  __traceiter_qdisc_reset+0xa0/0x140
    [  615.272499]  qdisc_reset+0x554/0x848
    [  615.273134]  netif_set_real_num_tx_queues+0x360/0x9a8
    [  615.274050]  veth_init_queues+0x110/0x220 [veth]
    [  615.275110]  veth_newlink+0x538/0xa50 [veth]
    [  615.276172]  __rtnl_newlink+0x11e4/0x1bc8
    [  615.276944]  rtnl_newlink+0xac/0x120
    [  615.277657]  rtnetlink_rcv_msg+0x4e4/0x1370
    [  615.278409]  netlink_rcv_skb+0x25c/0x4f0
    [  615.279122]  rtnetlink_rcv+0x48/0x70
    [  615.279769]  netlink_unicast+0x5a8/0x7b8
    [  615.280462]  netlink_sendmsg+0xa70/0x1190
    
    Yeoreum and I don't know if the patch we wrote will fix the underlying
    cause, but we think that priority is to prevent kernel panic happening.
    So, we're sending this patch.
    
    Fixes: 51270d573a8d ("tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string")
    Link: https://lore.kernel.org/lkml/[email protected]/t/
    Cc: [email protected]
    Tested-by: Yunseong Kim <[email protected]>
    Signed-off-by: Yunseong Kim <[email protected]>
    Signed-off-by: Yeoreum Yun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tty: mcf: MCF54418 has 10 UARTS [+ + +]
Author: Jean-Michel Hautbois <[email protected]>
Date:   Thu Jun 20 18:29:59 2024 +0200

    tty: mcf: MCF54418 has 10 UARTS
    
    commit 7c92a8bd53f24d50c8cf4aba53bb75505b382fed upstream.
    
    Most of the colfires have up to 5 UARTs but MCF54418 has up-to 10 !
    Change the maximum value authorized.
    
    Signed-off-by: Jean-Michel Hautbois <[email protected]>
    Cc: stable <[email protected]>
    Fixes: 2545cf6e94b4 ("m68knommu: allow 4 coldfire serial ports")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: atm: cxacru: fix endpoint checking in cxacru_bind() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Sun Jun 9 06:15:46 2024 -0700

    usb: atm: cxacru: fix endpoint checking in cxacru_bind()
    
    commit 2eabb655a968b862bc0c31629a09f0fbf3c80d51 upstream.
    
    Syzbot is still reporting quite an old issue [1] that occurs due to
    incomplete checking of present usb endpoints. As such, wrong
    endpoints types may be used at urb sumbitting stage which in turn
    triggers a warning in usb_submit_urb().
    
    Fix the issue by verifying that required endpoint types are present
    for both in and out endpoints, taking into account cmd endpoint type.
    
    Unfortunately, this patch has not been tested on real hardware.
    
    [1] Syzbot report:
    usb 1-1: BOGUS urb xfer, pipe 1 != type 3
    WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
    Modules linked in:
    CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
    ...
    Call Trace:
     cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
     cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
     cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
     usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
     cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
     usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
     call_driver_probe drivers/base/dd.c:517 [inline]
     really_probe+0x23c/0xcd0 drivers/base/dd.c:595
     __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
     driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
     __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
     bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
     __device_attach+0x228/0x4a0 drivers/base/dd.c:965
     bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
     device_add+0xc2f/0x2180 drivers/base/core.c:3354
     usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
     usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
    
    Reported-and-tested-by: [email protected]
    Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint")
    Cc: stable <[email protected]>
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock [+ + +]
Author: Meng Li <[email protected]>
Date:   Tue Jun 18 11:19:18 2024 +0800

    usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock
    
    commit 7838de15bb700c2898a7d741db9b1f3cbc86c136 upstream.
    
    When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system
    to enter suspend status with below command:
    echo mem > /sys/power/state
    There will be a deadlock issue occurring. Detailed invoking path as
    below:
    dwc3_suspend_common()
        spin_lock_irqsave(&dwc->lock, flags);              <-- 1st
        dwc3_gadget_suspend(dwc);
            dwc3_gadget_soft_disconnect(dwc);
                spin_lock_irqsave(&dwc->lock, flags);      <-- 2nd
    This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix
    NULL pointer dereference in dwc3_gadget_suspend") that removes the code
    of checking whether dwc->gadget_driver is NULL or not. It causes the
    following code is executed and deadlock occurs when trying to get the
    spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3:
    Remove DWC3 locking during gadget suspend/resume") that forgot to remove
    the lock of otg mode. So, remove the redundant lock of otg mode during
    gadget suspend/resume.
    
    Fixes: 5265397f9442 ("usb: dwc3: Remove DWC3 locking during gadget suspend/resume")
    Cc: Xu Yang <[email protected]>
    Cc: [email protected]
    Signed-off-by: Meng Li <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: aspeed_udc: fix device address configuration [+ + +]
Author: Jeremy Kerr <[email protected]>
Date:   Thu Jun 13 12:20:47 2024 +0800

    usb: gadget: aspeed_udc: fix device address configuration
    
    commit dba7567c2fbbf10a4de2471cdb0e16e5572dc007 upstream.
    
    In the aspeed UDC setup, we configure the UDC hardware with the assigned
    USB device address.
    
    However, we have an off-by-one in the bitmask, so we're only setting the
    lower 6 bits of the address (USB addresses being 7 bits, and the
    hardware bitmask being bits 0:6).
    
    This means that device enumeration fails if the assigned address is
    greater than 64:
    
    [  344.607255] usb 1-1: new high-speed USB device number 63 using ehci-platform
    [  344.808459] usb 1-1: New USB device found, idVendor=cc00, idProduct=cc00, bcdDevice= 6.10
    [  344.817684] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [  344.825671] usb 1-1: Product: Test device
    [  344.831075] usb 1-1: Manufacturer: Test vendor
    [  344.836335] usb 1-1: SerialNumber: 00
    [  349.917181] usb 1-1: USB disconnect, device number 63
    [  352.036775] usb 1-1: new high-speed USB device number 64 using ehci-platform
    [  352.249432] usb 1-1: device descriptor read/all, error -71
    [  352.696740] usb 1-1: new high-speed USB device number 65 using ehci-platform
    [  352.909431] usb 1-1: device descriptor read/all, error -71
    
    Use the correct mask of 0x7f (rather than 0x3f), and generate this
    through the GENMASK macro, so we have numbers that correspond exactly
    to the hardware register definition.
    
    Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
    Cc: [email protected]
    Reviewed-by: Neal Liu <[email protected]>
    Reviewed-by: Andrew Jeffery <[email protected]>
    Signed-off-by: Jeremy Kerr <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: printer: fix races against disable [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Jun 20 13:40:26 2024 +0200

    usb: gadget: printer: fix races against disable
    
    commit e587a7633dfee8987a999cf253f7c52a8e09276c upstream.
    
    printer_read() and printer_write() guard against the race
    against disable() by checking the dev->interface flag,
    which in turn is guarded by a spinlock.
    These functions, however, drop the lock on multiple occasions.
    This means that the test has to be redone after reacquiring
    the lock and before doing IO.
    
    Add the tests.
    
    This also addresses CVE-2024-25741
    
    Fixes: 7f2ca14d2f9b9 ("usb: gadget: function: printer: Interface is disabled and returns error")
    Cc: stable <[email protected]>
    Signed-off-by: Oliver Neukum <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: printer: SS+ support [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Jun 20 11:37:39 2024 +0200

    usb: gadget: printer: SS+ support
    
    commit fd80731e5e9d1402cb2f85022a6abf9b1982ec5f upstream.
    
    We need to treat super speed plus as super speed, not the default,
    which is full speed.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: musb: da8xx: fix a resource leak in probe() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Jun 17 12:31:30 2024 +0300

    usb: musb: da8xx: fix a resource leak in probe()
    
    commit de644a4a86be04ed8a43ef8267d0f7d021941c5e upstream.
    
    Call usb_phy_generic_unregister() if of_platform_populate() fails.
    
    Fixes: d6299b6efbf6 ("usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx")
    Cc: stable <[email protected]>
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: ucsi: Ack also failed Get Error commands [+ + +]
Author: Heikki Krogerus <[email protected]>
Date:   Fri May 31 13:46:52 2024 +0300

    usb: typec: ucsi: Ack also failed Get Error commands
    
    [ Upstream commit 8bdf8a42bca4f47646fd105a387ab6926948c7f1 ]
    
    It is possible that also the GET_ERROR command fails. If
    that happens, the command completion still needs to be
    acknowledged. Otherwise the interface will be stuck until
    it's reset.
    
    Reported-by: Ammy Yi <[email protected]>
    Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API")
    Cc: [email protected]
    Signed-off-by: Heikki Krogerus <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: typec: ucsi: Never send a lone connector change ack [+ + +]
Author: Christian A. Ehrhardt <[email protected]>
Date:   Wed Mar 27 23:45:53 2024 +0100

    usb: typec: ucsi: Never send a lone connector change ack
    
    [ Upstream commit de52aca4d9d56c3b2f00b638d457075914b1a227 ]
    
    Some PPM implementation do not like UCSI_ACK_CONNECTOR_CHANGE
    without UCSI_ACK_COMMAND_COMPLETE. Moreover, doing this is racy
    as it requires sending two UCSI_ACK_CC_CI commands in a row and
    the second one will be started with UCSI_CCI_ACK_COMPLETE already
    set in CCI.
    
    Bundle the UCSI_ACK_CONNECTOR_CHANGE with the UCSI_ACK_COMMAND_COMPLETE
    for the UCSI_GET_CONNECTOR_STATUS command that is sent while
    handling a connector change event.
    
    Signed-off-by: Christian A. Ehrhardt <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Tested-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 8bdf8a42bca4 ("usb: typec: ucsi: Ack also failed Get Error commands")
    Signed-off-by: Sasha Levin <[email protected]>
usb: ucsi: stm32: fix command completion handling [+ + +]
Author: Fabrice Gasnier <[email protected]>
Date:   Wed Jun 12 14:46:56 2024 +0200

    usb: ucsi: stm32: fix command completion handling
    
    commit 8e1ec117efdfd4b2f59f57bd0ad16b4edf5b963f upstream.
    
    Sometimes errors are seen, when doing DR swap, like:
    [   24.672481] ucsi-stm32g0-i2c 0-0035: UCSI_GET_PDOS failed (-5)
    [   24.720188] ucsi-stm32g0-i2c 0-0035: ucsi_handle_connector_change:
     GET_CONNECTOR_STATUS failed (-5)
    
    There may be some race, which lead to read CCI, before the command complete
    flag is set, hence returning -EIO. Similar fix has been done also in
    ucsi_acpi [1].
    
    In case of a spurious or otherwise delayed notification it is
    possible that CCI still reports the previous completion. The
    UCSI spec is aware of this and provides two completion bits in
    CCI, one for normal commands and one for acks. As acks and commands
    alternate the notification handler can determine if the completion
    bit is from the current command.
    
    To fix this add the ACK_PENDING bit for ucsi_stm32g0 and only complete
    commands if the completion bit matches.
    
    [1] https://lore.kernel.org/lkml/[email protected]/
    
    Fixes: 72849d4fcee7 ("usb: typec: ucsi: stm32g0: add support for stm32g0 controller")
    Signed-off-by: Fabrice Gasnier <[email protected]>
    Link: https://lore.kernel.org/stable/20240612124656.2305603-1-fabrice.gasnier%40foss.st.com
    Cc: stable <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vduse: Temporarily fail if control queue feature requested [+ + +]
Author: Maxime Coquelin <[email protected]>
Date:   Tue Jan 9 12:10:24 2024 +0100

    vduse: Temporarily fail if control queue feature requested
    
    [ Upstream commit 56e71885b0349241c07631a7b979b61e81afab6a ]
    
    Virtio-net driver control queue implementation is not safe
    when used with VDUSE. If the VDUSE application does not
    reply to control queue messages, it currently ends up
    hanging the kernel thread sending this command.
    
    Some work is on-going to make the control queue
    implementation robust with VDUSE. Until it is completed,
    let's fail features check if control-queue feature is
    requested.
    
    Signed-off-by: Maxime Coquelin <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Acked-by: Eugenio Pérez <[email protected]>
    Reviewed-by: Xie Yongji <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

vduse: validate block features only with block devices [+ + +]
Author: Maxime Coquelin <[email protected]>
Date:   Tue Jan 9 12:10:23 2024 +0100

    vduse: validate block features only with block devices
    
    [ Upstream commit a115b5716fc9a64652aa9cb332070087178ffafa ]
    
    This patch is preliminary work to enable network device
    type support to VDUSE.
    
    As VIRTIO_BLK_F_CONFIG_WCE shares the same value as
    VIRTIO_NET_F_HOST_TSO4, we need to restrict its check
    to Virtio-blk device type.
    
    Acked-by: Jason Wang <[email protected]>
    Reviewed-by: Xie Yongji <[email protected]>
    Reviewed-by: Eugenio Pérez <[email protected]>
    Signed-off-by: Maxime Coquelin <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: ieee80211: check for NULL in ieee80211_mle_size_ok() [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Mon Mar 18 18:53:17 2024 +0200

    wifi: ieee80211: check for NULL in ieee80211_mle_size_ok()
    
    [ Upstream commit b7793a1a2f370c28b17d9554b58e9dc51afcfcbd ]
    
    For simplicity, we may want to pass a NULL element, and
    while we should then pass also a zero length, just be a
    bit more careful here.
    
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240318184907.4d983653cb8d.Ic3ea99b60c61ac2f7d38cb9fd202a03c97a05601@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/fpu: Fix AMD X86_BUG_FXSAVE_LEAK fixup [+ + +]
Author: Uros Bizjak <[email protected]>
Date:   Fri Mar 15 09:18:23 2024 +0100

    x86/fpu: Fix AMD X86_BUG_FXSAVE_LEAK fixup
    
    [ Upstream commit 5d31174f3c8c465d9dbe88f6b9d1fe5716f44981 ]
    
    The assembly snippet in restore_fpregs_from_fpstate() that implements
    X86_BUG_FXSAVE_LEAK fixup loads the value from a random variable,
    preferably the one that is already in the L1 cache.
    
    However, the access to fpinit_state via *fpstate pointer is not
    implemented correctly. The "m" asm constraint requires dereferenced
    pointer variable, otherwise the compiler just reloads the value
    via temporary stack slot. The current asm code reflects this:
    
         mov    %rdi,(%rsp)
         ...
         fildl  (%rsp)
    
    With dereferenced pointer variable, the code does what the
    comment above the asm snippet says:
    
         fildl  (%rdi)
    
    Also, remove the pointless %P operand modifier. The modifier is
    ineffective on non-symbolic references - it was used to prevent
    %rip-relative addresses in .altinstr sections, but FILDL in the
    .text section can use %rip-relative addresses without problems.
    
    Signed-off-by: Uros Bizjak <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: H. Peter Anvin <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86: stop playing stack games in profile_pc() [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Fri Jun 28 14:27:22 2024 -0700

    x86: stop playing stack games in profile_pc()
    
    [ Upstream commit 093d9603b60093a9aaae942db56107f6432a5dca ]
    
    The 'profile_pc()' function is used for timer-based profiling, which
    isn't really all that relevant any more to begin with, but it also ends
    up making assumptions based on the stack layout that aren't necessarily
    valid.
    
    Basically, the code tries to account the time spent in spinlocks to the
    caller rather than the spinlock, and while I support that as a concept,
    it's not worth the code complexity or the KASAN warnings when no serious
    profiling is done using timers anyway these days.
    
    And the code really does depend on stack layout that is only true in the
    simplest of cases.  We've lost the comment at some point (I think when
    the 32-bit and 64-bit code was unified), but it used to say:
    
            Assume the lock function has either no stack frame or a copy
            of eflags from PUSHF.
    
    which explains why it just blindly loads a word or two straight off the
    stack pointer and then takes a minimal look at the values to just check
    if they might be eflags or the return pc:
    
            Eflags always has bits 22 and up cleared unlike kernel addresses
    
    but that basic stack layout assumption assumes that there isn't any lock
    debugging etc going on that would complicate the code and cause a stack
    frame.
    
    It causes KASAN unhappiness reported for years by syzkaller [1] and
    others [2].
    
    With no real practical reason for this any more, just remove the code.
    
    Just for historical interest, here's some background commits relating to
    this code from 2006:
    
      0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
      31679f38d886 ("Simplify profile_pc on x86-64")
    
    and a code unification from 2009:
    
      ef4512882dbe ("x86: time_32/64.c unify profile_pc")
    
    but the basics of this thing actually goes back to before the git tree.
    
    Link: https://syzkaller.appspot.com/bug?extid=84fe685c02cd112a2ac3 [1]
    Link: https://lore.kernel.org/all/CAK55_s7Xyq=nh97=K=G1sxueOFrJDAvPOJAL4TPTCAYvmxO9_A@mail.gmail.com/ [2]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xdp: Remove WARN() from __xdp_reg_mem_model() [+ + +]
Author: Daniil Dulov <[email protected]>
Date:   Mon Jun 24 11:07:47 2024 +0300

    xdp: Remove WARN() from __xdp_reg_mem_model()
    
    [ Upstream commit 7e9f79428372c6eab92271390851be34ab26bfb4 ]
    
    syzkaller reports a warning in __xdp_reg_mem_model().
    
    The warning occurs only if __mem_id_init_hash_table() returns an error. It
    returns the error in two cases:
    
      1. memory allocation fails;
      2. rhashtable_init() fails when some fields of rhashtable_params
         struct are not initialized properly.
    
    The second case cannot happen since there is a static const rhashtable_params
    struct with valid fields. So, warning is only triggered when there is a
    problem with memory allocation.
    
    Thus, there is no sense in using WARN() to handle this error and it can be
    safely removed.
    
    WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
    
    CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
    
    Call Trace:
     xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
     xdp_test_run_setup net/bpf/test_run.c:188 [inline]
     bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
     bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
     bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
     __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
     __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
     __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
     do_syscall_64+0xfb/0x240
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Found by Linux Verification Center (linuxtesting.org) with syzkaller.
    
    Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping")
    Signed-off-by: Daniil Dulov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>