Linux 5.15.150

 
ACPI: button: Add lid disable DMI quirk for Nextbook Ares 8A [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 29 12:38:41 2023 +0200

    ACPI: button: Add lid disable DMI quirk for Nextbook Ares 8A
    
    [ Upstream commit 4fd5556608bfa9c2bf276fc115ef04288331aded ]
    
    The LID0 device on the Nextbook Ares 8A tablet always reports lid
    closed causing userspace to suspend the device as soon as booting
    is complete.
    
    Add a DMI quirk to disable the broken lid functionality.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
acpi: property: Let args be NULL in __acpi_node_get_property_reference [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Nov 9 12:10:08 2023 +0200

    acpi: property: Let args be NULL in __acpi_node_get_property_reference
    
    [ Upstream commit bef52aa0f3de1b7d8c258c13b16e577361dabf3a ]
    
    fwnode_get_property_reference_args() may not be called with args argument
    NULL on ACPI, OF already supports this. Add the missing NULL checks and
    document this.
    
    The purpose is to be able to count the references.
    
    Fixes: 977d5ad39f3e ("ACPI: Convert ACPI reference args to generic fwnode reference args")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20231109101010.1329587-2-sakari.ailus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Dec 15 10:44:43 2022 +0100

    ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks
    
    [ Upstream commit 7203481fd12b1257938519efb2460ea02b9236ee ]
    
    The Asus ExpertBook B2502 has the same keyboard issue as Asus Vivobook
    K3402ZA/K3502ZA. The kernel overrides IRQ 1 to Edge_High when it
    should be Active_Low.
    
    This patch adds the ExpertBook B2502 model to the existing
    quirk list of Asus laptops with this issue.
    
    Fixes: b5f9223a105d ("ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA")
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2142574
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 77c724888238 ("ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: resource: Add ASUS model S5402ZA to quirks [+ + +]
Author: Kellen Renshaw <kellen.renshaw@canonical.com>
Date:   Wed Sep 21 10:24:22 2022 -0700

    ACPI: resource: Add ASUS model S5402ZA to quirks
    
    [ Upstream commit 6e5cbe7c4b41824e500acbb42411da692d1435f1 ]
    
    The Asus Vivobook S5402ZA has the same keyboard issue as Asus Vivobook
    K3402ZA/K3502ZA. The kernel overrides IRQ 1 to Edge_High when it
    should be Active_Low.
    
    This patch adds the S5402ZA model to the quirk list.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158
    Tested-by: Kellen Renshaw <kellen.renshaw@canonical.com>
    Signed-off-by: Kellen Renshaw <kellen.renshaw@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CBA [+ + +]
Author: Paul Menzel <pmenzel@molgen.mpg.de>
Date:   Tue Apr 11 20:31:44 2023 +0200

    ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CBA
    
    [ Upstream commit 05cda427126f30ce3fc8ffd82fd6f5196398d502 ]
    
    Like the ASUS ExpertBook B2502CBA and various ASUS Vivobook laptops, the
    ASUS ExpertBook B1502CBA has an ACPI DSDT table that describes IRQ 1 as
    ActiveLow while the kernel overrides it to Edge_High.
    
        $ sudo dmesg | grep DMI
        DMI: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B1502CBA_B1502CBA/B1502CBA, BIOS B1502CBA.300 01/18/2023
        $ grep -A 40 PS2K dsdt.dsl | grep IRQ -A 1
                        IRQ (Level, ActiveLow, Exclusive, )
                            {1}
    
    This prevents the keyboard from working. To fix this issue, add this laptop
    to the skip_override_table so that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217323
    Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA [+ + +]
Author: Tamim Khan <tamim@fusetak.com>
Date:   Fri Dec 30 00:58:39 2022 -0500

    ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA
    
    [ Upstream commit 77c7248882385397cd7dffe9e1437f59f32ce2de ]
    
    Like the Asus Expertbook B2502CBA and various Asus Vivobook laptops,
    the Asus Expertbook B2402CBA has an ACPI DSDT table that describes IRQ 1
    as ActiveLow while the kernel overrides it to Edge_High. This prevents the
    keyboard from working. To fix this issue, add this laptop to the
    skip_override_table so that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216864
    Tested-by: zelenat <zelenat@gmail.com>
    Signed-off-by: Tamim Khan <tamim@fusetak.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA [+ + +]
Author: Tamim Khan <tamim@fusetak.com>
Date:   Fri Oct 14 01:19:31 2022 -0400

    ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA
    
    [ Upstream commit b5f9223a105d9b56954ad1ca3eace4eaf26c99ed ]
    
    Like the Asus Vivobook K3402ZA/K3502ZA/S5402ZA Asus Vivobook S5602ZA
    has an ACPI DSDT table the describes IRQ 1 as ActiveLow while the kernel
    overrides it to Edge_High. This prevents the keyboard on this laptop
    from working. To fix this add this laptop to the skip_override_table so
    that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216579
    Tested-by: Dzmitry <wrkedm@gmail.com>
    Signed-off-by: Tamim Khan <tamim@fusetak.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Add backlight=native DMI quirk for Apple iMac11,3 [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed May 17 11:23:58 2023 +0200

    ACPI: video: Add backlight=native DMI quirk for Apple iMac11,3
    
    [ Upstream commit 48436f2e9834b46b47b038b605c8142a1c07bc85 ]
    
    Linux defaults to picking the non-working ACPI video backlight interface
    on the Apple iMac11,3 .
    
    Add a DMI quirk to pick the working native radeon_bl0 interface instead.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: bd5d93df86a7 ("ACPI: video: Add backlight=native DMI quirk for Lenovo ThinkPad X131e (3371 AMD version)")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Add backlight=native DMI quirk for Apple iMac12,1 and iMac12,2 [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Aug 7 11:44:08 2023 +0200

    ACPI: video: Add backlight=native DMI quirk for Apple iMac12,1 and iMac12,2
    
    [ Upstream commit 8cf04bb321f036dd2e523e993897e0789bd5265c ]
    
    Linux defaults to picking the non-working ACPI video backlight interface
    on the Apple iMac12,1 and iMac12,2.
    
    Add a DMI quirk to pick the working native radeon_bl0 interface instead.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1838
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2753
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Add backlight=native DMI quirk for Lenovo ThinkPad X131e (3371 AMD version) [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed May 17 11:23:59 2023 +0200

    ACPI: video: Add backlight=native DMI quirk for Lenovo ThinkPad X131e (3371 AMD version)
    
    [ Upstream commit bd5d93df86a7ddf98a2a37e9c3751e3cb334a66c ]
    
    Linux defaults to picking the non-working ACPI video backlight interface
    on the Lenovo ThinkPad X131e (3371 AMD version).
    
    Add a DMI quirk to pick the working native radeon_bl0 interface instead.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
afs: Increase buffer size in afs_update_volume_status() [+ + +]
Author: Daniil Dulov <d.dulov@aladdin.ru>
Date:   Mon Feb 19 14:39:03 2024 +0000

    afs: Increase buffer size in afs_update_volume_status()
    
    [ Upstream commit 6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d ]
    
    The max length of volume->vid value is 20 characters.
    So increase idbuf[] size up to 24 to avoid overflow.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20240211150442.3416-1-d.dulov@aladdin.ru/ # v1
    Link: https://lore.kernel.org/r/20240212083347.10742-1-d.dulov@aladdin.ru/ # v2
    Link: https://lore.kernel.org/r/20240219143906.138346-3-dhowells@redhat.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers [+ + +]
Author: Lennert Buytenhek <kernel@wantstofly.org>
Date:   Thu Jan 25 17:04:01 2024 +0200

    ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
    
    [ Upstream commit 20730e9b277873deeb6637339edcba64468f3da3 ]
    
    With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
    ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
    observed that was immediately preceded by the following kernel
    messages:
    
    ahci 0000:28:00.0: Using 64-bit DMA addresses
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
    
    The first message is produced by code in drivers/iommu/dma-iommu.c
    which is accompanied by the following comment that seems to apply:
    
            /*
             * Try to use all the 32-bit PCI addresses first. The original SAC vs.
             * DAC reasoning loses relevance with PCIe, but enough hardware and
             * firmware bugs are still lurking out there that it's safest not to
             * venture into the 64-bit space until necessary.
             *
             * If your device goes wrong after seeing the notice then likely either
             * its driver is not setting DMA masks accurately, the hardware has
             * some inherent bug in handling >32-bit addresses, or not all the
             * expected address bits are wired up between the device and the IOMMU.
             */
    
    Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
    address 0xffffffff00000000 produces the following I/O page faults:
    
    vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
    vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
    
    Note that the upper 21 bits of the logged DMA address are zero.  (When
    asking a different PCIe device in the same PCIe slot to DMA to the
    same I/O virtual address, we do see all the upper 32 bits of the DMA
    address as 1, so this is not an issue with the chipset or IOMMU
    configuration on the test system.)
    
    Also, hacking libahci to always set the upper 21 bits of all DMA
    addresses to 1 produces no discernible effect on the behavior of the
    ASM1061, and mkfs/mount/scrub/etc work as without this hack.
    
    This all strongly suggests that the ASM1061 has a 43 bit DMA address
    limit, and this commit therefore adds a quirk to deal with this limit.
    
    This issue probably applies to (some of) the other supported ASMedia
    parts as well, but we limit it to the PCI IDs known to refer to
    ASM1061 parts, as that's the only part we know for sure to be affected
    by this issue at this point.
    
    Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
    Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
    [cassel: drop date from error messages in commit log]
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ahci: asm1166: correct count of reported ports [+ + +]
Author: Conrad Kostecki <conikost@gentoo.org>
Date:   Tue Jan 23 19:30:02 2024 +0100

    ahci: asm1166: correct count of reported ports
    
    [ Upstream commit 0077a504e1a4468669fd2e011108db49133db56e ]
    
    The ASM1166 SATA host controller always reports wrongly,
    that it has 32 ports. But in reality, it only has six ports.
    
    This seems to be a hardware issue, as all tested ASM1166
    SATA host controllers reports such high count of ports.
    
    Example output: ahci 0000:09:00.0: AHCI 0001.0301
    32 slots 32 ports 6 Gbps 0xffffff3f impl SATA mode.
    
    By adjusting the port_map, the count is limited to six ports.
    
    New output: ahci 0000:09:00.0: AHCI 0001.0301
    32 slots 32 ports 6 Gbps 0x3f impl SATA mode.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=211873
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218346
    Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: usb-audio: Check presence of valid altsetting control [+ + +]
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Mon Jan 29 15:12:54 2024 +0300

    ALSA: usb-audio: Check presence of valid altsetting control
    
    [ Upstream commit 346f59d1e8ed0eed41c80e1acb657e484c308e6a ]
    
    Many devices with a single alternate setting do not have a Valid
    Alternate Setting Control and validation performed by
    validate_sample_rate_table_v2v3() doesn't work on them and is not
    really needed. So check the presense of control before sending
    altsetting validation requests.
    
    MOTU Microbook IIc is suffering the most without this check. It
    takes up to 40 seconds to bootup due to how slow it switches
    sampling rates:
    
    [ 2659.164824] usb 3-2: New USB device found, idVendor=07fd, idProduct=0004, bcdDevice= 0.60
    [ 2659.164827] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [ 2659.164829] usb 3-2: Product: MicroBook IIc
    [ 2659.164830] usb 3-2: Manufacturer: MOTU
    [ 2659.166204] usb 3-2: Found last interface = 3
    [ 2679.322298] usb 3-2: No valid sample rate available for 1:1, assuming a firmware bug
    [ 2679.322306] usb 3-2: 1:1: add audio endpoint 0x3
    [ 2679.322321] usb 3-2: Creating new data endpoint #3
    [ 2679.322552] usb 3-2: 1:1 Set sample rate 96000, clock 1
    [ 2684.362250] usb 3-2: 2:1: cannot get freq (v2/v3): err -110
    [ 2694.444700] usb 3-2: No valid sample rate available for 2:1, assuming a firmware bug
    [ 2694.444707] usb 3-2: 2:1: add audio endpoint 0x84
    [ 2694.444721] usb 3-2: Creating new data endpoint #84
    [ 2699.482103] usb 3-2: 2:1 Set sample rate 96000, clock 1
    
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Link: https://lore.kernel.org/r/20240129121254.3454481-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Ignore clock selector errors for single connection [+ + +]
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Thu Feb 1 14:53:08 2024 +0300

    ALSA: usb-audio: Ignore clock selector errors for single connection
    
    [ Upstream commit eaa1b01fe709d6a236a9cec74813e0400601fd23 ]
    
    For devices with multiple clock sources connected to a selector, we need
    to check what a clock selector control request has returned. This is
    needed to ensure that a requested clock source is indeed selected and for
    autoclock feature to work.
    
    For devices with single clock source connected, if we get an error there
    is nothing else we can do about it. We can't skip clock selector setup as
    it is required by some devices. So lets just ignore error in this case.
    
    This should fix various buggy Mackie devices:
    
    [  649.109785] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32)
    [  649.111946] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32)
    [  649.113822] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32)
    
    There is also interesting info from the Windows documentation [1] (this
    is probably why manufacturers dont't even test this feature):
    
    "The USB Audio 2.0 driver doesn't support clock selection. The driver
    uses the Clock Source Entity, which is selected by default and never
    issues a Clock Selector Control SET CUR request."
    
    Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers [1]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217314
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218175
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218342
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Link: https://lore.kernel.org/r/20240201115308.17838-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: rockchip: add ES8316 codec for ROCK Pi 4 [+ + +]
Author: Alex Bee <knaerzche@gmail.com>
Date:   Fri Jun 18 20:12:55 2021 +0200

    arm64: dts: rockchip: add ES8316 codec for ROCK Pi 4
    
    [ Upstream commit 65bd2b8bdb3bddc37bea695789713916327e1c1f ]
    
    ROCK Pi 4 boards have the codec connected to i2s0 and it is accessible
    via i2c1 address 0x11.
    Add an audio-graph-card for it.
    
    Signed-off-by: Alex Bee <knaerzche@gmail.com>
    Link: https://lore.kernel.org/r/20210618181256.27992-5-knaerzche@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: add SPDIF node for ROCK Pi 4 [+ + +]
Author: Alex Bee <knaerzche@gmail.com>
Date:   Fri Jun 18 20:12:56 2021 +0200

    arm64: dts: rockchip: add SPDIF node for ROCK Pi 4
    
    [ Upstream commit 697dd494cb1cf56acfb764214a1e4788e4d1a983 ]
    
    Add a SPDIF audio-graph-card to ROCK Pi 4 device tree.
    
    It's not enabled by default since all dma channels are used by
    the (already) enabled i2s0/1/2 and the pin is muxed with GPIO4_C5
    which might be in use already.
    If enabled SPDIF_TX will be available at pin #15.
    
    Signed-off-by: Alex Bee <knaerzche@gmail.com>
    Link: https://lore.kernel.org/r/20210618181256.27992-6-knaerzche@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix regulator name on rk3399-rock-4 [+ + +]
Author: FUKAUMI Naoki <naoki@radxa.com>
Date:   Fri Sep 9 19:50:04 2022 +0000

    arm64: dts: rockchip: fix regulator name on rk3399-rock-4
    
    [ Upstream commit 69448624b770aa88a71536a16900dd3cc6002919 ]
    
    fix regulator name
    
    ref:
     https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf
    
    Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
    Link: https://lore.kernel.org/r/20220909195006.127957-4-naoki@radxa.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: set num-cs property for spi on px30 [+ + +]
Author: Heiko Stuebner <heiko.stuebner@cherry.de>
Date:   Fri Jan 19 11:16:56 2024 +0100

    arm64: dts: rockchip: set num-cs property for spi on px30
    
    [ Upstream commit 334bf0710c98d391f4067b72f535d6c4c84dfb6f ]
    
    The px30 has two spi controllers with two chip-selects each.
    The num-cs property is specified as the total number of chip
    selects a controllers has and is used since 2020 to find uses
    of chipselects outside that range in the Rockchip spi driver.
    
    Without the property set, the default is 1, so spi devices
    using the second chipselect will not be created.
    
    Fixes: eb1262e3cc8b ("spi: spi-rockchip: use num-cs property and ctlr->enable_gpiods")
    Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
    Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240119101656.965744-1-heiko@sntech.de
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: mm: fix VA-range sanity check [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Jun 15 11:26:28 2023 +0100

    arm64: mm: fix VA-range sanity check
    
    [ Upstream commit ab9b4008092c86dc12497af155a0901cc1156999 ]
    
    Both create_mapping_noalloc() and update_mapping_prot() sanity-check
    their 'virt' parameter, but the check itself doesn't make much sense.
    The condition used today appears to be a historical accident.
    
    The sanity-check condition:
    
            if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
                    [ ... warning here ... ]
                    return;
            }
    
    ... can only be true for the KASAN shadow region or the module region,
    and there's no reason to exclude these specifically for creating and
    updateing mappings.
    
    When arm64 support was first upstreamed in commit:
    
      c1cc1552616d0f35 ("arm64: MMU initialisation")
    
    ... the condition was:
    
            if (virt < VMALLOC_START) {
                    [ ... warning here ... ]
                    return;
            }
    
    At the time, VMALLOC_START was the lowest kernel address, and this was
    checking whether 'virt' would be translated via TTBR1.
    
    Subsequently in commit:
    
      14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
    
    ... the condition was changed to:
    
            if ((virt >= VA_START) && (virt < VMALLOC_START)) {
                    [ ... warning here ... ]
                    return;
            }
    
    This appear to have been a thinko. The commit moved the linear map to
    the bottom of the kernel address space, with VMALLOC_START being at the
    halfway point. The old condition would warn for changes to the linear
    map below this, and at the time VA_START was the end of the linear map.
    
    Subsequently we cleaned up the naming of VA_START in commit:
    
      77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END")
    
    ... keeping the erroneous condition as:
    
            if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
                    [ ... warning here ... ]
                    return;
            }
    
    Correct the condition to check against the start of the TTBR1 address
    space, which is currently PAGE_OFFSET. This simplifies the logic, and
    more clearly matches the "outside kernel range" message in the warning.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Steve Capper <steve.capper@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: set __exception_irq_entry with __irq_entry as a default [+ + +]
Author: Youngmin Nam <youngmin.nam@samsung.com>
Date:   Mon Apr 24 10:04:36 2023 +0900

    arm64: set __exception_irq_entry with __irq_entry as a default
    
    [ Upstream commit f6794950f0e5ba37e3bbedda4d6ab0aad7395dd3 ]
    
    filter_irq_stacks() is supposed to cut entries which are related irq entries
    from its call stack.
    And in_irqentry_text() which is called by filter_irq_stacks()
    uses __irqentry_text_start/end symbol to find irq entries in callstack.
    
    But it doesn't work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER",
    arm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irq
    between __irqentry_text_start and __irqentry_text_end as we discussed in below link.
    https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t
    
    This problem can makes unintentional deep call stack entries especially
    in KASAN enabled situation as below.
    
    [ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity
    [ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c
    [ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
    [ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c
    [ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c
    [ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0
    [ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000
    [ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd
    [ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040
    [ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000
    [ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20
    [ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8
    [ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800
    [ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8
    [ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c
    [ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022
    [ 2479.386231]I[0:launcher-loader: 1719] Call trace:
    [ 2479.386248]I[0:launcher-loader: 1719]  __stack_depot_save+0x464/0x46c
    [ 2479.386273]I[0:launcher-loader: 1719]  kasan_save_stack+0x58/0x70
    [ 2479.386303]I[0:launcher-loader: 1719]  save_stack_info+0x34/0x138
    [ 2479.386331]I[0:launcher-loader: 1719]  kasan_save_free_info+0x18/0x24
    [ 2479.386358]I[0:launcher-loader: 1719]  ____kasan_slab_free+0x16c/0x170
    [ 2479.386385]I[0:launcher-loader: 1719]  __kasan_slab_free+0x10/0x20
    [ 2479.386410]I[0:launcher-loader: 1719]  kmem_cache_free+0x238/0x53c
    [ 2479.386435]I[0:launcher-loader: 1719]  mempool_free_slab+0x1c/0x28
    [ 2479.386460]I[0:launcher-loader: 1719]  mempool_free+0x7c/0x1a0
    [ 2479.386484]I[0:launcher-loader: 1719]  bvec_free+0x34/0x80
    [ 2479.386514]I[0:launcher-loader: 1719]  bio_free+0x60/0x98
    [ 2479.386540]I[0:launcher-loader: 1719]  bio_put+0x50/0x21c
    [ 2479.386567]I[0:launcher-loader: 1719]  f2fs_write_end_io+0x4ac/0x4d0
    [ 2479.386594]I[0:launcher-loader: 1719]  bio_endio+0x2dc/0x300
    [ 2479.386622]I[0:launcher-loader: 1719]  __dm_io_complete+0x324/0x37c
    [ 2479.386650]I[0:launcher-loader: 1719]  dm_io_dec_pending+0x60/0xa4
    [ 2479.386676]I[0:launcher-loader: 1719]  clone_endio+0xf8/0x2f0
    [ 2479.386700]I[0:launcher-loader: 1719]  bio_endio+0x2dc/0x300
    [ 2479.386727]I[0:launcher-loader: 1719]  blk_update_request+0x258/0x63c
    [ 2479.386754]I[0:launcher-loader: 1719]  scsi_end_request+0x50/0x304
    [ 2479.386782]I[0:launcher-loader: 1719]  scsi_io_completion+0x88/0x160
    [ 2479.386808]I[0:launcher-loader: 1719]  scsi_finish_command+0x17c/0x194
    [ 2479.386833]I[0:launcher-loader: 1719]  scsi_complete+0xcc/0x158
    [ 2479.386859]I[0:launcher-loader: 1719]  blk_mq_complete_request+0x4c/0x5c
    [ 2479.386885]I[0:launcher-loader: 1719]  scsi_done_internal+0xf4/0x1e0
    [ 2479.386910]I[0:launcher-loader: 1719]  scsi_done+0x14/0x20
    [ 2479.386935]I[0:launcher-loader: 1719]  ufshcd_compl_one_cqe+0x578/0x71c
    [ 2479.386963]I[0:launcher-loader: 1719]  ufshcd_mcq_poll_cqe_nolock+0xc8/0x150
    [ 2479.386991]I[0:launcher-loader: 1719]  ufshcd_intr+0x868/0xc0c
    [ 2479.387017]I[0:launcher-loader: 1719]  __handle_irq_event_percpu+0xd0/0x348
    [ 2479.387044]I[0:launcher-loader: 1719]  handle_irq_event_percpu+0x24/0x74
    [ 2479.387068]I[0:launcher-loader: 1719]  handle_irq_event+0x74/0xe0
    [ 2479.387091]I[0:launcher-loader: 1719]  handle_fasteoi_irq+0x174/0x240
    [ 2479.387118]I[0:launcher-loader: 1719]  handle_irq_desc+0x7c/0x2c0
    [ 2479.387147]I[0:launcher-loader: 1719]  generic_handle_domain_irq+0x1c/0x28
    [ 2479.387174]I[0:launcher-loader: 1719]  gic_handle_irq+0x64/0x158
    [ 2479.387204]I[0:launcher-loader: 1719]  call_on_irq_stack+0x2c/0x54
    [ 2479.387231]I[0:launcher-loader: 1719]  do_interrupt_handler+0x70/0xa0
    [ 2479.387258]I[0:launcher-loader: 1719]  el1_interrupt+0x34/0x68
    [ 2479.387283]I[0:launcher-loader: 1719]  el1h_64_irq_handler+0x18/0x24
    [ 2479.387308]I[0:launcher-loader: 1719]  el1h_64_irq+0x68/0x6c
    [ 2479.387332]I[0:launcher-loader: 1719]  blk_attempt_bio_merge+0x8/0x170
    [ 2479.387356]I[0:launcher-loader: 1719]  blk_mq_attempt_bio_merge+0x78/0x98
    [ 2479.387383]I[0:launcher-loader: 1719]  blk_mq_submit_bio+0x324/0xa40
    [ 2479.387409]I[0:launcher-loader: 1719]  __submit_bio+0x104/0x138
    [ 2479.387436]I[0:launcher-loader: 1719]  submit_bio_noacct_nocheck+0x1d0/0x4a0
    [ 2479.387462]I[0:launcher-loader: 1719]  submit_bio_noacct+0x618/0x804
    [ 2479.387487]I[0:launcher-loader: 1719]  submit_bio+0x164/0x180
    [ 2479.387511]I[0:launcher-loader: 1719]  f2fs_submit_read_bio+0xe4/0x1c4
    [ 2479.387537]I[0:launcher-loader: 1719]  f2fs_mpage_readpages+0x888/0xa4c
    [ 2479.387563]I[0:launcher-loader: 1719]  f2fs_readahead+0xd4/0x19c
    [ 2479.387587]I[0:launcher-loader: 1719]  read_pages+0xb0/0x4ac
    [ 2479.387614]I[0:launcher-loader: 1719]  page_cache_ra_unbounded+0x238/0x288
    [ 2479.387642]I[0:launcher-loader: 1719]  do_page_cache_ra+0x60/0x6c
    [ 2479.387669]I[0:launcher-loader: 1719]  page_cache_ra_order+0x318/0x364
    [ 2479.387695]I[0:launcher-loader: 1719]  ondemand_readahead+0x30c/0x3d8
    [ 2479.387722]I[0:launcher-loader: 1719]  page_cache_sync_ra+0xb4/0xc8
    [ 2479.387749]I[0:launcher-loader: 1719]  filemap_read+0x268/0xd24
    [ 2479.387777]I[0:launcher-loader: 1719]  f2fs_file_read_iter+0x1a0/0x62c
    [ 2479.387806]I[0:launcher-loader: 1719]  vfs_read+0x258/0x34c
    [ 2479.387831]I[0:launcher-loader: 1719]  ksys_pread64+0x8c/0xd0
    [ 2479.387857]I[0:launcher-loader: 1719]  __arm64_sys_pread64+0x48/0x54
    [ 2479.387881]I[0:launcher-loader: 1719]  invoke_syscall+0x58/0x158
    [ 2479.387909]I[0:launcher-loader: 1719]  el0_svc_common+0xf0/0x134
    [ 2479.387935]I[0:launcher-loader: 1719]  do_el0_svc+0x44/0x114
    [ 2479.387961]I[0:launcher-loader: 1719]  el0_svc+0x2c/0x80
    [ 2479.387985]I[0:launcher-loader: 1719]  el0t_64_sync_handler+0x48/0x114
    [ 2479.388010]I[0:launcher-loader: 1719]  el0t_64_sync+0x190/0x194
    [ 2479.388038]I[0:launcher-loader: 1719] Kernel panic - not syncing: kernel: panic_on_warn set ...
    
    So let's set __exception_irq_entry with __irq_entry as a default.
    Applying this patch, we can see gic_hande_irq is included in Systemp.map as below.
    
    * Before
    ffffffc008010000 T __do_softirq
    ffffffc008010000 T __irqentry_text_end
    ffffffc008010000 T __irqentry_text_start
    ffffffc008010000 T __softirqentry_text_start
    ffffffc008010000 T _stext
    ffffffc00801066c T __softirqentry_text_end
    ffffffc008010670 T __entry_text_start
    
    * After
    ffffffc008010000 T __irqentry_text_start
    ffffffc008010000 T _stext
    ffffffc008010000 t gic_handle_irq
    ffffffc00801013c t gic_handle_irq
    ffffffc008010294 T __irqentry_text_end
    ffffffc008010298 T __do_softirq
    ffffffc008010298 T __softirqentry_text_start
    ffffffc008010904 T __softirqentry_text_end
    ffffffc008010908 T __entry_text_start
    
    Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
    Signed-off-by: SEO HOYOUNG <hy50.seo@samsung.com>
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20230424010436.779733-1-youngmin.nam@samsung.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Mon Sep 20 16:10:23 2021 +0200

    ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch
    
    [ Upstream commit 9fb90ae6cae7f8fe4fbf626945f32cd9da2c3892 ]
    
    BCM53573 family SoC have Ethernet switch connected to the first Ethernet
    controller (accessible over MDIO).
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Drop nonexistent "default-off" LED trigger [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Jul 7 13:40:01 2023 +0200

    ARM: dts: BCM53573: Drop nonexistent "default-off" LED trigger
    
    [ Upstream commit be7e1e5b0f67c58ec4be0a54db23b6a4fa6e2116 ]
    
    There is no such trigger documented or implemented in Linux. It was a
    copy & paste mistake.
    
    This fixes:
    arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: leds: led-wlan:linux,default-trigger: 'oneOf' conditional failed, one must be fixed:
            'default-off' is not one of ['backlight', 'default-on', 'heartbeat', 'disk-activity', 'disk-read', 'disk-write', 'timer', 'pattern', 'audio-micmute', 'audio-mute', 'bluetooth-power', 'flash', 'kbd-capslock', 'mtd', 'nand-disk', 'none', 'torch', 'usb-gadget', 'usb-host', 'usbport']
            'default-off' does not match '^cpu[0-9]*$'
            'default-off' does not match '^hci[0-9]+-power$'
            'default-off' does not match '^mmc[0-9]+$'
            'default-off' does not match '^phy[0-9]+tx$'
            From schema: Documentation/devicetree/bindings/leds/leds-gpio.yaml
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230707114004.2740-1-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Drop nonexistent #usb-cells [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Jul 7 13:40:02 2023 +0200

    ARM: dts: BCM53573: Drop nonexistent #usb-cells
    
    [ Upstream commit 05d2c3d552b8c92fc397377d9d1112fc58e2cd59 ]
    
    Such property simply doesn't exist (is not documented or used anywhere).
    
    This fixes:
    arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: usb@d000: Unevaluated properties are not allowed ('#usb-cells' was unexpected)
            From schema: Documentation/devicetree/bindings/usb/generic-ohci.yaml
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230707114004.2740-2-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: ep93xx: Add terminator to gpiod_lookup_table [+ + +]
Author: Nikita Shubin <nikita.shubin@maquefel.me>
Date:   Mon Feb 5 11:23:34 2024 +0100

    ARM: ep93xx: Add terminator to gpiod_lookup_table
    
    commit fdf87a0dc26d0550c60edc911cda42f9afec3557 upstream.
    
    Without the terminator, if a con_id is passed to gpio_find() that
    does not exist in the lookup table the function will not stop looping
    correctly, and eventually cause an oops.
    
    Cc: stable@vger.kernel.org
    Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors")
    Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com>
    Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Link: https://lore.kernel.org/r/20240205102337.439002-1-alexander.sverdlin@gmail.com
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arp: Prevent overflow in arp_req_get(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Feb 15 15:05:16 2024 -0800

    arp: Prevent overflow in arp_req_get().
    
    commit a7d6027790acea24446ddd6632d394096c0f4667 upstream.
    
    syzkaller reported an overflown write in arp_req_get(). [0]
    
    When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
    entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
    
    The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
    the sa_data buffer is just 14 bytes.
    
    In the splat below, 2 bytes are overflown to the next int field,
    arp_flags.  We initialise the field just after the memcpy(), so it's
    not a problem.
    
    However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
    arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
    in arp_ioctl() before calling arp_req_get().
    
    To avoid the overflow, let's limit the max length of memcpy().
    
    Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
    array in struct sockaddr") just silenced syzkaller.
    
    [0]:
    memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
    WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
    Modules linked in:
    CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
    RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
    Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
    RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
    RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
    R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
    FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
     inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
     sock_do_ioctl+0xdf/0x260 net/socket.c:1204
     sock_ioctl+0x3ef/0x650 net/socket.c:1321
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:870 [inline]
     __se_sys_ioctl fs/ioctl.c:856 [inline]
     __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x64/0xce
    RIP: 0033:0x7f172b262b8d
    Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
    RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
    RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
     </TASK>
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Reported-by: Bjoern Doebel <doebel@amazon.de>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240215230516.31330-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: sunxi: sun4i-spdif: Add support for Allwinner H616 [+ + +]
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Sun Jan 28 00:32:43 2024 +0800

    ASoC: sunxi: sun4i-spdif: Add support for Allwinner H616
    
    [ Upstream commit 0adf963b8463faa44653e22e56ce55f747e68868 ]
    
    The SPDIF hardware block found in the H616 SoC has the same layout as
    the one found in the H6 SoC, except that it is missing the receiver
    side.
    
    Since the driver currently only supports the transmit function, support
    for the H616 is identical to what is currently done for the H6.
    
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://msgid.link/r/20240127163247.384439-4-wens@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: ahci_ceva: fix error handling for Xilinx GT PHY support [+ + +]
Author: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Date:   Fri Feb 16 23:44:57 2024 +0530

    ata: ahci_ceva: fix error handling for Xilinx GT PHY support
    
    [ Upstream commit 26c8404e162b43dddcb037ba2d0cb58c0ed60aab ]
    
    Platform clock and phy error resources are not cleaned up in Xilinx GT PHY
    error path.
    
    To fix introduce the function ceva_ahci_platform_enable_resources() which
    is a customized version of ahci_platform_enable_resources() and inline with
    SATA IP programming sequence it does:
    
    - Assert SATA reset
    - Program PS GTR phy
    - Bring SATA by de-asserting the reset
    - Wait for GT lane PLL to be locked
    
    ceva_ahci_platform_enable_resources() is also used in the resume path
    as the same SATA programming sequence (as in probe) should be followed.
    Also cleanup the mixed usage of ahci_platform_enable_resources() and custom
    implementation in the probe function as both are not required.
    
    Fixes: 9a9d3abe24bb ("ata: ahci: ceva: Update the driver to support xilinx GT phy")
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ata: libahci_platform: Convert to using devm bulk clocks API [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Sep 9 22:36:05 2022 +0300

    ata: libahci_platform: Convert to using devm bulk clocks API
    
    [ Upstream commit e28b3abf8020a884bd3b7758ea8915365af8fadf ]
    
    In order to simplify the clock-related code there is a way to convert the
    current fixed clocks array into using the common bulk clocks kernel API
    with dynamic set of the clock handlers and device-managed clock-resource
    tracking. It's a bit tricky due to the complication coming from the
    requirement to support the platforms (da850, spear13xx) with the
    non-OF-based clock source, but still doable.
    
    Before this modification there are two methods have been used to get the
    clocks connected to an AHCI device: clk_get() - to get the very first
    clock in the list and of_clk_get() - to get the rest of them. Basically
    the platforms with non-OF-based clocks definition could specify only a
    single reference clock source. The platforms with OF-hw clocks have been
    luckier and could setup up to AHCI_MAX_CLKS clocks. Such semantic can be
    retained with using devm_clk_bulk_get_all() to retrieve the clocks defined
    via the DT firmware and devm_clk_get_optional() otherwise. In both cases
    using the device-managed version of the methods will cause the automatic
    resources deallocation on the AHCI device removal event. The only
    complicated part in the suggested approach is the explicit allocation and
    initialization of the clk_bulk_data structure instance for the non-OF
    reference clocks. It's required in order to use the Bulk Clocks API for
    the both denoted cases of the clocks definition.
    
    Note aside with the clock-related code reduction and natural
    simplification, there are several bonuses the suggested modification
    provides. First of all the limitation of having no greater than
    AHCI_MAX_CLKS clocks is now removed, since the devm_clk_bulk_get_all()
    method will allocate as many reference clocks data descriptors as there
    are clocks specified for the device. Secondly the clock names are
    auto-detected. So the LLDD (glue) drivers can make sure that the required
    clocks are specified just by checking the clock IDs in the clk_bulk_data
    array.  Thirdly using the handy Bulk Clocks kernel API improves the
    clocks-handling code readability. And the last but not least this
    modification implements a true optional clocks support to the
    ahci_platform_get_resources() method. Indeed the previous clocks getting
    procedure just stopped getting the clocks on any errors (aside from
    non-critical -EPROBE_DEFER) in a way so the callee wasn't even informed
    about abnormal loop termination. The new implementation lacks of such
    problem. The ahci_platform_get_resources() will return an error code if
    the corresponding clocks getting method ends execution abnormally.
    
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Stable-dep-of: 26c8404e162b ("ata: ahci_ceva: fix error handling for Xilinx GT PHY support")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ata: libahci_platform: Introduce reset assertion/deassertion methods [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Sep 9 22:36:08 2022 +0300

    ata: libahci_platform: Introduce reset assertion/deassertion methods
    
    [ Upstream commit f67f12ff57bcfcd7d64280f748787793217faeaf ]
    
    Currently the ACHI-platform library supports only the assert and deassert
    reset signals and ignores the platforms with self-deasserting reset lines.
    That prone to having the platforms with self-deasserting reset method
    misbehaviour when it comes to resuming from sleep state after the clocks
    have been fully disabled. For such cases the controller needs to be fully
    reset all over after the reference clocks are enabled and stable,
    otherwise the controller state machine might be in an undetermined state.
    
    The best solution would be to auto-detect which reset method is supported
    by the particular platform and use it implicitly in the framework of the
    ahci_platform_enable_resources()/ahci_platform_disable_resources()
    methods. Alas it can't be implemented due to the AHCI-platform library
    already supporting the shared reset control lines. As [1] says in such
    case we have to use only one of the next methods:
    + reset_control_assert()/reset_control_deassert();
    + reset_control_reset()/reset_control_rearm().
    If the driver had an exclusive control over the reset lines we could have
    been able to manipulate the lines with no much limitation and just used
    the combination of the methods above to cover all the possible
    reset-control cases. Since the shared reset control has already been
    advertised and couldn't be changed with no risk to breaking the platforms
    relying on it, we have no choice but to make the platform drivers to
    determine which reset methods the platform reset system supports.
    
    In order to implement both types of reset control support we suggest to
    introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which
    when passed to the ahci_platform_get_resources() method together with the
    AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are
    self-deasserting thus the reset_control_reset()/reset_control_rearm() will
    be used to control the reset state. Otherwise the
    reset_control_deassert()/reset_control_assert() methods will be utilized.
    
    [1] Documentation/driver-api/reset.rst
    
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Stable-dep-of: 26c8404e162b ("ata: ahci_ceva: fix error handling for Xilinx GT PHY support")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, scripts: Correct GPL license name [+ + +]
Author: Gianmarco Lusvardi <glusvardi@posteo.net>
Date:   Tue Feb 13 23:05:46 2024 +0000

    bpf, scripts: Correct GPL license name
    
    [ Upstream commit e37243b65d528a8a9f8b9a57a43885f8e8dfc15c ]
    
    The bpf_doc script refers to the GPL as the "GNU Privacy License".
    I strongly suspect that the author wanted to refer to the GNU General
    Public License, under which the Linux kernel is released, as, to the
    best of my knowledge, there is no license named "GNU Privacy License".
    This patch corrects the license name in the script accordingly.
    
    Fixes: 56a092c89505 ("bpf: add script and prepare bpf.h for new helpers documentation")
    Signed-off-by: Gianmarco Lusvardi <glusvardi@posteo.net>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240213230544.930018-3-glusvardi@posteo.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add struct for bin_args arg in bpf_bprintf_prepare [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Sat Feb 17 09:13:19 2024 -0300

    bpf: Add struct for bin_args arg in bpf_bprintf_prepare
    
    commit 78aa1cc9404399a15d2a1205329c6a06236f5378 upstream.
    
    Adding struct bpf_bprintf_data to hold bin_args argument for
    bpf_bprintf_prepare function.
    
    We will add another return argument to bpf_bprintf_prepare and
    pass the struct to bpf_bprintf_cleanup for proper cleanup in
    following changes.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221215214430.1336195-2-jolsa@kernel.org
    [cascardo: there is no bpf_trace_vprintk in 5.15]
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: Address KCSAN report on bpf_lru_list [+ + +]
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Wed May 10 21:37:48 2023 -0700

    bpf: Address KCSAN report on bpf_lru_list
    
    [ Upstream commit ee9fd0ac3017c4313be91a220a9ac4c99dde7ad4 ]
    
    KCSAN reported a data-race when accessing node->ref.
    Although node->ref does not have to be accurate,
    take this chance to use a more common READ_ONCE() and WRITE_ONCE()
    pattern instead of data_race().
    
    There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().
    This patch also adds bpf_lru_node_clear_ref() to do the
    WRITE_ONCE(node->ref, 0) also.
    
    ==================================================================
    BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elem
    
    write to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:
    __bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]
    __bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]
    __bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240
    bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]
    bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]
    bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499
    prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]
    __htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316
    bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313
    bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200
    generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687
    bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534
    __sys_bpf+0x338/0x810
    __do_sys_bpf kernel/bpf/syscall.c:5096 [inline]
    __se_sys_bpf kernel/bpf/syscall.c:5094 [inline]
    __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:
    bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]
    __htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332
    bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313
    bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200
    generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687
    bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534
    __sys_bpf+0x338/0x810
    __do_sys_bpf kernel/bpf/syscall.c:5096 [inline]
    __se_sys_bpf kernel/bpf/syscall.c:5094 [inline]
    __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x01 -> 0x00
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
    ==================================================================
    
    Reported-by: syzbot+ebe648a84e8784763f82@syzkaller.appspotmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20230511043748.1384166-1-martin.lau@linux.dev
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Do cleanup in bpf_bprintf_cleanup only when needed [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Sat Feb 17 09:13:20 2024 -0300

    bpf: Do cleanup in bpf_bprintf_cleanup only when needed
    
    commit f19a4050455aad847fb93f18dc1fe502eb60f989 upstream.
    
    Currently we always cleanup/decrement bpf_bprintf_nest_level variable
    in bpf_bprintf_cleanup if it's > 0.
    
    There's possible scenario where this could cause a problem, when
    bpf_bprintf_prepare does not get bin_args buffer (because num_args is 0)
    and following bpf_bprintf_cleanup call decrements bpf_bprintf_nest_level
    variable, like:
    
      in task context:
        bpf_bprintf_prepare(num_args != 0) increments 'bpf_bprintf_nest_level = 1'
        -> first irq :
           bpf_bprintf_prepare(num_args == 0)
           bpf_bprintf_cleanup decrements 'bpf_bprintf_nest_level = 0'
        -> second irq:
           bpf_bprintf_prepare(num_args != 0) bpf_bprintf_nest_level = 1
           gets same buffer as task context above
    
    Adding check to bpf_bprintf_cleanup and doing the real cleanup only if we
    got bin_args data in the first place.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221215214430.1336195-3-jolsa@kernel.org
    [cascardo: there is no bpf_trace_vprintk in 5.15]
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel [+ + +]
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Thu Feb 15 13:12:17 2024 -0800

    bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel
    
    [ Upstream commit 0281b919e175bb9c3128bd3872ac2903e9436e3f ]
    
    The following race is possible between bpf_timer_cancel_and_free
    and bpf_timer_cancel. It will lead a UAF on the timer->timer.
    
    bpf_timer_cancel();
            spin_lock();
            t = timer->time;
            spin_unlock();
    
                                            bpf_timer_cancel_and_free();
                                                    spin_lock();
                                                    t = timer->timer;
                                                    timer->timer = NULL;
                                                    spin_unlock();
                                                    hrtimer_cancel(&t->timer);
                                                    kfree(t);
    
            /* UAF on t */
            hrtimer_cancel(&t->timer);
    
    In bpf_timer_cancel_and_free, this patch frees the timer->timer
    after a rcu grace period. This requires a rcu_head addition
    to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,
    this does not need a kfree_rcu because it is still under the
    spin_lock and timer->timer has not been visible by others yet.
    
    In bpf_timer_cancel, rcu_read_lock() is added because this helper
    can be used in a non rcu critical section context (e.g. from
    a sleepable bpf prog). Other timer->timer usages in helpers.c
    have been audited, bpf_timer_cancel() is the only place where
    timer->timer is used outside of the spin_lock.
    
    Another solution considered is to mark a t->flag in bpf_timer_cancel
    and clear it after hrtimer_cancel() is done.  In bpf_timer_cancel_and_free,
    it busy waits for the flag to be cleared before kfree(t). This patch
    goes with a straight forward solution and frees timer->timer after
    a rcu grace period.
    
    Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.")
    Suggested-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/bpf/20240215211218.990808-1-martin.lau@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Merge printk and seq_printf VARARG max macros [+ + +]
Author: Dave Marchevsky <davemarchevsky@fb.com>
Date:   Sat Feb 17 09:13:18 2024 -0300

    bpf: Merge printk and seq_printf VARARG max macros
    
    commit 335ff4990cf3bfa42d8846f9b3d8c09456f51801 upstream.
    
    MAX_SNPRINTF_VARARGS and MAX_SEQ_PRINTF_VARARGS are used by bpf helpers
    bpf_snprintf and bpf_seq_printf to limit their varargs. Both call into
    bpf_bprintf_prepare for print formatting logic and have convenience
    macros in libbpf (BPF_SNPRINTF, BPF_SEQ_PRINTF) which use the same
    helper macros to convert varargs to a byte array.
    
    Changing shared functionality to support more varargs for either bpf
    helper would affect the other as well, so let's combine the _VARARGS
    macros to make this more obvious.
    
    Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20210917182911.2426606-2-davemarchevsky@fb.com
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: Remove trace_printk_lock [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Sat Feb 17 09:13:21 2024 -0300

    bpf: Remove trace_printk_lock
    
    commit e2bb9e01d589f7fa82573aedd2765ff9b277816a upstream.
    
    Both bpf_trace_printk and bpf_trace_vprintk helpers use static buffer guarded
    with trace_printk_lock spin lock.
    
    The spin lock contention causes issues with bpf programs attached to
    contention_begin tracepoint [1][2].
    
    Andrii suggested we could get rid of the contention by using trylock, but we
    could actually get rid of the spinlock completely by using percpu buffers the
    same way as for bin_args in bpf_bprintf_prepare function.
    
    Adding new return 'buf' argument to struct bpf_bprintf_data and making
    bpf_bprintf_prepare to return also the buffer for printk helpers.
    
      [1] https://lore.kernel.org/bpf/CACkBjsakT_yWxnSWr4r-0TpPvbKm9-OBmVUhJb7hV3hY8fdCkw@mail.gmail.com/
      [2] https://lore.kernel.org/bpf/CACkBjsaCsTovQHFfkqJKto6S4Z8d02ud1D7MPESrHa1cVNNTrw@mail.gmail.com/
    
    Reported-by: Hao Sun <sunhao.th@gmail.com>
    Suggested-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221215214430.1336195-4-jolsa@kernel.org
    [cascardo: there is no bpf_trace_vprintk in 5.15]
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: add xxhash to fast checksum implementations [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Apr 4 00:06:02 2023 +0200

    btrfs: add xxhash to fast checksum implementations
    
    [ Upstream commit efcfcbc6a36195c42d98e0ee697baba36da94dc8 ]
    
    The implementation of XXHASH is now CPU only but still fast enough to be
    considered for the synchronous checksumming, like non-generic crc32c.
    
    A userspace benchmark comparing it to various implementations (patched
    hash-speedtest from btrfs-progs):
    
      Block size:     4096
      Iterations:     1000000
      Implementation: builtin
      Units:          CPU cycles
    
            NULL-NOP: cycles:     73384294, cycles/i       73
         NULL-MEMCPY: cycles:    228033868, cycles/i      228,    61664.320 MiB/s
          CRC32C-ref: cycles:  24758559416, cycles/i    24758,      567.950 MiB/s
           CRC32C-NI: cycles:   1194350470, cycles/i     1194,    11773.433 MiB/s
      CRC32C-ADLERSW: cycles:   6150186216, cycles/i     6150,     2286.372 MiB/s
      CRC32C-ADLERHW: cycles:    626979180, cycles/i      626,    22427.453 MiB/s
          CRC32C-PCL: cycles:    466746732, cycles/i      466,    30126.699 MiB/s
              XXHASH: cycles:    860656400, cycles/i      860,    16338.188 MiB/s
    
    Comparing purely software implementation (ref), current outdated
    accelerated using crc32q instruction (NI), optimized implementations by
    M. Adler (https://stackoverflow.com/questions/17645167/implementing-sse-4-2s-crc32c-in-software/17646775#17646775)
    and the best one that was taken from kernel using the PCLMULQDQ
    instruction (PCL).
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: add a warning when the in-flight count goes negative [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Fri Jun 9 17:46:56 2023 +0000

    cifs: add a warning when the in-flight count goes negative
    
    [ Upstream commit e4645cc2f1e2d6f268bb8dcfac40997c52432aed ]
    
    We've seen the in-flight count go into negative with some
    internal stress testing in Microsoft.
    
    Adding a WARN when this happens, in hope of understanding
    why this happens when it happens.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Bharath SM <bharathsm@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: fix mid leak during reconnection after timeout threshold [+ + +]
Author: Shyam Prasad N <nspmangalore@gmail.com>
Date:   Fri Jul 14 08:56:33 2023 +0000

    cifs: fix mid leak during reconnection after timeout threshold
    
    commit 69cba9d3c1284e0838ae408830a02c4a063104bc upstream.
    
    When the number of responses with status of STATUS_IO_TIMEOUT
    exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect
    the connection. But we do not return the mid, or the credits
    returned for the mid, or reduce the number of in-flight requests.
    
    This bug could result in the server->in_flight count to go bad,
    and also cause a leak in the mids.
    
    This change moves the check to a few lines below where the
    response is decrypted, even of the response is read from the
    transform header. This way, the code for returning the mids
    can be reused.
    
    Also, the cifs_reconnect was reconnecting just the transport
    connection before. In case of multi-channel, this may not be
    what we want to do after several timeouts. Changed that to
    reconnect the session and the tree too.
    
    Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name
    MAX_STATUS_IO_TIMEOUT.
    
    Fixes: 8e670f77c4a5 ("Handle STATUS_IO_TIMEOUT gracefully")
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [Harshit: Backport to 5.15.y]
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: remove useless parameter 'is_fsctl' from SMB2_ioctl() [+ + +]
Author: Enzo Matsumiya <ematsumiya@suse.de>
Date:   Wed Aug 17 16:08:34 2022 -0300

    cifs: remove useless parameter 'is_fsctl' from SMB2_ioctl()
    
    [ Upstream commit 400d0ad63b190895e29f43bc75b1260111d3fd34 ]
    
    SMB2_ioctl() is always called with is_fsctl = true, so doesn't make any
    sense to have it at all.
    
    Thus, always set SMB2_0_IOCTL_IS_FSCTL flag on the request.
    
    Also, as per MS-SMB2 3.3.5.15 "Receiving an SMB2 IOCTL Request", servers
    must fail the request if the request flags is zero anyway.
    
    Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: Honor CLK_OPS_PARENT_ENABLE in clk_core_is_enabled() [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Tue Jan 3 17:23:30 2023 +0800

    clk: Honor CLK_OPS_PARENT_ENABLE in clk_core_is_enabled()
    
    [ Upstream commit 79200d5851c8e7179f68a4a6f162d8f1bde4986f ]
    
    In the previous commits that added CLK_OPS_PARENT_ENABLE, support for
    this flag was only added to rate change operations (rate setting and
    reparent) and disabling unused subtree. It was not added to the
    clock gate related operations. Any hardware driver that needs it for
    these operations will either see bogus results, or worse, hang.
    
    This has been seen on MT8192 and MT8195, where the imp_ii2_* clk
    drivers set this, but dumping debugfs clk_summary would cause it
    to hang.
    
    Prepare parent on prepare and enable parent on enable dependencies are
    already handled automatically by the core as part of its sequencing.
    Whether the case for "enable parent on prepare" should be supported by
    this flag or not is not clear, and thus ignored for now.
    
    This change solely fixes the handling of clk_core_is_enabled, i.e.
    enabling the parent clock when reading the hardware state. Unfortunately
    clk_core_is_enabled is called in a variety of places, sometimes with
    the enable clock already held. To avoid deadlocking, the core will
    ignore readouts and just return false if CLK_OPS_PARENT_ENABLE is set
    but the parent isn't currently enabled.
    
    Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
    Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20230103092330.494102-1-wenst@chromium.org
    Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

clk: imx: avoid memory leak [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Wed Jan 4 19:00:29 2023 +0800

    clk: imx: avoid memory leak
    
    [ Upstream commit f4419db4086e8c31821da14140e81498516a3c75 ]
    
    In case imx_register_uart_clocks return early, the imx_uart_clocks
    memory will be no freed. So execute kfree always to avoid memory leak.
    
    Fixes: 379c9a24cc23 ("clk: imx: Fix reparenting of UARTs not associated with stdout")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20230104110032.1220721-2-peng.fan@oss.nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

clk: linux/clk-provider.h: fix kernel-doc warnings and typos [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Sep 30 15:14:26 2023 -0700

    clk: linux/clk-provider.h: fix kernel-doc warnings and typos
    
    [ Upstream commit 84aefafe6b294041b7fa0757414c4a29c1bdeea2 ]
    
    Fix spelling of "Structure".
    
    Fix multiple kernel-doc warnings:
    
    clk-provider.h:269: warning: Function parameter or member 'recalc_rate' not described in 'clk_ops'
    clk-provider.h:468: warning: Function parameter or member 'parent_data' not described in 'clk_hw_register_fixed_rate_with_accuracy_parent_data'
    clk-provider.h:468: warning: Excess function parameter 'parent_name' description in 'clk_hw_register_fixed_rate_with_accuracy_parent_data'
    clk-provider.h:482: warning: Function parameter or member 'parent_data' not described in 'clk_hw_register_fixed_rate_parent_accuracy'
    clk-provider.h:482: warning: Excess function parameter 'parent_name' description in 'clk_hw_register_fixed_rate_parent_accuracy'
    clk-provider.h:687: warning: Function parameter or member 'flags' not described in 'clk_divider'
    clk-provider.h:1164: warning: Function parameter or member 'flags' not described in 'clk_fractional_divider'
    clk-provider.h:1164: warning: Function parameter or member 'approximation' not described in 'clk_fractional_divider'
    clk-provider.h:1213: warning: Function parameter or member 'flags' not described in 'clk_multiplier'
    
    Fixes: 9fba738a53dd ("clk: add duty cycle support")
    Fixes: b2476490ef11 ("clk: introduce the common clock framework")
    Fixes: 2d34f09e79c9 ("clk: fixed-rate: Add support for specifying parents via DT/pointers")
    Fixes: f5290d8e4f0c ("clk: asm9260: use parent index to link the reference clock")
    Fixes: 9d9f78ed9af0 ("clk: basic clock hardware types")
    Fixes: e2d0e90fae82 ("clk: new basic clk type for fractional divider")
    Fixes: f2e0a53271a4 ("clk: Add a basic multiplier clock")
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: linux-clk@vger.kernel.org
    Link: https://lore.kernel.org/r/20230930221428.18463-1-rdunlap@infradead.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-qcs404: disable gpll[04]_out_aux parents [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Dec 26 06:21:43 2022 +0200

    clk: qcom: gcc-qcs404: disable gpll[04]_out_aux parents
    
    [ Upstream commit 712c64caf31374de57aa193a9dff57172b2f6f82 ]
    
    On the QCS404 platform the driver for the Global Clock Controller
    doens't define gpll0_out_aux and gpll4_out_aux clocks, so it's not
    possible to use them as parents. Remove entries for these clocks.
    
    Note: backporting this patch to earlier kernels would also require a
    previous patch which switches the gcc driver to use ARRAY_SIZE for
    parent data arrays.
    
    Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for QCS404")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221226042154.2666748-6-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-qcs404: fix names of the DSI clocks used as parents [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Dec 26 06:21:44 2022 +0200

    clk: qcom: gcc-qcs404: fix names of the DSI clocks used as parents
    
    [ Upstream commit 47d94d30cd3dcc743241b4208b1eec7247610c84 ]
    
    The QCS404 uses 28nm LPM DSI PHY, which registers dsi0pll and
    dsi0pllbyte clocks. Fix all DSI PHY clock names used as parents inside
    the GCC driver.
    
    Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for QCS404")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221226042154.2666748-7-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gpucc-sc7180: fix clk_dis_wait being programmed for CX GDSC [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Feb 1 19:23:04 2023 +0200

    clk: qcom: gpucc-sc7180: fix clk_dis_wait being programmed for CX GDSC
    
    [ Upstream commit 658c82caffa042b351f5a1b6325819297a951a04 ]
    
    The gdsc_init() function will rewrite the CLK_DIS_WAIT field while
    registering the GDSC (writing the value 0x2 by default). This will
    override the setting done in the driver's probe function.
    
    Set cx_gdsc.clk_dis_wait_val to 8 to follow the intention of the probe
    function.
    
    Fixes: 745ff069a49c ("clk: qcom: Add graphics clock controller driver for SC7180")
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230201172305.993146-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gpucc-sdm845: fix clk_dis_wait being programmed for CX GDSC [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Feb 1 19:23:05 2023 +0200

    clk: qcom: gpucc-sdm845: fix clk_dis_wait being programmed for CX GDSC
    
    [ Upstream commit cb81719e3c1165ef1bc33137dc628f750eed8ea4 ]
    
    The gdsc_init() function will rewrite the CLK_DIS_WAIT field while
    registering the GDSC (writing the value 0x2 by default). This will
    override the setting done in the driver's probe function.
    
    Set cx_gdsc.clk_dis_wait_val to 8 to follow the intention of the probe
    function.
    
    Fixes: 453361cdd757 ("clk: qcom: Add graphics clock controller driver for SDM845")
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230201172305.993146-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: cpg-mssr: Fix use after free if cpg_mssr_common_init() failed [+ + +]
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Fri Dec 23 17:40:17 2022 +0300

    clk: renesas: cpg-mssr: Fix use after free if cpg_mssr_common_init() failed
    
    [ Upstream commit fbfd614aeaa2853c2c575299dfe2458db8eff67e ]
    
    If cpg_mssr_common_init() fails after assigning priv to global variable
    cpg_mssr_priv, it deallocates priv, but cpg_mssr_priv keeps dangling
    pointer that potentially can be used later.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 1f7db7bbf031 ("clk: renesas: cpg-mssr: Add early clock support")
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/1671806417-32623-1-git-send-email-khoroshilov@ispras.ru
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: cpg-mssr: Remove superfluous check in resume code [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Jan 11 09:23:34 2023 +0100

    clk: renesas: cpg-mssr: Remove superfluous check in resume code
    
    [ Upstream commit 1c052043c79af5f70e80e2acd4dd70904ae08666 ]
    
    When the code flow arrives at printing the error message in
    cpg_mssr_resume_noirq(), we know for sure that we are not running on an
    RZ/A Soc, as the code checked for that before.
    
    Fixes: ace342097768e35f ("clk: renesas: cpg-mssr: Fix STBCR suspend/resume handling")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/144a3e66d748c0c17f3524ac8fa6ece5bf5b6f1e.1673425314.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
debugobjects: Recheck debug_objects_enabled before reporting [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Wed Jun 7 19:19:02 2023 +0900

    debugobjects: Recheck debug_objects_enabled before reporting
    
    [ Upstream commit 8b64d420fe2450f82848178506d3e3a0bd195539 ]
    
    syzbot is reporting false a positive ODEBUG message immediately after
    ODEBUG was disabled due to OOM.
    
      [ 1062.309646][T22911] ODEBUG: Out of memory. ODEBUG disabled
      [ 1062.886755][ T5171] ------------[ cut here ]------------
      [ 1062.892770][ T5171] ODEBUG: assert_init not available (active state 0) object: ffffc900056afb20 object type: timer_list hint: process_timeout+0x0/0x40
    
      CPU 0 [ T5171]                CPU 1 [T22911]
      --------------                --------------
      debug_object_assert_init() {
        if (!debug_objects_enabled)
          return;
        db = get_bucket(addr);
                                    lookup_object_or_alloc() {
                                      debug_objects_enabled = 0;
                                      return NULL;
                                    }
                                    debug_objects_oom() {
                                      pr_warn("Out of memory. ODEBUG disabled\n");
                                      // all buckets get emptied here, and
                                    }
        lookup_object_or_alloc(addr, db, descr, false, true) {
          // this bucket is already empty.
          return ERR_PTR(-ENOENT);
        }
        // Emits false positive warning.
        debug_print_object(&o, "assert_init");
      }
    
    Recheck debug_object_enabled in debug_print_object() to avoid that.
    
    Reported-by: syzbot <syzbot+7937ba6a50bdd00fffdf@syzkaller.appspotmail.com>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/492fe2ae-5141-d548-ebd5-62f5fe2e57f7@I-love.SAKURA.ne.jp
    Closes: https://syzkaller.appspot.com/bug?extid=7937ba6a50bdd00fffdf
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
devlink: report devlink_port_type_warn source device [+ + +]
Author: Petr Oros <poros@redhat.com>
Date:   Thu Jun 15 11:54:47 2023 +0200

    devlink: report devlink_port_type_warn source device
    
    [ Upstream commit a52305a81d6bb74b90b400dfa56455d37872fe4b ]
    
    devlink_port_type_warn is scheduled for port devlink and warning
    when the port type is not set. But from this warning it is not easy
    found out which device (driver) has no devlink port set.
    
    [ 3709.975552] Type was not set for devlink port.
    [ 3709.975579] WARNING: CPU: 1 PID: 13092 at net/devlink/leftover.c:6775 devlink_port_type_warn+0x11/0x20
    [ 3709.993967] Modules linked in: openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink bluetooth rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs vhost_net vhost vhost_iotlb tap tun bridge stp llc qrtr intel_rapl_msr intel_rapl_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal mlx5_ib intel_powerclamp coretemp dell_wmi ledtrig_audio sparse_keymap ipmi_ssif kvm_intel ib_uverbs rfkill ib_core video kvm iTCO_wdt acpi_ipmi intel_vsec irqbypass ipmi_si iTCO_vendor_support dcdbas ipmi_devintf mei_me ipmi_msghandler rapl mei intel_cstate isst_if_mmio isst_if_mbox_pci dell_smbios intel_uncore isst_if_common i2c_i801 dell_wmi_descriptor wmi_bmof i2c_smbus intel_pch_thermal pcspkr acpi_power_meter xfs libcrc32c sd_mod sg nvme_tcp mgag200 i2c_algo_bit nvme_fabrics drm_shmem_helper drm_kms_helper nvme syscopyarea ahci sysfillrect sysimgblt nvme_core fb_sys_fops crct10dif_pclmul libahci mlx5_core sfc crc32_pclmul nvme_common drm
    [ 3709.994030]  crc32c_intel mtd t10_pi mlxfw libata tg3 mdio megaraid_sas psample ghash_clmulni_intel pci_hyperv_intf wmi dm_multipath sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse
    [ 3710.108431] CPU: 1 PID: 13092 Comm: kworker/1:1 Kdump: loaded Not tainted 5.14.0-319.el9.x86_64 #1
    [ 3710.108435] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022
    [ 3710.108437] Workqueue: events devlink_port_type_warn
    [ 3710.108440] RIP: 0010:devlink_port_type_warn+0x11/0x20
    [ 3710.108443] Code: 84 76 fe ff ff 48 c7 03 20 0e 1a ad 31 c0 e9 96 fd ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 48 c7 c7 18 24 4e ad e8 ef 71 62 ff <0f> 0b c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f6 87
    [ 3710.108445] RSP: 0018:ff3b6d2e8b3c7e90 EFLAGS: 00010282
    [ 3710.108447] RAX: 0000000000000000 RBX: ff366d6580127080 RCX: 0000000000000027
    [ 3710.108448] RDX: 0000000000000027 RSI: 00000000ffff86de RDI: ff366d753f41f8c8
    [ 3710.108449] RBP: ff366d658ff5a0c0 R08: ff366d753f41f8c0 R09: ff3b6d2e8b3c7e18
    [ 3710.108450] R10: 0000000000000001 R11: 0000000000000023 R12: ff366d753f430600
    [ 3710.108451] R13: ff366d753f436900 R14: 0000000000000000 R15: ff366d753f436905
    [ 3710.108452] FS:  0000000000000000(0000) GS:ff366d753f400000(0000) knlGS:0000000000000000
    [ 3710.108453] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3710.108454] CR2: 00007f1c57bc74e0 CR3: 000000111d26a001 CR4: 0000000000773ee0
    [ 3710.108456] PKRU: 55555554
    [ 3710.108457] Call Trace:
    [ 3710.108458]  <TASK>
    [ 3710.108459]  process_one_work+0x1e2/0x3b0
    [ 3710.108466]  ? rescuer_thread+0x390/0x390
    [ 3710.108468]  worker_thread+0x50/0x3a0
    [ 3710.108471]  ? rescuer_thread+0x390/0x390
    [ 3710.108473]  kthread+0xdd/0x100
    [ 3710.108477]  ? kthread_complete_and_exit+0x20/0x20
    [ 3710.108479]  ret_from_fork+0x1f/0x30
    [ 3710.108485]  </TASK>
    [ 3710.108486] ---[ end trace 1b4b23cd0c65d6a0 ]---
    
    After patch:
    [  402.473064] ice 0000:41:00.0: Type was not set for devlink port.
    [  402.473064] ice 0000:41:00.1: Type was not set for devlink port.
    
    Signed-off-by: Petr Oros <poros@redhat.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Link: https://lore.kernel.org/r/20230615095447.8259-1-poros@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm-crypt: don't modify the data when using authenticated encryption [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:30:10 2024 +0100

    dm-crypt: don't modify the data when using authenticated encryption
    
    commit 50c70240097ce41fe6bce6478b80478281e4d0f7 upstream.
    
    It was said that authenticated encryption could produce invalid tag when
    the data that is being encrypted is modified [1]. So, fix this problem by
    copying the data into the clone bio first and then encrypt them inside the
    clone bio.
    
    This may reduce performance, but it is needed to prevent the user from
    corrupting the device by writing data with O_DIRECT and modifying them at
    the same time.
    
    [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dmaengine: fsl-qdma: increase size of 'irq_name' [+ + +]
Author: Vinod Koul <vkoul@kernel.org>
Date:   Fri Jan 19 18:10:44 2024 +0530

    dmaengine: fsl-qdma: increase size of 'irq_name'
    
    [ Upstream commit 6386f6c995b3ab91c72cfb76e4465553c555a8da ]
    
    We seem to have hit warnings of 'output may be truncated' which is fixed
    by increasing the size of 'irq_name'
    
    drivers/dma/fsl-qdma.c: In function ‘fsl_qdma_irq_init’:
    drivers/dma/fsl-qdma.c:824:46: error: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Werror=format-overflow=]
      824 |                 sprintf(irq_name, "qdma-queue%d", i);
          |                                              ^~
    drivers/dma/fsl-qdma.c:824:35: note: directive argument in the range [-2147483641, 2147483646]
      824 |                 sprintf(irq_name, "qdma-queue%d", i);
          |                                   ^~~~~~~~~~~~~~
    drivers/dma/fsl-qdma.c:824:17: note: ‘sprintf’ output between 12 and 22 bytes into a destination of size 20
      824 |                 sprintf(irq_name, "qdma-queue%d", i);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: shdma: increase size of 'dev_id' [+ + +]
Author: Vinod Koul <vkoul@kernel.org>
Date:   Fri Jan 19 18:10:44 2024 +0530

    dmaengine: shdma: increase size of 'dev_id'
    
    [ Upstream commit 404290240827c3bb5c4e195174a8854eef2f89ac ]
    
    We seem to have hit warnings of 'output may be truncated' which is fixed
    by increasing the size of 'dev_id'
    
    drivers/dma/sh/shdmac.c: In function ‘sh_dmae_probe’:
    drivers/dma/sh/shdmac.c:541:34: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=]
      541 |                          "sh-dmae%d.%d", pdev->id, id);
          |                                  ^~
    In function ‘sh_dmae_chan_probe’,
        inlined from ‘sh_dmae_probe’ at drivers/dma/sh/shdmac.c:845:9:
    drivers/dma/sh/shdmac.c:541:26: note: directive argument in the range [0, 2147483647]
      541 |                          "sh-dmae%d.%d", pdev->id, id);
          |                          ^~~~~~~~~~~~~~
    drivers/dma/sh/shdmac.c:541:26: note: directive argument in the range [0, 19]
    drivers/dma/sh/shdmac.c:540:17: note: ‘snprintf’ output between 11 and 21 bytes into a destination of size 16
      540 |                 snprintf(sh_chan->dev_id, sizeof(sh_chan->dev_id),
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      541 |                          "sh-dmae%d.%d", pdev->id, id);
          |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ti: edma: Add some null pointer checks to the edma_probe [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 18 11:19:29 2024 +0800

    dmaengine: ti: edma: Add some null pointer checks to the edma_probe
    
    [ Upstream commit 6e2276203ac9ff10fc76917ec9813c660f627369 ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20240118031929.192192-1-chentao@kylinos.cn
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Fix memory leak in dm_sw_fini() [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Tue Feb 13 01:50:50 2024 +0100

    drm/amd/display: Fix memory leak in dm_sw_fini()
    
    [ Upstream commit bae67893578d608e35691dcdfa90c4957debf1d3 ]
    
    After destroying dmub_srv, the memory associated with it is
    not freed, causing a memory leak:
    
    unreferenced object 0xffff896302b45800 (size 1024):
      comm "(udev-worker)", pid 222, jiffies 4294894636
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc 6265fd77):
        [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
        [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
        [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu]
        [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
        [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
        [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
        [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90
        [<ffffffff996918a3>] pci_device_probe+0xc3/0x230
        [<ffffffff99805872>] really_probe+0xe2/0x480
        [<ffffffff99805c98>] __driver_probe_device+0x78/0x160
        [<ffffffff99805daf>] driver_probe_device+0x1f/0x90
        [<ffffffff9980601e>] __driver_attach+0xce/0x1c0
        [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
        [<ffffffff99804822>] bus_add_driver+0x112/0x210
        [<ffffffff99807245>] driver_register+0x55/0x100
        [<ffffffff990012d1>] do_one_initcall+0x41/0x300
    
    Fix this by freeing dmub_srv after destroying it.
    
    Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: init iommu after amdkfd device init [+ + +]
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Tue Sep 28 15:42:35 2021 +0800

    drm/amdgpu: init iommu after amdkfd device init
    
    [ Upstream commit 286826d7d976e7646b09149d9bc2899d74ff962b ]
    
    This patch is to fix clinfo failure in Raven/Picasso:
    
    Number of platforms: 1
      Platform Profile: FULL_PROFILE
      Platform Version: OpenCL 2.2 AMD-APP (3364.0)
      Platform Name: AMD Accelerated Parallel Processing
      Platform Vendor: Advanced Micro Devices, Inc.
      Platform Extensions: cl_khr_icd cl_amd_event_callback
    
      Platform Name: AMD Accelerated Parallel Processing Number of devices: 0
    
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: James Zhu <James.Zhu@amd.com>
    Tested-by: James Zhu <James.Zhu@amd.com>
    Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: reset gpu for s3 suspend abort case [+ + +]
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Wed Jan 17 13:39:37 2024 +0800

    drm/amdgpu: reset gpu for s3 suspend abort case
    
    [ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
    
    In the s3 suspend abort case some type of gfx9 power
    rail not turn off from FCH side and this will put the
    GPU in an unknown power status, so let's reset the gpu
    to a known good power state before reinitialize gpu
    device.
    
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: skip to program GFXDEC registers for suspend abort [+ + +]
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Tue Jan 16 19:10:45 2024 +0800

    drm/amdgpu: skip to program GFXDEC registers for suspend abort
    
    [ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
    
    In the suspend abort cases, the gfx power rail doesn't turn off so
    some GFXDEC registers/CSB can't reset to default value and at this
    moment reinitialize GFXDEC/CSB will result in an unexpected error.
    So let skip those program sequence for the suspend abort case.
    
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/dg1: Update DMC_DEBUG3 register [+ + +]
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date:   Fri Feb 11 08:29:33 2022 +0800

    drm/i915/dg1: Update DMC_DEBUG3 register
    
    [ Upstream commit b60668cb4c57a7cc451de781ae49f5e9cc375eaf ]
    
    Current DMC_DEBUG3(_MMIO(0x101090)) address is for TGL,
    it is wrong for DG1. Just like commit 5bcc95ca382e
    ("drm/i915/dg1: Update DMC_DEBUG register"), correct
    this issue for DG1 platform to avoid wrong register
    being read.
    
    BSpec: 49788
    
    v2: fix "not wrong" typo. (Jani)
    
    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220211002933.84240-1-chuansheng.liu@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau/instmem: fix uninitialized_var.cocci warning [+ + +]
Author: Guo Zhengkui <guozhengkui@vivo.com>
Date:   Mon Feb 28 22:23:50 2022 +0800

    drm/nouveau/instmem: fix uninitialized_var.cocci warning
    
    [ Upstream commit 2046e733e125fa58ed997f3d26d43543faf82c95 ]
    
    Fix following coccicheck warning:
    drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c:316:11-12:
    WARNING this kind of initialization is deprecated.
    
    `void *map = map` has the same form of
    uninitialized_var() macro. I remove the redundant assignement. It has
    been tested with gcc (Debian 8.3.0-6) 8.3.0.
    
    The patch which removed uninitialized_var() is:
    https://lore.kernel.org/all/20121028102007.GA7547@gmail.com/
    And there is very few "/* GCC */" comments in the Linux kernel code now.
    
    Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220228142352.18006-1-guozhengkui@vivo.com
    Stable-dep-of: 3b1ae9b71c2a ("octeontx2-af: Consider the action set by PF")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set [+ + +]
Author: Erik Kurzinger <ekurzinger@nvidia.com>
Date:   Fri Jan 19 08:32:06 2024 -0800

    drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set
    
    [ Upstream commit 3c43177ffb54ea5be97505eb8e2690e99ac96bc9 ]
    
    When waiting for a syncobj timeline point whose fence has not yet been
    submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
    drm_syncobj_fence_add_wait and the thread is put to sleep until the
    timeout expires. If the fence is submitted before then,
    drm_syncobj_add_point will wake up the sleeping thread immediately which
    will proceed to wait for the fence to be signaled.
    
    However, if the WAIT_AVAILABLE flag is used instead,
    drm_syncobj_fence_add_wait won't get called, meaning the waiting thread
    will always sleep for the full timeout duration, even if the fence gets
    submitted earlier. If it turns out that the fence *has* been submitted
    by the time it eventually wakes up, it will still indicate to userspace
    that the wait completed successfully (it won't return -ETIME), but it
    will have taken much longer than it should have.
    
    To fix this, we must call drm_syncobj_fence_add_wait if *either* the
    WAIT_FOR_SUBMIT flag or the WAIT_AVAILABLE flag is set. The only
    difference being that with WAIT_FOR_SUBMIT we will also wait for the
    fence to be signaled after it has been submitted while with
    WAIT_AVAILABLE we will return immediately.
    
    IGT test patch: https://lists.freedesktop.org/archives/igt-dev/2024-January/067537.html
    
    v1 -> v2: adjust lockdep_assert_none_held_once condition
    
    (cherry picked from commit 8c44ea81634a4a337df70a32621a5f3791be23df)
    
    Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
    Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240119163208.3723457-1-ekurzinger@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/ttm: Fix an invalid freeing on already freed page in error path [+ + +]
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Date:   Wed Feb 21 08:33:24 2024 +0100

    drm/ttm: Fix an invalid freeing on already freed page in error path
    
    commit 40510a941d27d405a82dc3320823d875f94625df upstream.
    
    If caching mode change fails due to, for example, OOM we
    free the allocated pages in a two-step process. First the pages
    for which the caching change has already succeeded. Secondly
    the pages for which a caching change did not succeed.
    
    However the second step was incorrectly freeing the pages already
    freed in the first step.
    
    Fix.
    
    Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Christian Koenig <christian.koenig@amd.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v6.4+
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellstrom@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

 
efi: Don't add memblocks for soft-reserved memory [+ + +]
Author: Andrew Bresticker <abrestic@rivosinc.com>
Date:   Fri Feb 2 10:07:04 2024 -0800

    efi: Don't add memblocks for soft-reserved memory
    
    [ Upstream commit 0bcff59ef7a652fcdc6d535554b63278c2406c8f ]
    
    Adding memblocks for soft-reserved regions prevents them from later being
    hotplugged in by dax_kmem.
    
    Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

efi: runtime: Fix potential overflow of soft-reserved region size [+ + +]
Author: Andrew Bresticker <abrestic@rivosinc.com>
Date:   Fri Feb 2 10:07:03 2024 -0800

    efi: runtime: Fix potential overflow of soft-reserved region size
    
    [ Upstream commit de1034b38a346ef6be25fe8792f5d1e0684d5ff4 ]
    
    md_size will have been narrowed if we have >= 4GB worth of pages in a
    soft-reserved region.
    
    Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
erofs: fix lz4 inplace decompression [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Wed Dec 6 12:55:34 2023 +0800

    erofs: fix lz4 inplace decompression
    
    commit 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de upstream.
    
    Currently EROFS can map another compressed buffer for inplace
    decompression, that was used to handle the cases that some pages of
    compressed data are actually not in-place I/O.
    
    However, like most simple LZ77 algorithms, LZ4 expects the compressed
    data is arranged at the end of the decompressed buffer and it
    explicitly uses memmove() to handle overlapping:
      __________________________________________________________
     |_ direction of decompression --> ____ |_ compressed data _|
    
    Although EROFS arranges compressed data like this, it typically maps two
    individual virtual buffers so the relative order is uncertain.
    Previously, it was hardly observed since LZ4 only uses memmove() for
    short overlapped literals and x86/arm64 memmove implementations seem to
    completely cover it up and they don't have this issue.  Juhyung reported
    that EROFS data corruption can be found on a new Intel x86 processor.
    After some analysis, it seems that recent x86 processors with the new
    FSRM feature expose this issue with "rep movsb".
    
    Let's strictly use the decompressed buffer for lz4 inplace
    decompression for now.  Later, as an useful improvement, we could try
    to tie up these two buffers together in the correct order.
    
    Reported-and-tested-by: Juhyung Park <qkrwngud825@gmail.com>
    Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR2Q@mail.gmail.com
    Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace")
    Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
    Cc: stable <stable@vger.kernel.org> # 5.4+
    Tested-by: Yifan Zhao <zhaoyifan@sjtu.edu.cn>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
exfat: support dynamic allocate bh for exfat_entry_set_cache [+ + +]
Author: Yuezhang Mo <Yuezhang.Mo@sony.com>
Date:   Wed Nov 9 13:50:22 2022 +0800

    exfat: support dynamic allocate bh for exfat_entry_set_cache
    
    [ Upstream commit a3ff29a95fde16906304455aa8c0bd84eb770258 ]
    
    In special cases, a file or a directory may occupied more than 19
    directory entries, pre-allocating 3 bh is not enough. Such as
      - Support vendor secondary directory entry in the future.
      - Since file directory entry is damaged, the SecondaryCount
        field is bigger than 18.
    
    So this commit supports dynamic allocation of bh.
    
    Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
    Reviewed-by: Andy Wu <Andy.Wu@sony.com>
    Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com>
    Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:39 2024 +0800

    ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
    
    [ Upstream commit 832698373a25950942c04a512daa652c18a9b513 ]
    
    Places the logic for checking if the group's block bitmap is corrupt under
    the protection of the group lock to avoid allocating blocks from the group
    with a corrupted block bitmap.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-8-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:38 2024 +0800

    ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
    
    [ Upstream commit 4530b3660d396a646aad91a787b6ab37cf604b53 ]
    
    Determine if the group block bitmap is corrupted before using ac_b_ex in
    ext4_mb_try_best_found() to avoid allocating blocks from a group with a
    corrupted block bitmap in the following concurrency and making the
    situation worse.
    
    ext4_mb_regular_allocator
      ext4_lock_group(sb, group)
      ext4_mb_good_group
       // check if the group bbitmap is corrupted
      ext4_mb_complex_scan_group
       // Scan group gets ac_b_ex but doesn't use it
      ext4_unlock_group(sb, group)
                               ext4_mark_group_bitmap_corrupted(group)
                               // The block bitmap was corrupted during
                               // the group unlock gap.
      ext4_mb_try_best_found
        ext4_lock_group(ac->ac_sb, group)
        ext4_mb_use_best_found
          mb_mark_used
          // Allocating blocks in block bitmap corrupted group
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-7-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:36 2024 +0800

    ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks()
    
    commit 2331fd4a49864e1571b4f50aa3aa1536ed6220d0 upstream.
    
    After updating bb_free in mb_free_blocks, it is possible to return without
    updating bb_fragments because the block being freed is found to have
    already been freed, which leads to inconsistency between bb_free and
    bb_fragments.
    
    Since the group may be unlocked in ext4_grp_locked_error(), this can lead
    to problems such as dividing by zero when calculating the average fragment
    length. Hence move the update of bb_free to after the block double-free
    check guarantees that the corresponding statistics are updated only after
    the core block bitmap is modified.
    
    Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit")
    CC:  <stable@vger.kernel.org> # 3.10
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-5-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:37 2024 +0800

    ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
    
    [ Upstream commit 993bf0f4c393b3667830918f9247438a8f6fdb5b ]
    
    Determine if bb_fragments is 0 instead of determining bb_free to eliminate
    the risk of dividing by zero when the block bitmap is corrupted.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-6-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: correct the hole length returned by ext4_map_blocks() [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat Jan 27 09:58:02 2024 +0800

    ext4: correct the hole length returned by ext4_map_blocks()
    
    [ Upstream commit 6430dea07e85958fa87d0276c0c4388dd51e630b ]
    
    In ext4_map_blocks(), if we can't find a range of mapping in the
    extents cache, we are calling ext4_ext_map_blocks() to search the real
    path and ext4_ext_determine_hole() to determine the hole range. But if
    the querying range was partially or completely overlaped by a delalloc
    extent, we can't find it in the real extent path, so the returned hole
    length could be incorrect.
    
    Fortunately, ext4_ext_put_gap_in_cache() have already handle delalloc
    extent, but it searches start from the expanded hole_start, doesn't
    start from the querying range, so the delalloc extent found could not be
    the one that overlaped the querying range, plus, it also didn't adjust
    the hole length. Let's just remove ext4_ext_put_gap_in_cache(), handle
    delalloc and insert adjusted hole extent in ext4_ext_determine_hole().
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Suggested-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240127015825.1608160-4-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: regenerate buddy after block freeing failed if under fc replay [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:35 2024 +0800

    ext4: regenerate buddy after block freeing failed if under fc replay
    
    commit c9b528c35795b711331ed36dc3dbee90d5812d4e upstream.
    
    This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
    mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
    code in mb_free_blocks(), fast commit replay can end up marking as free
    blocks that are already marked as such. This causes corruption of the
    buddy bitmap so we need to regenerate it in that case.
    
    Reported-by: Jan Kara <jack@suse.cz>
    Fixes: 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
f2fs: don't set GC_FAILURE_PIN for background GC [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun Mar 20 23:11:18 2022 +0800

    f2fs: don't set GC_FAILURE_PIN for background GC
    
    [ Upstream commit 642c0969916eaa4878cb74f36752108e590b0389 ]
    
    So that it can reduce the possibility that file be unpinned forcely by
    foreground GC due to .i_gc_failures[GC_FAILURE_PIN] exceeds threshold.
    
    Signed-off-by: Chao Yu <chao.yu@oppo.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: write checkpoint during FG_GC [+ + +]
Author: Byungki Lee <dominicus79@gmail.com>
Date:   Fri Apr 29 13:29:53 2022 -0700

    f2fs: write checkpoint during FG_GC
    
    [ Upstream commit a9163b947ae8f7af7cb8d63606cd87b9facbfe74 ]
    
    If there's not enough free sections each of which consistis of large segments,
    we can hit no free section for upcoming section allocation. Let's reclaim some
    prefree segments by writing checkpoints.
    
    Signed-off-by: Byungki Lee <dominicus79@gmail.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: savage: Error out if pixclock equals zero [+ + +]
Author: Fullway Wang <fullwaywang@outlook.com>
Date:   Thu Jan 18 11:49:40 2024 +0800

    fbdev: savage: Error out if pixclock equals zero
    
    [ Upstream commit 04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 ]
    
    The userspace program could pass any values to the driver through
    ioctl() interface. If the driver doesn't check the value of pixclock,
    it may cause divide-by-zero error.
    
    Although pixclock is checked in savagefb_decode_var(), but it is not
    checked properly in savagefb_probe(). Fix this by checking whether
    pixclock is zero in the function savagefb_check_var() before
    info->var.pixclock is used as the divisor.
    
    This is similar to CVE-2022-3061 in i740fb which was fixed by
    commit 15cf0b8.
    
    Signed-off-by: Fullway Wang <fullwaywang@outlook.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: sis: Error out if pixclock equals zero [+ + +]
Author: Fullway Wang <fullwaywang@outlook.com>
Date:   Thu Jan 18 14:24:43 2024 +0800

    fbdev: sis: Error out if pixclock equals zero
    
    [ Upstream commit e421946be7d9bf545147bea8419ef8239cb7ca52 ]
    
    The userspace program could pass any values to the driver through
    ioctl() interface. If the driver doesn't check the value of pixclock,
    it may cause divide-by-zero error.
    
    In sisfb_check_var(), var->pixclock is used as a divisor to caculate
    drate before it is checked against zero. Fix this by checking it
    at the beginning.
    
    This is similar to CVE-2022-3061 in i740fb which was fixed by
    commit 15cf0b8.
    
    Signed-off-by: Fullway Wang <fullwaywang@outlook.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firewire: core: send bus reset promptly on gap count error [+ + +]
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Wed Feb 7 08:01:17 2024 +0900

    firewire: core: send bus reset promptly on gap count error
    
    [ Upstream commit 7ed4380009e96d9e9c605e12822e987b35b05648 ]
    
    If we are bus manager and the bus has inconsistent gap counts, send a
    bus reset immediately instead of trying to read the root node's config
    ROM first. Otherwise, we could spend a lot of time trying to read the
    config ROM but never succeeding.
    
    This eliminates a 50+ second delay before the FireWire bus is usable after
    a newly connected device is powered on in certain circumstances.
    
    The delay occurs if a gap count inconsistency occurs, we are not the root
    node, and we become bus manager. One scenario that causes this is with a TI
    XIO2213B OHCI, the first time a Sony DSR-25 is powered on after being
    connected to the FireWire cable. In this configuration, the Linux box will
    not receive the initial PHY configuration packet sent by the DSR-25 as IRM,
    resulting in the DSR-25 having a gap count of 44 while the Linux box has a
    gap count of 63.
    
    FireWire devices have a gap count parameter, which is set to 63 on power-up
    and can be changed with a PHY configuration packet. This determines the
    duration of the subaction and arbitration gaps. For reliable communication,
    all nodes on a FireWire bus must have the same gap count.
    
    A node may have zero or more of the following roles: root node, bus manager
    (BM), isochronous resource manager (IRM), and cycle master. Unless a root
    node was forced with a PHY configuration packet, any node might become root
    node after a bus reset. Only the root node can become cycle master. If the
    root node is not cycle master capable, the BM or IRM should force a change
    of root node.
    
    After a bus reset, each node sends a self-ID packet, which contains its
    current gap count. A single bus reset does not change the gap count, but
    two bus resets in a row will set the gap count to 63. Because a consistent
    gap count is required for reliable communication, IEEE 1394a-2000 requires
    that the bus manager generate a bus reset if it detects that the gap count
    is inconsistent.
    
    When the gap count is inconsistent, build_tree() will notice this after the
    self identification process. It will set card->gap_count to the invalid
    value 0. If we become bus master, this will force bm_work() to send a bus
    reset when it performs gap count optimization.
    
    After a bus reset, there is no bus manager. We will almost always try to
    become bus manager. Once we become bus manager, we will first determine
    whether the root node is cycle master capable. Then, we will determine if
    the gap count should be changed. If either the root node or the gap count
    should be changed, we will generate a bus reset.
    
    To determine if the root node is cycle master capable, we read its
    configuration ROM. bm_work() will wait until we have finished trying to
    read the configuration ROM.
    
    However, an inconsistent gap count can make this take a long time.
    read_config_rom() will read the first few quadlets from the config ROM. Due
    to the gap count inconsistency, eventually one of the reads will time out.
    When read_config_rom() fails, fw_device_init() calls it again until
    MAX_RETRIES is reached. This takes 50+ seconds.
    
    Once we give up trying to read the configuration ROM, bm_work() will wake
    up, assume that the root node is not cycle master capable, and do a bus
    reset. Hopefully, this will resolve the gap count inconsistency.
    
    This change makes bm_work() check for an inconsistent gap count before
    waiting for the root node's configuration ROM. If the gap count is
    inconsistent, bm_work() will immediately do a bus reset. This eliminates
    the 50+ second delay and rapidly brings the bus to a working state.
    
    I considered that if the gap count is inconsistent, a PHY configuration
    packet might not be successful, so it could be desirable to skip the PHY
    configuration packet before the bus reset in this case. However, IEEE
    1394a-2000 and IEEE 1394-2008 say that the bus manager may transmit a PHY
    configuration packet before a bus reset when correcting a gap count error.
    Since the standard endorses this, I decided it's safe to retain the PHY
    configuration packet transmission.
    
    Normally, after a topology change, we will reset the bus a maximum of 5
    times to change the root node and perform gap count optimization. However,
    if there is a gap count inconsistency, we must always generate a bus reset.
    Otherwise the gap count inconsistency will persist and communication will
    be unreliable. For that reason, if there is a gap count inconstency, we
    generate a bus reset even if we already reached the 5 reset limit.
    
    Signed-off-by: Adam Goldman <adamg@pobox.com>
    Reference: https://sourceforge.net/p/linux1394/mailman/message/58727806/
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Feb 15 12:47:38 2024 -0800

    fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
    
    commit b820de741ae48ccf50dd95e297889c286ff4f760 upstream.
    
    If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
    following kernel warning appears:
    
    WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
    Call trace:
     kiocb_set_cancel_fn+0x9c/0xa8
     ffs_epfile_read_iter+0x144/0x1d0
     io_read+0x19c/0x498
     io_issue_sqe+0x118/0x27c
     io_submit_sqes+0x25c/0x5fc
     __arm64_sys_io_uring_enter+0x104/0xab0
     invoke_syscall+0x58/0x11c
     el0_svc_common+0xb4/0xf4
     do_el0_svc+0x2c/0xb0
     el0_svc+0x2c/0xa4
     el0t_64_sync_handler+0x68/0xb4
     el0t_64_sync+0x1a4/0x1a8
    
    Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
    submitted by libaio.
    
    Suggested-by: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Avi Kivity <avi@scylladb.com>
    Cc: Sandeep Dhavale <dhavale@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240215204739.2677806-2-bvanassche@acm.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Nov 28 11:09:34 2023 +0300

    fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()
    
    [ Upstream commit aaab47f204aaf47838241d57bf8662c8840de60a ]
    
    It is preferable to exit through the out: label because
    internal debugging functions are located there.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Correct function is_rst_area_valid [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:13:59 2024 +0300

    fs/ntfs3: Correct function is_rst_area_valid
    
    [ Upstream commit 1b7dd28e14c4728ae1a815605ca33ffb4ce1b309 ]
    
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Correct hard links updating when dealing with DOS names [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:26:31 2023 +0300

    fs/ntfs3: Correct hard links updating when dealing with DOS names
    
    [ Upstream commit 1918c10e137eae266b8eb0ab1cc14421dcb0e3e2 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Disable ATTR_LIST_ENTRY size check [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu Dec 21 13:59:43 2023 +0300

    fs/ntfs3: Disable ATTR_LIST_ENTRY size check
    
    [ Upstream commit 4cdfb6e7bc9c80142d33bf1d4653a73fa678ba56 ]
    
    The use of sizeof(struct ATTR_LIST_ENTRY) has been replaced with le_size(0)
    due to alignment peculiarities on different platforms.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312071005.g6YrbaIe-lkp@intel.com/
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Fix detected field-spanning write (size 8) of single field "le->name" [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:47:30 2023 +0300

    fs/ntfs3: Fix detected field-spanning write (size 8) of single field "le->name"
    
    [ Upstream commit d155617006ebc172a80d3eb013c4b867f9a8ada4 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Fix oob in ntfs_listxattr [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Sat Dec 30 17:00:03 2023 +0800

    fs/ntfs3: Fix oob in ntfs_listxattr
    
    [ Upstream commit 731ab1f9828800df871c5a7ab9ffe965317d3f15 ]
    
    The length of name cannot exceed the space occupied by ea.
    
    Reported-and-tested-by: syzbot+65e940cfb8f99a97aca7@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Improve ntfs_dir_count [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:24:33 2023 +0300

    fs/ntfs3: Improve ntfs_dir_count
    
    [ Upstream commit 6a799c928b78b14999b7705c4cca0f88e297fe96 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Modified fix directory element type detection [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:17:07 2023 +0300

    fs/ntfs3: Modified fix directory element type detection
    
    [ Upstream commit 22457c047ed971f2f2e33be593ddfabd9639a409 ]
    
    Unfortunately reparse attribute is used for many purposes (several dozens).
    It is not possible here to know is this name symlink or not.
    To get exactly the type of name we should to open inode (read mft).
    getattr for opened file (fstat) correctly returns symlink.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Prevent generic message "attempt to access beyond end of device" [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:03:21 2024 +0300

    fs/ntfs3: Prevent generic message "attempt to access beyond end of device"
    
    [ Upstream commit 5ca87d01eba7bdfe9536a157ca33c1455bb8d16c ]
    
    It used in test environment.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Print warning while fixing hard links count [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:34:24 2023 +0300

    fs/ntfs3: Print warning while fixing hard links count
    
    [ Upstream commit 85ba2a75faee759809a7e43b4c103ac59bac1026 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Update inode->i_size after success write into compressed file [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Mon Jan 29 10:30:09 2024 +0300

    fs/ntfs3: Update inode->i_size after success write into compressed file
    
    [ Upstream commit d68968440b1a75dee05cfac7f368f1aa139e1911 ]
    
    Reported-by: Giovanni Santini <giovannisantini93@yahoo.it>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: use non-movable memory for ntfs3 MFT buffer cache [+ + +]
Author: Ism Hong <ism.hong@gmail.com>
Date:   Tue Dec 26 16:51:41 2023 +0800

    fs/ntfs3: use non-movable memory for ntfs3 MFT buffer cache
    
    [ Upstream commit d6d33f03baa43d763fe094ca926eeae7d3421d07 ]
    
    Since the buffer cache for ntfs3 metadata is not released until the file
    system is unmounted, allocating from the movable zone may result in cma
    allocation failures. This is due to the page still being used by ntfs3,
    leading to migration failures.
    
    To address this, this commit use sb_bread_umovable() instead of
    sb_bread(). This change prevents allocation from the movable zone,
    ensuring compatibility with scenarios where the buffer head is not
    released until unmount. This patch is inspired by commit
    a8ac900b8163("ext4: use non-movable memory for the ext4 superblock").
    
    The issue is found when playing video files stored in NTFS on the
    Android TV platform. During this process, the media parser reads the
    video file, causing ntfs3 to allocate buffer cache from the CMA area.
    Subsequently, the hardware decoder attempts to allocate memory from the
    same CMA area. However, the page is still in use by ntfs3, resulting in
    a migrate failure in alloc_contig_range().
    
    The pinned page and allocating stacktrace reported by page owner shows
    below:
    
    page:ffffffff00b68880 refcount:3 mapcount:0 mapping:ffffff80046aa828
            index:0xc0040 pfn:0x20fa4
        aops:def_blk_aops ino:0
        flags: 0x2020(active|private)
        page dumped because: migration failure
        page last allocated via order 0, migratetype Movable,
            gfp_mask 0x108c48
            (GFP_NOFS|__GFP_NOFAIL|__GFP_HARDWALL|__GFP_MOVABLE),
        page_owner tracks the page as allocated
         prep_new_page
         get_page_from_freelist
         __alloc_pages_nodemask
         pagecache_get_page
         __getblk_gfp
         __bread_gfp
         ntfs_read_run_nb
         ntfs_read_bh
         mi_read
         ntfs_iget5
         dir_search_u
         ntfs_lookup
         __lookup_slow
         lookup_slow
         walk_component
         path_lookupat
    
    Signed-off-by: Ism Hong <ism.hong@gmail.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp() [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Wed Feb 14 19:27:33 2024 +0300

    gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
    
    commit 136cfaca22567a03bbb3bf53a43d8cb5748b80ec upstream.
    
    The gtp_net_ops pernet operations structure for the subsystem must be
    registered before registering the generic netlink family.
    
    Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
    
    general protection fault, probably for non-canonical address
    0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
    RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
    Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
          df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
          3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
    RSP: 0018:ffff888014107220 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
    FS:  00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? show_regs+0x90/0xa0
     ? die_addr+0x50/0xd0
     ? exc_general_protection+0x148/0x220
     ? asm_exc_general_protection+0x22/0x30
     ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
     ? __alloc_skb+0x1dd/0x350
     ? __pfx___alloc_skb+0x10/0x10
     genl_dumpit+0x11d/0x230
     netlink_dump+0x5b9/0xce0
     ? lockdep_hardirqs_on_prepare+0x253/0x430
     ? __pfx_netlink_dump+0x10/0x10
     ? kasan_save_track+0x10/0x40
     ? __kasan_kmalloc+0x9b/0xa0
     ? genl_start+0x675/0x970
     __netlink_dump_start+0x6fc/0x9f0
     genl_family_rcv_msg_dumpit+0x1bb/0x2d0
     ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
     ? genl_op_from_small+0x2a/0x440
     ? cap_capable+0x1d0/0x240
     ? __pfx_genl_start+0x10/0x10
     ? __pfx_genl_dumpit+0x10/0x10
     ? __pfx_genl_done+0x10/0x10
     ? security_capable+0x9d/0xe0
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
    Link: https://lore.kernel.org/r/20240214162733.34214-1-kovalev@altlinux.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hwmon: (coretemp) Enlarge per package core count limit [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Feb 2 17:21:36 2024 +0800

    hwmon: (coretemp) Enlarge per package core count limit
    
    [ Upstream commit 34cf8c657cf0365791cdc658ddbca9cc907726ce ]
    
    Currently, coretemp driver supports only 128 cores per package.
    This loses some core temperature information on systems that have more
    than 128 cores per package.
     [   58.685033] coretemp coretemp.0: Adding Core 128 failed
     [   58.692009] coretemp coretemp.0: Adding Core 129 failed
     ...
    
    Enlarge the limitation to 512 because there are platforms with more than
    256 cores per package.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20240202092144.71180-4-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: imx: Add timer for handling the stop condition [+ + +]
Author: Corey Minyard <minyard@acm.org>
Date:   Fri Nov 12 07:39:55 2021 -0600

    i2c: imx: Add timer for handling the stop condition
    
    [ Upstream commit f89bf95632b41695402996d96476c44c641d23d7 ]
    
    Most IMX I2C interfaces don't generate an interrupt on a stop condition,
    so it won't generate a timely stop event on a slave mode transfer.
    Some users, like IPMB, need a timely stop event to work properly.
    
    So, add a timer and add the proper handling to generate a stop event in
    slave mode if the interface goes idle.
    
    Signed-off-by: Corey Minyard <minyard@acm.org>
    Tested-by: Andrew Manley <andrew.manley@sealingtech.com>
    Reviewed-by: Andrew Manley <andrew.manley@sealingtech.com>
    Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Stable-dep-of: 87aec499368d ("i2c: imx: when being a target, mark the last read as processed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: imx: when being a target, mark the last read as processed [+ + +]
Author: Corey Minyard <minyard@acm.org>
Date:   Wed Feb 21 20:27:13 2024 +0100

    i2c: imx: when being a target, mark the last read as processed
    
    [ Upstream commit 87aec499368d488c20292952d6d4be7cb9e49c5e ]
    
    When being a target, NAK from the controller means that all bytes have
    been transferred. So, the last byte needs also to be marked as
    'processed'. Otherwise index registers of backends may not increase.
    
    Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
    Signed-off-by: Corey Minyard <minyard@acm.org>
    Tested-by: Andrew Manley <andrew.manley@sealingtech.com>
    Reviewed-by: Andrew Manley <andrew.manley@sealingtech.com>
    Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    [wsa: fixed comment and commit message to properly describe the case]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/hfi1: Fix a memleak in init_credit_return [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Fri Jan 12 16:55:23 2024 +0800

    IB/hfi1: Fix a memleak in init_credit_return
    
    [ Upstream commit 809aa64ebff51eb170ee31a95f83b2d21efa32e2 ]
    
    When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
    init_credit_return should deallocate dd->cr_base and
    dd->cr_base[i] that allocated before. Or those resources
    would be never freed and a memleak is triggered.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Link: https://lore.kernel.org/r/20240112085523.3731720-1-alexious@zju.edu.cn
    Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Fix sdma.h tx->num_descs off-by-one error [+ + +]
Author: Daniel Vacek <neelx@redhat.com>
Date:   Thu Feb 1 09:10:08 2024 +0100

    IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
    
    commit e6f57c6881916df39db7d95981a8ad2b9c3458d6 upstream.
    
    Unfortunately the commit `fd8958efe877` introduced another error
    causing the `descs` array to overflow. This reults in further crashes
    easily reproducible by `sendmsg` system call.
    
    [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
    [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
    --
    [ 1080.974535] Call Trace:
    [ 1080.976990]  <TASK>
    [ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]
    [ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]
    [ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]
    [ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]
    [ 1081.046978]  dev_hard_start_xmit+0xc4/0x210
    --
    [ 1081.148347]  __sys_sendmsg+0x59/0xa0
    
    crash> ipoib_txreq 0xffff9cfeba229f00
    struct ipoib_txreq {
      txreq = {
        list = {
          next = 0xffff9cfeba229f00,
          prev = 0xffff9cfeba229f00
        },
        descp = 0xffff9cfeba229f40,
        coalesce_buf = 0x0,
        wait = 0xffff9cfea4e69a48,
        complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>,
        packet_len = 0x46d,
        tlen = 0x0,
        num_desc = 0x0,
        desc_limit = 0x6,
        next_descq_idx = 0x45c,
        coalesce_idx = 0x0,
        flags = 0x0,
        descs = {{
            qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)
          }, {
            qw = {  0x3800014231b108, 0x4}
          }, {
            qw = { 0x310000e4ee0fcf0, 0x8}
          }, {
            qw = {  0x3000012e9f8000, 0x8}
          }, {
            qw = {  0x59000dfb9d0000, 0x8}
          }, {
            qw = {  0x78000e02e40000, 0x8}
          }}
      },
      sdma_hdr =  0x400300015528b000,  <<< invalid pointer in the tx request structure
      sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)
      complete = 0x0,
      priv = 0x0,
      txq = 0xffff9cfea4e69880,
      skb = 0xffff9d099809f400
    }
    
    If an SDMA send consists of exactly 6 descriptors and requires dword
    padding (in the 7th descriptor), the sdma_txreq descriptor array is not
    properly expanded and the packet will overflow into the container
    structure. This results in a panic when the send completion runs. The
    exact panic varies depending on what elements of the container structure
    get corrupted. The fix is to use the correct expression in
    _pad_sdma_tx_descs() to test the need to expand the descriptor array.
    
    With this patch the crashes are no longer reproducible and the machine is
    stable.
    
    Fixes: fd8958efe877 ("IB/hfi1: Fix sdma.h tx->num_descs off-by-one errors")
    Cc: stable@vger.kernel.org
    Reported-by: Mats Kronberg <kronberg@nsc.liu.se>
    Tested-by: Mats Kronberg <kronberg@nsc.liu.se>
    Signed-off-by: Daniel Vacek <neelx@redhat.com>
    Link: https://lore.kernel.org/r/20240201081009.1109442-1-neelx@redhat.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
igb: Fix igb_down hung on surprise removal [+ + +]
Author: Ying Hsu <yinghsu@chromium.org>
Date:   Tue Jun 20 10:47:32 2023 -0700

    igb: Fix igb_down hung on surprise removal
    
    [ Upstream commit 004d25060c78fc31f66da0fa439c544dda1ac9d5 ]
    
    In a setup where a Thunderbolt hub connects to Ethernet and a display
    through USB Type-C, users may experience a hung task timeout when they
    remove the cable between the PC and the Thunderbolt hub.
    This is because the igb_down function is called multiple times when
    the Thunderbolt hub is unplugged. For example, the igb_io_error_detected
    triggers the first call, and the igb_remove triggers the second call.
    The second call to igb_down will block at napi_synchronize.
    Here's the call trace:
        __schedule+0x3b0/0xddb
        ? __mod_timer+0x164/0x5d3
        schedule+0x44/0xa8
        schedule_timeout+0xb2/0x2a4
        ? run_local_timers+0x4e/0x4e
        msleep+0x31/0x38
        igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]
        __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]
        igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]
        __dev_close_many+0x95/0xec
        dev_close_many+0x6e/0x103
        unregister_netdevice_many+0x105/0x5b1
        unregister_netdevice_queue+0xc2/0x10d
        unregister_netdev+0x1c/0x23
        igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]
        pci_device_remove+0x3f/0x9c
        device_release_driver_internal+0xfe/0x1b4
        pci_stop_bus_device+0x5b/0x7f
        pci_stop_bus_device+0x30/0x7f
        pci_stop_bus_device+0x30/0x7f
        pci_stop_and_remove_bus_device+0x12/0x19
        pciehp_unconfigure_device+0x76/0xe9
        pciehp_disable_slot+0x6e/0x131
        pciehp_handle_presence_or_link_change+0x7a/0x3f7
        pciehp_ist+0xbe/0x194
        irq_thread_fn+0x22/0x4d
        ? irq_thread+0x1fd/0x1fd
        irq_thread+0x17b/0x1fd
        ? irq_forced_thread_fn+0x5f/0x5f
        kthread+0x142/0x153
        ? __irq_get_irqchip_state+0x46/0x46
        ? kthread_associate_blkcg+0x71/0x71
        ret_from_fork+0x1f/0x30
    
    In this case, igb_io_error_detected detaches the network interface
    and requests a PCIE slot reset, however, the PCIE reset callback is
    not being invoked and thus the Ethernet connection breaks down.
    As the PCIE error in this case is a non-fatal one, requesting a
    slot reset can be avoided.
    This patch fixes the task hung issue and preserves Ethernet
    connection by ignoring non-fatal PCIE errors.
    
    Signed-off-by: Ying Hsu <yinghsu@chromium.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230620174732.4145155-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: ads7846 - always set last command to PWRDOWN [+ + +]
Author: Luca Ellero <l.ellero@asem.it>
Date:   Thu Jan 26 11:52:26 2023 +0100

    Input: ads7846 - always set last command to PWRDOWN
    
    [ Upstream commit 13f82ca3878db8284a70ef9711d7f710a31eb562 ]
    
    Controllers that report pressure (e.g. ADS7846) use 5 commands and the
    correct sequence is READ_X, READ_Y, READ_Z1, READ_Z2, PWRDOWN.
    
    Controllers that don't report pressure (e.g. ADS7845/ADS7843) use only 3
    commands and the correct sequence should be READ_X, READ_Y, PWRDOWN. But
    the sequence sent was incorrect: READ_X, READ_Y, READ_Z1.
    
    Fix this by setting the third (and last) command to PWRDOWN.
    
    Fixes: ffa458c1bd9b ("spi: ads7846 driver")
    Signed-off-by: Luca Ellero <l.ellero@asem.it>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230126105227.47648-3-l.ellero@asem.it
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: ads7846 - don't check penirq immediately for 7845 [+ + +]
Author: Luca Ellero <l.ellero@asem.it>
Date:   Thu Jan 26 11:52:27 2023 +0100

    Input: ads7846 - don't check penirq immediately for 7845
    
    [ Upstream commit fa9f4275b20ec7b2a8fb05c66362d10b36f9efec ]
    
    To discard false readings, one should use "ti,penirq-recheck-delay-usecs".
    Checking get_pendown_state() at the beginning, most of the time fails
    causing malfunctioning.
    
    Fixes: ffa458c1bd9b ("spi: ads7846 driver")
    Signed-off-by: Luca Ellero <l.ellero@asem.it>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230126105227.47648-4-l.ellero@asem.it
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: ads7846 - don't report pressure for ads7845 [+ + +]
Author: Luca Ellero <l.ellero@asem.it>
Date:   Thu Jan 26 11:52:25 2023 +0100

    Input: ads7846 - don't report pressure for ads7845
    
    [ Upstream commit d50584d783313c8b05b84d0b07a2142f1bde46dd ]
    
    ADS7845 doesn't support pressure.
    Avoid the following error reported by libinput-list-devices:
    "ADS7845 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE".
    
    Fixes: ffa458c1bd9b ("spi: ads7846 driver")
    Signed-off-by: Luca Ellero <l.ellero@asem.it>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230126105227.47648-2-l.ellero@asem.it
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: i8042 - add Fujitsu Lifebook U728 to i8042 quirk table [+ + +]
Author: Szilard Fabian <szfabian@bluemarch.art>
Date:   Fri Feb 2 10:28:59 2024 -0800

    Input: i8042 - add Fujitsu Lifebook U728 to i8042 quirk table
    
    [ Upstream commit 4255447ad34c5c3785fcdcf76cfa0271d6e5ed39 ]
    
    Another Fujitsu-related patch.
    
    In the initial boot stage the integrated keyboard of Fujitsu Lifebook U728
    refuses to work and it's not possible to type for example a dm-crypt
    passphrase without the help of an external keyboard.
    
    i8042.nomux kernel parameter resolves this issue but using that a PS/2
    mouse is detected. This input device is unused even when the i2c-hid-acpi
    kernel module is blacklisted making the integrated ELAN touchpad
    (04F3:3092) not working at all.
    
    So this notebook uses a hid-over-i2c touchpad which is managed by the
    i2c_designware input driver. Since you can't find a PS/2 mouse port on this
    computer and you can't connect a PS/2 mouse to it even with an official
    port replicator I think it's safe to not use the PS/2 mouse port at all.
    
    Signed-off-by: Szilard Fabian <szfabian@bluemarch.art>
    Link: https://lore.kernel.org/r/20240103014717.127307-2-szfabian@bluemarch.art
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iqs269a - configure device with a single block write [+ + +]
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Tue Jan 3 11:59:12 2023 -0600

    Input: iqs269a - configure device with a single block write
    
    [ Upstream commit 3689abfc4e369a643d758a02fb9ad0b2403d6d6d ]
    
    Unless it is being done as part of servicing a soft reset interrupt,
    configuring channels on-the-fly (as is the case when writing to the
    ati_trigger attribute) may cause GPIO3 (which reflects the state of
    touch for a selected channel) to be inadvertently asserted.
    
    To solve this problem, follow the vendor's recommendation and write
    all channel configuration as well as the REDO_ATI register field as
    part of a single block write. This ensures the device has been told
    to re-calibrate itself following an I2C stop condition, after which
    sensing resumes and GPIO3 may be asserted.
    
    Fixes: 04e49867fad1 ("Input: add support for Azoteq IQS269A")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Link: https://lore.kernel.org/r/Y7Rs8GyV7g0nF5Yy@nixie71
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iqs269a - do not poll during ATI [+ + +]
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Tue Jan 3 11:59:35 2023 -0600

    Input: iqs269a - do not poll during ATI
    
    [ Upstream commit b08134eb254db56e9ce8170d9b82f0d7a616b6f8 ]
    
    After initial start-up, the driver triggers ATI (calibration) with
    the newly loaded register configuration in place. Next, the driver
    polls a register field to ensure ATI completed in a timely fashion
    and that the device is ready to sense.
    
    However, communicating with the device over I2C while ATI is under-
    way may induce noise in the device and cause ATI to fail. As such,
    the vendor recommends not to poll the device during ATI.
    
    To solve this problem, let the device naturally signal to the host
    that ATI is complete by way of an interrupt. A completion prevents
    the device from successfully probing until this happens.
    
    As an added benefit, initial switch states are now reported in the
    interrupt handler at the same time ATI status is checked. As such,
    duplicate code that reports initial switch states has been removed
    from iqs269_input_init().
    
    The former logic that scaled ATI timeout and filter settling delay
    is not carried forward with the new implementation, as it produces
    overly conservative delays at the lower clock rate.
    
    Rather, a single timeout that covers both clock rates is used. The
    filter settling delay does not happen to be necessary and has been
    removed as well.
    
    Fixes: 04e49867fad1 ("Input: add support for Azoteq IQS269A")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Link: https://lore.kernel.org/r/Y7RtB2T7AF9rYMjK@nixie71
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iqs269a - do not poll during suspend or resume [+ + +]
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Tue Jan 3 11:59:21 2023 -0600

    Input: iqs269a - do not poll during suspend or resume
    
    [ Upstream commit 18ab69c8ca5678324efbeed874b707ce7b2feae1 ]
    
    Polling the device while it transitions from automatic to manual
    power mode switching may keep the device from actually finishing
    the transition. The process appears to time out depending on the
    polling rate and the device's core clock frequency.
    
    This is ultimately unnecessary in the first place; instead it is
    sufficient to write the desired mode during initialization, then
    disable automatic switching at suspend. This eliminates the need
    to ensure the device is prepared for a manual change and removes
    the 'suspend_mode' variable.
    
    Similarly, polling the device while it transitions from one mode
    to another under manual control may time out as well. This added
    step does not appear to be necessary either, so drop it.
    
    Fixes: 04e49867fad1 ("Input: add support for Azoteq IQS269A")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Link: https://lore.kernel.org/r/Y7Rs+eEXlRw4Vq57@nixie71
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iqs269a - drop unused device node references [+ + +]
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Tue Jan 3 11:58:31 2023 -0600

    Input: iqs269a - drop unused device node references
    
    [ Upstream commit 59bc9cb3b80abaa42643abede0d5db8477901d9c ]
    
    Each call to device/fwnode_get_named_child_node() must be matched
    with a call to fwnode_handle_put() once the corresponding node is
    no longer in use. This ensures a reference count remains balanced
    in the case of dynamic device tree support.
    
    Currently, the driver does not call fwnode_handle_put() on nested
    event nodes. This patch solves this problem by adding the missing
    instances of fwnode_handle_put().
    
    As part of this change, the logic which parses each channel's key
    code is gently refactored in order to reduce the number of places
    from which fwnode_handle_put() is called.
    
    Fixes: 04e49867fad1 ("Input: add support for Azoteq IQS269A")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/Y7Rsx68k/gvDVXAt@nixie71
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iqs269a - increase interrupt handler return delay [+ + +]
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Tue Jan 3 11:58:59 2023 -0600

    Input: iqs269a - increase interrupt handler return delay
    
    [ Upstream commit e023cc4abde3c01b895660b0e5a8488deb36b8c1 ]
    
    The time the device takes to deassert its RDY output following an
    I2C stop condition scales with the core clock frequency.
    
    To prevent level-triggered interrupts from being reasserted after
    the interrupt handler returns, increase the time before returning
    to account for the worst-case delay (~140 us) plus margin.
    
    Fixes: 04e49867fad1 ("Input: add support for Azoteq IQS269A")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Link: https://lore.kernel.org/r/Y7Rs484ypy4dab5G@nixie71
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iqs269a - switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Mon Jan 2 18:17:41 2023 +0000

    Input: iqs269a - switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
    
    [ Upstream commit 29eac950768a48651e2389f7d3f2ad597f6e58d1 ]
    
    SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
    against unused function warnings.  The new combination of pm_sleep_ptr()
    and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
    thus suppressing the warning, but still allowing the unused code to be
    removed. Thus also drop the __maybe_unused markings.
    
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Jeff LaBundy <jeff@labundy.com>
    Reviewed-by: Jeff LaBundy <jeff@labundy.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20230102181842.718010-9-jic23@kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Stable-dep-of: 18ab69c8ca56 ("Input: iqs269a - do not poll during suspend or resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: xpad - add Lenovo Legion Go controllers [+ + +]
Author: Brenton Simpson <appsforartists@google.com>
Date:   Tue Jan 30 13:34:16 2024 -0800

    Input: xpad - add Lenovo Legion Go controllers
    
    [ Upstream commit 80441f76ee67002437db61f3b317ed80cce085d2 ]
    
    The Lenovo Legion Go is a handheld gaming system, similar to a Steam Deck.
    It has a gamepad (including rear paddles), 3 gyroscopes, a trackpad,
    volume buttons, a power button, and 2 LED ring lights.
    
    The Legion Go firmware presents these controls as a USB hub with various
    devices attached.  In its default state, the gamepad is presented as an
    Xbox controller connected to this hub.  (By holding a combination of
    buttons, it can be changed to use the older DirectInput API.)
    
    This patch teaches the existing Xbox controller module `xpad` to bind to
    the controller in the Legion Go, which enables support for the:
    
    - directional pad,
    - analog sticks (including clicks),
    - X, Y, A, B,
    - start and select (or menu and capture),
    - shoulder buttons, and
    - rumble.
    
    The trackpad, touchscreen, volume controls, and power button are already
    supported via existing kernel modules.  Two of the face buttons, the
    gyroscopes, rear paddles, and LEDs are not.
    
    After this patch lands, the Legion Go will be mostly functional in Linux,
    out-of-the-box.  The various components of the USB hub can be synthesized
    into a single logical controller (including the additional buttons) in
    userspace with [Handheld Daemon](https://github.com/hhd-dev/hhd), which
    makes the Go fully functional.
    
    Signed-off-by: Brenton Simpson <appsforartists@google.com>
    Link: https://lore.kernel.org/r/20240118183546.418064-1-appsforartists@google.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4: properly combine dev_base_seq and ipv4.dev_addr_genid [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 15 17:21:06 2024 +0000

    ipv4: properly combine dev_base_seq and ipv4.dev_addr_genid
    
    [ Upstream commit 081a0e3b0d4c061419d3f4679dec9f68725b17e4 ]
    
    net->dev_base_seq and ipv4.dev_addr_genid are monotonically increasing.
    
    If we XOR their values, we could miss to detect if both values
    were changed with the same amount.
    
    Fixes: 0465277f6b3f ("ipv4: provide addr and netconf dump consistency info")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: properly combine dev_base_seq and ipv6.dev_addr_genid [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 15 17:21:07 2024 +0000

    ipv6: properly combine dev_base_seq and ipv6.dev_addr_genid
    
    [ Upstream commit e898e4cd1aab271ca414f9ac6e08e4c761f6913c ]
    
    net->dev_base_seq and ipv6.dev_addr_genid are monotonically increasing.
    
    If we XOR their values, we could miss to detect if both values
    were changed with the same amount.
    
    Fixes: 63998ac24f83 ("ipv6: provide addr and netconf dump consistency info")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: sr: fix possible use-after-free and null-ptr-deref [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Thu Feb 15 23:27:17 2024 +0300

    ipv6: sr: fix possible use-after-free and null-ptr-deref
    
    [ Upstream commit 5559cea2d5aa3018a5f00dd2aca3427ba09b386b ]
    
    The pernet operations structure for the subsystem must be registered
    before registering the generic netlink family.
    
    Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20240215202717.29815-1-kovalev@altlinux.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kernel/sched: Remove dl_boosted flag comment [+ + +]
Author: Hui Su <suhui_kernel@163.com>
Date:   Fri Jan 7 17:52:54 2022 +0800

    kernel/sched: Remove dl_boosted flag comment
    
    [ Upstream commit 0e3872499de1a1230cef5221607d71aa09264bd5 ]
    
    since commit 2279f540ea7d ("sched/deadline: Fix priority
    inheritance with multiple scheduling classes"), we should not
    keep it here.
    
    Signed-off-by: Hui Su <suhui_kernel@163.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com>
    Link: https://lore.kernel.org/r/20220107095254.GA49258@localhost.localdomain
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: free aux buffer if ksmbd_iov_pin_rsp_read fails [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Mon Feb 5 14:19:16 2024 +0300

    ksmbd: free aux buffer if ksmbd_iov_pin_rsp_read fails
    
    [ Upstream commit 108a020c64434fed4b69762879d78cd24088b4c7 ]
    
    ksmbd_iov_pin_rsp_read() doesn't free the provided aux buffer if it
    fails. Seems to be the caller's responsibility to clear the buffer in
    error case.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound")
    Cc: stable@vger.kernel.org
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table() [+ + +]
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Wed Feb 21 09:27:31 2024 +0000

    KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table()
    
    commit 8d3a7dfb801d157ac423261d7cd62c33e95375f8 upstream.
    
    vgic_get_irq() may not return a valid descriptor if there is no ITS that
    holds a valid translation for the specified INTID. If that is the case,
    it is safe to silently ignore it and continue processing the LPI pending
    table.
    
    Cc: stable@vger.kernel.org
    Fixes: 33d3bc9556a7 ("KVM: arm64: vgic-its: Read initial LPI pending table")
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240221092732.4126848-2-oliver.upton@linux.dev
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler [+ + +]
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Wed Feb 21 09:27:32 2024 +0000

    KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler
    
    commit 85a71ee9a0700f6c18862ef3b0011ed9dad99aca upstream.
    
    It is possible that an LPI mapped in a different ITS gets unmapped while
    handling the MOVALL command. If that is the case, there is no state that
    can be migrated to the destination. Silently ignore it and continue
    migrating other LPIs.
    
    Cc: stable@vger.kernel.org
    Fixes: ff9c114394aa ("KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE")
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240221092732.4126848-3-oliver.upton@linux.dev
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
l2tp: pass correct message length to ip6_append_data [+ + +]
Author: Tom Parkin <tparkin@katalix.com>
Date:   Tue Feb 20 12:21:56 2024 +0000

    l2tp: pass correct message length to ip6_append_data
    
    commit 359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79 upstream.
    
    l2tp_ip6_sendmsg needs to avoid accounting for the transport header
    twice when splicing more data into an already partially-occupied skbuff.
    
    To manage this, we check whether the skbuff contains data using
    skb_queue_empty when deciding how much data to append using
    ip6_append_data.
    
    However, the code which performed the calculation was incorrect:
    
         ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
    
    ...due to C operator precedence, this ends up setting ulen to
    transhdrlen for messages with a non-zero length, which results in
    corrupted packets on the wire.
    
    Add parentheses to correct the calculation in line with the original
    intent.
    
    Fixes: 9d4c75800f61 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()")
    Cc: David Howells <dhowells@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tom Parkin <tparkin@katalix.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240220122156.43131-1-tparkin@katalix.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.15.150 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Mar 1 13:22:01 2024 +0100

    Linux 5.15.150
    
    Link: https://lore.kernel.org/r/20240227131615.098467438@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md/raid10: prevent soft lockup while flush writes [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Mon May 29 21:11:00 2023 +0800

    md/raid10: prevent soft lockup while flush writes
    
    [ Upstream commit 010444623e7f4da6b4a4dd603a7da7469981e293 ]
    
    Currently, there is no limit for raid1/raid10 plugged bio. While flushing
    writes, raid1 has cond_resched() while raid10 doesn't, and too many
    writes can cause soft lockup.
    
    Follow up soft lockup can be triggered easily with writeback test for
    raid10 with ramdisks:
    
    watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
    Call Trace:
     <TASK>
     call_rcu+0x16/0x20
     put_object+0x41/0x80
     __delete_object+0x50/0x90
     delete_object_full+0x2b/0x40
     kmemleak_free+0x46/0xa0
     slab_free_freelist_hook.constprop.0+0xed/0x1a0
     kmem_cache_free+0xfd/0x300
     mempool_free_slab+0x1f/0x30
     mempool_free+0x3a/0x100
     bio_free+0x59/0x80
     bio_put+0xcf/0x2c0
     free_r10bio+0xbf/0xf0
     raid_end_bio_io+0x78/0xb0
     one_write_done+0x8a/0xa0
     raid10_end_write_request+0x1b4/0x430
     bio_endio+0x175/0x320
     brd_submit_bio+0x3b9/0x9b7 [brd]
     __submit_bio+0x69/0xe0
     submit_bio_noacct_nocheck+0x1e6/0x5a0
     submit_bio_noacct+0x38c/0x7e0
     flush_pending_writes+0xf0/0x240
     raid10d+0xac/0x1ed0
    
    Fix the problem by adding cond_resched() to raid10 like what raid1 did.
    
    Note that unlimited plugged bio still need to be optimized, for example,
    in the case of lots of dirty pages writeback, this will take lots of
    memory and io will spend a long time in plug, hence io latency is bad.
    
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20230529131106.2123367-2-yukuai1@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: fix data corruption for raid456 when reshape restart while grow up [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri May 12 09:56:07 2023 +0800

    md: fix data corruption for raid456 when reshape restart while grow up
    
    [ Upstream commit 873f50ece41aad5c4f788a340960c53774b5526e ]
    
    Currently, if reshape is interrupted, echo "reshape" to sync_action will
    restart reshape from scratch, for example:
    
    echo frozen > sync_action
    echo reshape > sync_action
    
    This will corrupt data before reshape_position if the array is growing,
    fix the problem by continue reshape from reshape_position.
    
    Reported-by: Peter Neuwirth <reddunur@online.de>
    Link: https://lore.kernel.org/linux-raid/e2f96772-bfbc-f43b-6da1-f520e5164536@online.de/
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20230512015610.821290-3-yukuai1@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: reserve exception vector space ONLY ONCE [+ + +]
Author: Huang Pei <huangpei@loongson.cn>
Date:   Tue Jan 23 09:47:57 2024 +0800

    MIPS: reserve exception vector space ONLY ONCE
    
    [ Upstream commit abcabb9e30a1f9a69c76776f8abffc31c377b542 ]
    
    "cpu_probe" is called both by BP and APs, but reserving exception vector
    (like 0x0-0x1000) called by "cpu_probe" need once and calling on APs is
    too late since memblock is unavailable at that time.
    
    So, reserve exception vector ONLY by BP.
    
    Suggested-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Huang Pei <huangpei@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: SMP-CPS: fix build error when HOTPLUG_CPU not set [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Feb 17 12:07:49 2023 -0800

    MIPS: SMP-CPS: fix build error when HOTPLUG_CPU not set
    
    [ Upstream commit 6f02e39fa40f16c24e7a5c599a854c0d1682788d ]
    
    When MIPS_CPS=y, MIPS_CPS_PM is not set, HOTPLUG_CPU is not set, and
    KEXEC=y, cps_shutdown_this_cpu() attempts to call cps_pm_enter_state(),
    which is not built when MIPS_CPS_PM is not set.
    Conditionally execute the else branch based on CONFIG_HOTPLUG_CPU
    to remove the build error.
    This build failure is from a randconfig file.
    
    mips-linux-ld: arch/mips/kernel/smp-cps.o: in function `$L162':
    smp-cps.c:(.text.cps_kexec_nonboot_cpu+0x31c): undefined reference to `cps_pm_enter_state'
    
    Fixes: 1447864bee4c ("MIPS: kexec: CPS systems to halt nonboot CPUs")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Dengcheng Zhu <dzhu@wavecomp.com>
    Cc: Paul Burton <paulburton@kernel.org>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Cc: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: vpe-mt: drop physical_memsize [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Feb 19 15:15:25 2023 -0800

    MIPS: vpe-mt: drop physical_memsize
    
    [ Upstream commit 91dc288f4edf0d768e46c2c6d33e0ab703403459 ]
    
    When neither LANTIQ nor MIPS_MALTA is set, 'physical_memsize' is not
    declared. This causes the build to fail with:
    
    mips-linux-ld: arch/mips/kernel/vpe-mt.o: in function `vpe_run':
    arch/mips/kernel/vpe-mt.c:(.text.vpe_run+0x280): undefined reference to `physical_memsize'
    
    LANTIQ is not using 'physical_memsize' and MIPS_MALTA's use of it is
    self-contained in mti-malta/malta-dtshim.c.
    Use of physical_memsize in vpe-mt.c appears to be unused, so eliminate
    this loader mode completely and require VPE programs to be compiled with
    DFLT_STACK_SIZE and DFLT_HEAP_SIZE defined.
    
    Fixes: 9050d50e2244 ("MIPS: lantiq: Set physical_memsize")
    Fixes: 1a2a6d7e8816 ("MIPS: APRP: Split VPE loader into separate files.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/all/202302030625.2g3E98sY-lkp@intel.com/
    Cc: Dengcheng Zhu <dzhu@wavecomp.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
    Cc: "Steven J. Hill" <Steven.Hill@imgtec.com>
    Cc: Qais Yousef <Qais.Yousef@imgtec.com>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Cc: Hauke Mehrtens <hauke@hauke-m.de>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: jz4740: Use the new PM macros [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Tue Dec 7 00:21:01 2021 +0000

    mmc: jz4740: Use the new PM macros
    
    [ Upstream commit e0d64ecc621715e9c7807e952b68475c62bbf630 ]
    
     - Use DEFINE_SIMPLE_DEV_PM_OPS() instead of the SIMPLE_DEV_PM_OPS()
       macro. This makes it possible to remove the __maybe_unused flags
       on the callback functions.
    
     - Since we only have callbacks for suspend/resume, we can conditionally
       compile the dev_pm_ops structure for when CONFIG_PM_SLEEP is enabled;
       so use the pm_sleep_ptr() macro instead of pm_ptr().
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 18ab69c8ca56 ("Input: iqs269a - do not poll during suspend or resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: mxc: Use the new PM macros [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Tue Dec 7 00:21:02 2021 +0000

    mmc: mxc: Use the new PM macros
    
    [ Upstream commit 2cdbd92c2d1dff07ad56c39f5857ee644bbd2c8a ]
    
    Use DEFINE_SIMPLE_DEV_PM_OPS() instead of the SIMPLE_DEV_PM_OPS()
    macro, along with using pm_sleep_ptr() as this driver doesn't handle
    runtime PM.
    
    This makes it possible to remove the #ifdef CONFIG_PM guard around
    the suspend/resume functions.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 18ab69c8ca56 ("Input: iqs269a - do not poll during suspend or resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: fix lockless access in subflow ULP diag [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:30 2024 +0100

    mptcp: fix lockless access in subflow ULP diag
    
    commit b8adb69a7d29c2d33eb327bca66476fb6066516b upstream.
    
    Since the introduction of the subflow ULP diag interface, the
    dump callback accessed all the subflow data with lockless.
    
    We need either to annotate all the read and write operation accordingly,
    or acquire the subflow socket lock. Let's do latter, even if slower, to
    avoid a diffstat havoc.
    
    Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: rawnand: sunxi: Fix the size of the last OOB region [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Thu Dec 29 12:15:24 2022 -0600

    mtd: rawnand: sunxi: Fix the size of the last OOB region
    
    [ Upstream commit 34569d869532b54d6e360d224a0254dcdd6a1785 ]
    
    The previous code assigned to the wrong structure member.
    
    Fixes: c66811e6d350 ("mtd: nand: sunxi: switch to mtd_ooblayout_ops")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Acked-By: Dhruva Gole <d-gole@ti.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20221229181526.53766-6-samuel@sholland.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nbd: Add the maximum limit of allocated index in nbd_dev_add [+ + +]
Author: Zhong Jinghua <zhongjinghua@huawei.com>
Date:   Mon Jun 5 20:21:59 2023 +0800

    nbd: Add the maximum limit of allocated index in nbd_dev_add
    
    [ Upstream commit f12bc113ce904777fd6ca003b473b427782b3dde ]
    
    If the index allocated by idr_alloc greater than MINORMASK >> part_shift,
    the device number will overflow, resulting in failure to create a block
    device.
    
    Fix it by imiting the size of the max allocation.
    
    Signed-off-by: Zhong Jinghua <zhongjinghua@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230605122159.2134384-1-zhongjinghua@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: Refactor qdisc_graft() for ingress and clsact Qdiscs [+ + +]
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Sat Jun 10 20:30:15 2023 -0700

    net/sched: Refactor qdisc_graft() for ingress and clsact Qdiscs
    
    [ Upstream commit 2d5f6a8d7aef7852a9ecc555f88c673a1c91754f ]
    
    Grafting ingress and clsact Qdiscs does not need a for-loop in
    qdisc_graft().  Refactor it.  No functional changes intended.
    
    Tested-by: Pedro Tammela <pctammela@mojatatu.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Reviewed-by: Vlad Buslov <vladbu@nvidia.com>
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: Retire ATM qdisc [+ + +]
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Tue Feb 14 08:49:12 2023 -0500

    net/sched: Retire ATM qdisc
    
    commit fb38306ceb9e770adfb5ffa6e3c64047b55f7a07 upstream.
    
    The ATM qdisc has served us well over the years but has not been getting much
    TLC due to lack of known users. Most recently it has become a shooting target
    for syzkaller. For this reason, we are retiring it.
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/sched: Retire CBQ qdisc [+ + +]
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Tue Feb 14 08:49:11 2023 -0500

    net/sched: Retire CBQ qdisc
    
    commit 051d442098421c28c7951625652f61b1e15c4bd5 upstream.
    
    While this amazing qdisc has served us well over the years it has not been
    getting any tender love and care and has bitrotted over time.
    It has become mostly a shooting target for syzkaller lately.
    For this reason, we are retiring it. Goodbye CBQ - we loved you.
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/sched: Retire dsmark qdisc [+ + +]
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Tue Feb 14 08:49:13 2023 -0500

    net/sched: Retire dsmark qdisc
    
    commit bbe77c14ee6185a61ba6d5e435c1cbb489d2a9ed upstream.
    
    The dsmark qdisc has served us well over the years for diffserv but has not
    been getting much attention due to other more popular approaches to do diffserv
    services. Most recently it has become a shooting target for syzkaller. For this
    reason, we are retiring it.
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: dev: Convert sa_data to flexible array in struct sockaddr [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Oct 18 02:56:03 2022 -0700

    net: dev: Convert sa_data to flexible array in struct sockaddr
    
    [ Upstream commit b5f0de6df6dce8d641ef58ef7012f3304dffb9a1 ]
    
    One of the worst offenders of "fake flexible arrays" is struct sockaddr,
    as it is the classic example of why GCC and Clang have been traditionally
    forced to treat all trailing arrays as fake flexible arrays: in the
    distant misty past, sa_data became too small, and code started just
    treating it as a flexible array, even though it was fixed-size. The
    special case by the compiler is specifically that sizeof(sa->sa_data)
    and FORTIFY_SOURCE (which uses __builtin_object_size(sa->sa_data, 1))
    do not agree (14 and -1 respectively), which makes FORTIFY_SOURCE treat
    it as a flexible array.
    
    However, the coming -fstrict-flex-arrays compiler flag will remove
    these special cases so that FORTIFY_SOURCE can gain coverage over all
    the trailing arrays in the kernel that are _not_ supposed to be treated
    as a flexible array. To deal with this change, convert sa_data to a true
    flexible array. To keep the structure size the same, move sa_data into
    a union with a newly introduced sa_data_min with the original size. The
    result is that FORTIFY_SOURCE can continue to have no idea how large
    sa_data may actually be, but anything using sizeof(sa->sa_data) must
    switch to sizeof(sa->sa_data_min).
    
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Pavel Begunkov <asml.silence@gmail.com>
    Cc: David Ahern <dsahern@kernel.org>
    Cc: Dylan Yudaken <dylany@fb.com>
    Cc: Yajun Deng <yajun.deng@linux.dev>
    Cc: Petr Machata <petrm@nvidia.com>
    Cc: Hangbin Liu <liuhangbin@gmail.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: syzbot <syzkaller@googlegroups.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221018095503.never.671-kees@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a7d6027790ac ("arp: Prevent overflow in arp_req_get().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: ti: add missing of_node_put before return [+ + +]
Author: Wang Qing <wangqing@vivo.com>
Date:   Mon Dec 13 01:44:36 2021 -0800

    net: ethernet: ti: add missing of_node_put before return
    
    [ Upstream commit be565ec71d1d59438bed0c7ed0a252a327e0b0ef ]
    
    Fix following coccicheck warning:
    WARNING: Function "for_each_child_of_node"
    should have of_node_put() before return.
    
    Early exits from for_each_child_of_node should decrement the
    node reference counter.
    
    Signed-off-by: Wang Qing <wangqing@vivo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: Fix incorrect dereference in interrupt handlers [+ + +]
Author: Pavel Sakharov <p.sakharov@ispras.ru>
Date:   Wed Feb 14 12:27:17 2024 +0300

    net: stmmac: Fix incorrect dereference in interrupt handlers
    
    [ Upstream commit 97dde84026339e4b4af9a6301f825d1828d7874b ]
    
    If 'dev' or 'data' is NULL, the 'priv' variable has an incorrect address
    when dereferencing calling netdev_err().
    
    Since we get as 'dev_id' or 'data' what was passed as the 'dev' argument
    to request_irq() during interrupt initialization (that is, the net_device
    and rx/tx queue pointers initialized at the time of the call) and since
    there are usually no checks for the 'dev_id' argument in such handlers
    in other drivers, remove these checks from the handlers in stmmac driver.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX")
    Signed-off-by: Pavel Sakharov <p.sakharov@ispras.ru>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Jan 25 17:29:46 2024 -0500

    netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new
    
    [ Upstream commit 6e348067ee4bc5905e35faa3a8fafa91c9124bc7 ]
    
    The annotation says in sctp_new(): "If it is a shutdown ack OOTB packet, we
    expect a return shutdown complete, otherwise an ABORT Sec 8.4 (5) and (8)".
    However, it does not check SCTP_CID_SHUTDOWN_ACK before setting vtag[REPLY]
    in the conntrack entry(ct).
    
    Because of that, if the ct in Router disappears for some reason in [1]
    with the packet sequence like below:
    
       Client > Server: sctp (1) [INIT] [init tag: 3201533963]
       Server > Client: sctp (1) [INIT ACK] [init tag: 972498433]
       Client > Server: sctp (1) [COOKIE ECHO]
       Server > Client: sctp (1) [COOKIE ACK]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057809]
       Server > Client: sctp (1) [SACK] [cum ack 3075057809]
       Server > Client: sctp (1) [HB REQ]
       (the ct in Router disappears somehow)  <-------- [1]
       Client > Server: sctp (1) [HB ACK]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
       Client > Server: sctp (1) [HB REQ]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
       Client > Server: sctp (1) [HB REQ]
       Client > Server: sctp (1) [ABORT]
    
    when processing HB ACK packet in Router it calls sctp_new() to initialize
    the new ct with vtag[REPLY] set to HB_ACK packet's vtag.
    
    Later when sending DATA from Client, all the SACKs from Server will get
    dropped in Router, as the SACK packet's vtag does not match vtag[REPLY]
    in the ct. The worst thing is the vtag in this ct will never get fixed
    by the upcoming packets from Server.
    
    This patch fixes it by checking SCTP_CID_SHUTDOWN_ACK before setting
    vtag[REPLY] in the ct in sctp_new() as the annotation says. With this
    fix, it will leave vtag[REPLY] in ct to 0 in the case above, and the
    next HB REQ/ACK from Server is able to fix the vtag as its value is 0
    in nf_conntrack_sctp_packet().
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: flowtable: simplify route logic [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu May 11 07:35:33 2023 +0200

    netfilter: flowtable: simplify route logic
    
    [ Upstream commit fa502c86566680ac62bc28ec883a069bf7a2aa5e ]
    
    Grab reference to dst from skbuff earlier to simplify route caching.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Stable-dep-of: 9e0f0430389b ("netfilter: nft_flow_offload: reset dst in route object after setting up flow")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: add rescheduling points during loop detection walks [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jul 26 12:44:35 2022 +0200

    netfilter: nf_tables: add rescheduling points during loop detection walks
    
    [ Upstream commit 81ea010667417ef3f218dfd99b69769fe66c2b67 ]
    
    Add explicit rescheduling points during ruleset walk.
    
    Switching to a faster algorithm is possible but this is a much
    smaller change, suitable for nf tree.
    
    Link: https://bugzilla.netfilter.org/show_bug.cgi?id=1460
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: can't schedule in nft_chain_validate [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jul 18 01:30:33 2023 +0200

    netfilter: nf_tables: can't schedule in nft_chain_validate
    
    commit 314c82841602a111c04a7210c21dc77e0d560242 upstream.
    
    Can be called via nft set element list iteration, which may acquire
    rcu and/or bh read lock (depends on set type).
    
    BUG: sleeping function called from invalid context at net/netfilter/nf_tables_api.c:3353
    in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1232, name: nft
    preempt_count: 0, expected: 0
    RCU nest depth: 1, expected: 0
    2 locks held by nft/1232:
     #0: ffff8881180e3ea8 (&nft_net->commit_mutex){+.+.}-{3:3}, at: nf_tables_valid_genid
     #1: ffffffff83f5f540 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire
    Call Trace:
     nft_chain_validate
     nft_lookup_validate_setelem
     nft_pipapo_walk
     nft_lookup_validate
     nft_chain_validate
     nft_immediate_validate
     nft_chain_validate
     nf_tables_validate
     nf_tables_abort
    
    No choice but to move it to nf_tables_validate().
    
    Fixes: 81ea01066741 ("netfilter: nf_tables: add rescheduling points during loop detection walks")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: fix scheduling-while-atomic splat [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 11 13:30:39 2022 +0200

    netfilter: nf_tables: fix scheduling-while-atomic splat
    
    commit 2024439bd5ceb145eeeb428b2a59e9b905153ac3 upstream.
    
    nf_tables_check_loops() can be called from rhashtable list
    walk so cond_resched() cannot be used here.
    
    Fixes: 81ea01066741 ("netfilter: nf_tables: add rescheduling points during loop detection walks")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: set dormant flag on hook register failure [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Feb 19 16:58:04 2024 +0100

    netfilter: nf_tables: set dormant flag on hook register failure
    
    [ Upstream commit bccebf64701735533c8db37773eeacc6566cc8ec ]
    
    We need to set the dormant flag again if we fail to register
    the hooks.
    
    During memory pressure hook registration can fail and we end up
    with a table marked as active but no registered hooks.
    
    On table/base chain deletion, nf_tables will attempt to unregister
    the hook again which yields a warn splat from the nftables core.
    
    Reported-and-tested-by: syzbot+de4025c006ec68ac56fc@syzkaller.appspotmail.com
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_flow_offload: release dst in case direct xmit path is used [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Feb 20 21:36:39 2024 +0100

    netfilter: nft_flow_offload: release dst in case direct xmit path is used
    
    [ Upstream commit 8762785f459be1cfe6fcf7285c123aad6a3703f0 ]
    
    Direct xmit does not use it since it calls dev_queue_xmit() to send
    packets, hence it calls dst_release().
    
    kmemleak reports:
    
    unreferenced object 0xffff88814f440900 (size 184):
      comm "softirq", pid 0, jiffies 4294951896
      hex dump (first 32 bytes):
        00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff  .`[.............
        21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00  !.P.............
      backtrace (crc cb2bf5d6):
        [<000000003ee17107>] kmem_cache_alloc+0x286/0x340
        [<0000000021a5de2c>] dst_alloc+0x43/0xb0
        [<00000000f0671159>] rt_dst_alloc+0x2e/0x190
        [<00000000fe5092c9>] __mkroute_output+0x244/0x980
        [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160
        [<0000000045367433>] nf_ip_route+0xf/0x30
        [<0000000085da1d8e>] nf_route+0x2d/0x60
        [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload]
        [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload]
        [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables]
        [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables]
        [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables]
        [<0000000097c9d5c6>] nf_hook_slow+0x5b/0x160
        [<0000000005eccab1>] ip_forward+0x8b6/0x9b0
        [<00000000553a269b>] ip_rcv+0x221/0x230
        [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110
    
    Fixes: fa502c865666 ("netfilter: flowtable: simplify route logic")
    Reported-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_flow_offload: reset dst in route object after setting up flow [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Feb 21 12:32:58 2024 +0100

    netfilter: nft_flow_offload: reset dst in route object after setting up flow
    
    [ Upstream commit 9e0f0430389be7696396c62f037be4bf72cf93e3 ]
    
    dst is transferred to the flow object, route object does not own it
    anymore.  Reset dst in route object, otherwise if flow_offload_add()
    fails, error path releases dst twice, leading to a refcount underflow.
    
    Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nouveau: fix function cast warnings [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 13 10:57:37 2024 +0100

    nouveau: fix function cast warnings
    
    [ Upstream commit 0affdba22aca5573f9d989bcb1d71d32a6a03efe ]
    
    clang-16 warns about casting between incompatible function types:
    
    drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from 'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      161 |         .fini = (void(*)(void *))release_firmware,
    
    This one was done to use the generic shadow_fw_release() function as a
    callback for struct nvbios_source. Change it to use the same prototype
    as the other five instances, with a trivial helper function that actually
    calls release_firmware.
    
    Fixes: 70c0f263cc2e ("drm/nouveau/bios: pull in basic vbios subdev, more to come later")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240213095753.455062-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-fc: do not wait in vain when unloading module [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:01 2024 +0100

    nvme-fc: do not wait in vain when unloading module
    
    [ Upstream commit 70fbfc47a392b98e5f8dba70c6efc6839205c982 ]
    
    The module exit path has race between deleting all controllers and
    freeing 'left over IDs'. To prevent double free a synchronization
    between nvme_delete_ctrl and ida_destroy has been added by the initial
    commit.
    
    There is some logic around trying to prevent from hanging forever in
    wait_for_completion, though it does not handling all cases. E.g.
    blktests is able to reproduce the situation where the module unload
    hangs forever.
    
    If we completely rely on the cleanup code executed from the
    nvme_delete_ctrl path, all IDs will be freed eventually. This makes
    calling ida_destroy unnecessary. We only have to ensure that all
    nvme_delete_ctrl code has been executed before we leave
    nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
    workqueue.
    
    While at it, remove the unused nvme_fc_wq workqueue too.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-fc: abort command when there is no binding [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:09 2024 +0100

    nvmet-fc: abort command when there is no binding
    
    [ Upstream commit 3146345c2e9c2f661527054e402b0cfad80105a4 ]
    
    When the target port has not active port binding, there is no point in
    trying to process the command as it has to fail anyway. Instead adding
    checks to all commands abort the command early.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-fc: avoid deadlock on delete association path [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:10 2024 +0100

    nvmet-fc: avoid deadlock on delete association path
    
    [ Upstream commit 710c69dbaccdac312e32931abcb8499c1525d397 ]
    
    When deleting an association the shutdown path is deadlocking because we
    try to flush the nvmet_wq nested. Avoid this by deadlock by deferring
    the put work into its own work item.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-fc: defer cleanup using RCU properly [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:04 2024 +0100

    nvmet-fc: defer cleanup using RCU properly
    
    [ Upstream commit 4049dc96b8de7aeb3addcea039446e464726a525 ]
    
    When the target executes a disconnect and the host triggers a reconnect
    immediately, the reconnect command still finds an existing association.
    
    The reconnect crashes later on because nvmet_fc_delete_target_assoc
    blindly removes resources while the reconnect code wants to use it.
    
    To address this, nvmet_fc_find_target_assoc should not be able to
    lookup an association which is being removed. The association list
    is already under RCU lifetime management, so let's properly use it
    and remove the association from the list and wait for a grace period
    before cleaning up all. This means we also can drop the RCU management
    on the queues, because this is now handled via the association itself.
    
    A second step split the execution context so that the initial disconnect
    command can complete without running the reconnect code in the same
    context. As usual, this is done by deferring the ->done to a workqueue.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-fc: hold reference on hostport match [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:06 2024 +0100

    nvmet-fc: hold reference on hostport match
    
    [ Upstream commit ca121a0f7515591dba0eb5532bfa7ace4dc153ce ]
    
    The hostport data structure is shared between the association, this why
    we keep track of the users via a refcount. So we should not decrement
    the refcount on a match and free the hostport several times.
    
    Reported by KASAN.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-fc: release reference on target port [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:03 2024 +0100

    nvmet-fc: release reference on target port
    
    [ Upstream commit c691e6d7e13dab81ac8c7489c83b5dea972522a5 ]
    
    In case we return early out of __nvmet_fc_finish_ls_req() we still have
    to release the reference on the target port.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-fc: take ref count on tgtport before delete assoc [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:11 2024 +0100

    nvmet-fc: take ref count on tgtport before delete assoc
    
    [ Upstream commit fe506a74589326183297d5abdda02d0c76ae5a8b ]
    
    We have to ensure that the tgtport is not going away
    before be have remove all the associations.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-fcloop: swap the list_add_tail arguments [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:02 2024 +0100

    nvmet-fcloop: swap the list_add_tail arguments
    
    [ Upstream commit dcfad4ab4d6733f2861cd241d8532a0004fc835a ]
    
    The first argument of list_add_tail function is the new element which
    should be added to the list which is the second argument. Swap the
    arguments to allow processing more than one element at a time.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-tcp: fix nvme tcp ida memory leak [+ + +]
Author: Guixin Liu <kanie@linux.alibaba.com>
Date:   Fri Jan 26 16:26:43 2024 +0800

    nvmet-tcp: fix nvme tcp ida memory leak
    
    [ Upstream commit 47c5dd66c1840524572dcdd956f4af2bdb6fbdff ]
    
    The nvmet_tcp_queue_ida should be destroy when the nvmet-tcp module
    exit.
    
    Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: Consider the action set by PF [+ + +]
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Mon Feb 19 18:25:14 2024 +0530

    octeontx2-af: Consider the action set by PF
    
    [ Upstream commit 3b1ae9b71c2a97f848b00fb085a2bd29bddbe8d9 ]
    
    AF reserves MCAM entries for each PF, VF present in the
    system and populates the entry with DMAC and action with
    default RSS so that basic packet I/O works. Since PF/VF is
    not aware of the RSS action installed by AF, AF only fixup
    the actions of the rules installed by PF/VF with corresponding
    default RSS action. This worked well for rules installed by
    PF/VF for features like RX VLAN offload and DMAC filters but
    rules involving action like drop/forward to queue are also
    getting modified by AF. Hence fix it by setting the default
    RSS action only if requested by PF/VF.
    
    Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
packet: move from strlcpy with unused retval to strscpy [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Aug 18 23:02:27 2022 +0200

    packet: move from strlcpy with unused retval to strscpy
    
    [ Upstream commit 8fc9d51ea2d32a05f7d7cf86a25cc86ecc57eb45 ]
    
    Follow the advice of the below link and prefer 'strscpy' in this
    subsystem. Conversion is 1:1 because the return value is not used.
    Generated by a coccinelle script.
    
    Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/20220818210227.8611-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a7d6027790ac ("arp: Prevent overflow in arp_req_get().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/MSI: Prevent MSI hardware interrupt number truncation [+ + +]
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Mon Jan 15 19:26:49 2024 +0530

    PCI/MSI: Prevent MSI hardware interrupt number truncation
    
    commit db744ddd59be798c2627efbfc71f707f5a935a40 upstream.
    
    While calculating the hardware interrupt number for a MSI interrupt, the
    higher bits (i.e. from bit-5 onwards a.k.a domain_nr >= 32) of the PCI
    domain number gets truncated because of the shifted value casting to return
    type of pci_domain_nr() which is 'int'. This for example is resulting in
    same hardware interrupt number for devices 0019:00:00.0 and 0039:00:00.0.
    
    To address this cast the PCI domain number to 'irq_hw_number_t' before left
    shifting it to calculate the hardware interrupt number.
    
    Please note that this fixes the issue only on 64-bit systems and doesn't
    change the behavior for 32-bit systems i.e. the 32-bit systems continue to
    have the issue. Since the issue surfaces only if there are too many PCIe
    controllers in the system which usually is the case in modern server
    systems and they don't tend to run 32-bit kernels.
    
    Fixes: 3878eaefb89a ("PCI/MSI: Enhance core to support hierarchy irqdomain")
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Shanker Donthineni <sdonthineni@nvidia.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240115135649.708536-1-vidyas@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Jan 26 11:40:37 2024 +0300

    PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()
    
    commit b5d1b4b46f856da1473c7ba9a5cdfcb55c9b2478 upstream.
    
    The "msg_addr" variable is u64.  However, the "aligned_offset" is an
    unsigned int.  This means that when the code does:
    
      msg_addr &= ~aligned_offset;
    
    it will unintentionally zero out the high 32 bits.  Use ALIGN_DOWN() to do
    the alignment instead.
    
    Fixes: 2217fffcd63f ("PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support")
    Link: https://lore.kernel.org/r/af59c7ad-ab93-40f7-ad4a-7ac0b14d37f5@moroto.mountain
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf beauty: Update copy of linux/socket.h with the kernel sources [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Sat Jun 19 10:09:08 2021 -0300

    perf beauty: Update copy of linux/socket.h with the kernel sources
    
    [ Upstream commit 6da2a45e15af4f706fed211f8eb57a40cc7abfc7 ]
    
    To pick the changes in:
    
      99ce45d5e7dbde39 ("mctp: Implement extended addressing")
      55c42fa7fa331f98 ("mptcp: add MPTCP_INFO getsockopt")
    
    That don't result in any changes in the tables generated from that
    header.
    
    A table generator for setsockopt is needed, probably will be done in the
    5.16 cycle.
    
    This silences this perf build warning:
    
      Warning: Kernel ABI header at 'tools/perf/trace/beauty/include/linux/socket.h' differs from latest version at 'include/linux/socket.h'
      diff -u tools/perf/trace/beauty/include/linux/socket.h include/linux/socket.h
    
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Florian Westphal <fw@strlen.de>
    Cc: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: asus-wmi: Document the dgpu_disable sysfs attribute [+ + +]
Author: Luke D. Jones <luke@ljones.dev>
Date:   Sat Aug 13 10:25:04 2022 +1200

    platform/x86: asus-wmi: Document the dgpu_disable sysfs attribute
    
    [ Upstream commit 7e64c486e807c8edfbd3a0c8e44ad7a1896dbec8 ]
    
    The dgpu_disable attribute was not documented, this adds the
    required documentation.
    
    Fixes: 98829e84dc67 ("asus-wmi: Add dgpu disable method")
    Signed-off-by: Luke D. Jones <luke@ljones.dev>
    Link: https://lore.kernel.org/r/20220812222509.292692-2-luke@ljones.dev
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: intel-vbtn: Stop calling "VBDL" from notify_handler [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Feb 16 21:33:00 2024 +0100

    platform/x86: intel-vbtn: Stop calling "VBDL" from notify_handler
    
    commit 84c16d01ff219bc0a5dca5219db6b8b86a6854fb upstream.
    
    Commit 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing
    tablet-mode-switch events") causes 2 issues on the ThinkPad X1 Tablet Gen2:
    
    1. The ThinkPad will wake up immediately from suspend
    2. When put in tablet mode SW_TABLET_MODE reverts to 0 after about 1 second
    
    Both these issues are caused by the "VBDL" ACPI method call added
    at the end of the notify_handler.
    
    And it never became entirely clear if this call is even necessary to fix
    the issue of missing tablet-mode-switch events on the Dell Inspiron 7352.
    
    Drop the "VBDL" ACPI method call again to fix the 2 issues this is
    causing on the ThinkPad X1 Tablet Gen2.
    
    Fixes: 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events")
    Reported-by: Alexander Kobel <a-kobel@a-kobel.de>
    Closes: https://lore.kernel.org/platform-driver-x86/295984ce-bd4b-49bd-adc5-ffe7c898d7f0@a-kobel.de/
    Cc: regressions@lists.linux.dev
    Cc: Arnold Gozum <arngozum@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Alexander Kobel <a-kobel@a-kobel.de>
    Link: https://lore.kernel.org/r/20240216203300.245826-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet [+ + +]
Author: Phoenix Chen <asbeltogf@gmail.com>
Date:   Fri Jan 26 17:53:08 2024 +0800

    platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet
    
    [ Upstream commit 1abdf288b0ef5606f76b6e191fa6df05330e3d7e ]
    
    Add touch screen info for TECLAST X16 Plus tablet.
    
    Signed-off-by: Phoenix Chen <asbeltogf@gmail.com>
    Link: https://lore.kernel.org/r/20240126095308.5042-1-asbeltogf@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI names [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Feb 12 13:06:07 2024 +0100

    platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI names
    
    commit dbcbfd662a725641d118fb3ae5ffb7be4e3d0fb0 upstream.
    
    On some devices the ACPI name of the touchscreen is e.g. either
    MSSL1680:00 or MSSL1680:01 depending on the BIOS version.
    
    This happens for example on the "Chuwi Hi8 Air" tablet where the initial
    commit's ts_data uses "MSSL1680:00" but the tablets from the github issue
    and linux-hardware.org probe linked below both use "MSSL1680:01".
    
    Replace the strcmp() match on ts_data->acpi_name with a strstarts()
    check to allow using a partial match on just the ACPI HID of "MSSL1680"
    and change the ts_data->acpi_name for the "Chuwi Hi8 Air" accordingly
    to fix the touchscreen not working on models where it is "MSSL1680:01".
    
    Note this drops the length check for I2C_NAME_SIZE. This never was
    necessary since the ACPI names used are never more then 11 chars and
    I2C_NAME_SIZE is 20 so the replaced strncmp() would always stop long
    before reaching I2C_NAME_SIZE.
    
    Link: https://linux-hardware.org/?computer=AC4301C0542A
    Fixes: bbb97d728f77 ("platform/x86: touchscreen_dmi: Add info for the Chuwi Hi8 Air tablet")
    Closes: https://github.com/onitake/gsl-firmware/issues/91
    Cc: stable@vger.kernel.org
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240212120608.30469-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PM: core: Add new *_PM_OPS macros, deprecate old ones [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Tue Dec 7 00:21:00 2021 +0000

    PM: core: Add new *_PM_OPS macros, deprecate old ones
    
    [ Upstream commit 1a3c7bb088266fa2db017be299f91f1c1894c857 ]
    
    This commit introduces the following macros:
    
    SYSTEM_SLEEP_PM_OPS()
    LATE_SYSTEM_SLEEP_PM_OPS()
    NOIRQ_SYSTEM_SLEEP_PM_OPS()
    RUNTIME_PM_OPS()
    
    These new macros are very similar to their SET_*_PM_OPS() equivalent.
    They however differ in the fact that the callbacks they set will always
    be seen as referenced by the compiler. This means that the callback
    functions don't need to be wrapped with a #ifdef CONFIG_PM guard, or
    tagged with __maybe_unused, to prevent the compiler from complaining
    about unused static symbols. The compiler will then simply evaluate at
    compile time whether or not these symbols are dead code.
    
    The callbacks that are only useful with CONFIG_PM_SLEEP is enabled, are
    now also wrapped with a new pm_sleep_ptr() macro, which is inspired from
    pm_ptr(). This is needed for drivers that use different callbacks for
    sleep and runtime PM, to handle the case where CONFIG_PM is set and
    CONFIG_PM_SLEEP is not.
    
    This commit also deprecates the following macros:
    
    SIMPLE_DEV_PM_OPS()
    UNIVERSAL_DEV_PM_OPS()
    
    And introduces the following macros:
    
    DEFINE_SIMPLE_DEV_PM_OPS()
    DEFINE_UNIVERSAL_DEV_PM_OPS()
    
    These macros are similar to the functions they were created to replace,
    with the following differences:
    
     - They use the new macros introduced above, and as such always
       reference the provided callback functions.
    
     - They are not tagged with __maybe_unused. They are meant to be used
       with pm_ptr() or pm_sleep_ptr() for DEFINE_UNIVERSAL_DEV_PM_OPS()
       and DEFINE_SIMPLE_DEV_PM_OPS() respectively.
    
     - They declare the symbol static, since every driver seems to do that
       anyway; and if a non-static use-case is needed an indirection pointer
       could be used.
    
    The point of this change, is to progressively switch from a code model
    where PM callbacks are all protected behind CONFIG_PM guards, to a code
    model where the PM callbacks are always seen by the compiler, but
    discarded if not used.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 18ab69c8ca56 ("Input: iqs269a - do not poll during suspend or resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: core: Redefine pm_ptr() macro [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Tue Dec 7 00:20:59 2021 +0000

    PM: core: Redefine pm_ptr() macro
    
    [ Upstream commit c06ef740d401d0f4ab188882bf6f8d9cf0f75eaf ]
    
    The pm_ptr() macro was previously conditionally defined, according to
    the value of the CONFIG_PM option. This meant that the pointed structure
    was either referenced (if CONFIG_PM was set), or never referenced (if
    CONFIG_PM was not set), causing it to be detected as unused by the
    compiler.
    
    This worked fine, but required the __maybe_unused compiler attribute to
    be used to every symbol pointed to by a pointer wrapped with pm_ptr().
    
    We can do better. With this change, the pm_ptr() is now defined the
    same, independently of the value of CONFIG_PM. It now uses the (?:)
    ternary operator to conditionally resolve to its argument. Since the
    condition is known at compile time, the compiler will then choose to
    discard the unused symbols, which won't need to be tagged with
    __maybe_unused anymore.
    
    This pm_ptr() macro is usually used with pointers to dev_pm_ops
    structures created with SIMPLE_DEV_PM_OPS() or similar macros. These do
    use a __maybe_unused flag, which is now useless with this change, so it
    later can be removed. However in the meantime it causes no harm, and all
    the drivers still compile fine with the new pm_ptr() macro.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 18ab69c8ca56 ("Input: iqs269a - do not poll during suspend or resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: core: Remove static qualifier in DEFINE_SIMPLE_DEV_PM_OPS macro [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Jan 7 18:17:19 2022 +0000

    PM: core: Remove static qualifier in DEFINE_SIMPLE_DEV_PM_OPS macro
    
    [ Upstream commit 52cc1d7f9786d2be44a3ab9b5b48416a7618e713 ]
    
    Keep this macro in line with the other ones. This makes it possible to
    use them in the cases where the underlying dev_pm_ops structure is
    exported.
    
    Restore the "static" qualifier in the two drivers where the
    DEFINE_SIMPLE_DEV_PM_OPS macro was used.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 18ab69c8ca56 ("Input: iqs269a - do not poll during suspend or resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pmdomain: mediatek: fix race conditions with genpd [+ + +]
Author: Eugen Hristev <eugen.hristev@collabora.com>
Date:   Mon Dec 25 15:36:15 2023 +0200

    pmdomain: mediatek: fix race conditions with genpd
    
    [ Upstream commit c41336f4d69057cbf88fed47951379b384540df5 ]
    
    If the power domains are registered first with genpd and *after that*
    the driver attempts to power them on in the probe sequence, then it is
    possible that a race condition occurs if genpd tries to power them on
    in the same time.
    The same is valid for powering them off before unregistering them
    from genpd.
    Attempt to fix race conditions by first removing the domains from genpd
    and *after that* powering down domains.
    Also first power up the domains and *after that* register them
    to genpd.
    
    Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains")
    Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231225133615.78993-1-eugen.hristev@collabora.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pmdomain: renesas: r8a77980-sysc: CR7 must be always on [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jan 12 17:33:55 2024 +0100

    pmdomain: renesas: r8a77980-sysc: CR7 must be always on
    
    [ Upstream commit f0e4a1356466ec1858ae8e5c70bea2ce5e55008b ]
    
    The power domain containing the Cortex-R7 CPU core on the R-Car V3H SoC
    must always be in power-on state, unlike on other SoCs in the R-Car Gen3
    family.  See Table 9.4 "Power domains" in the R-Car Series, 3rd
    Generation Hardware User’s Manual Rev.1.00 and later.
    
    Fix this by marking the domain as a CPU domain without control
    registers, so the driver will not touch it.
    
    Fixes: 41d6d8bd8ae9 ("soc: renesas: rcar-sysc: add R8A77980 support")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/fdad9a86132d53ecddf72b734dac406915c4edc0.1705076735.git.geert+renesas@glider.be
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
posix-timers: Ensure timer ID search-loop limit is valid [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jun 1 20:58:47 2023 +0200

    posix-timers: Ensure timer ID search-loop limit is valid
    
    [ Upstream commit 8ce8849dd1e78dadcee0ec9acbd259d239b7069f ]
    
    posix_timer_add() tries to allocate a posix timer ID by starting from the
    cached ID which was stored by the last successful allocation.
    
    This is done in a loop searching the ID space for a free slot one by
    one. The loop has to terminate when the search wrapped around to the
    starting point.
    
    But that's racy vs. establishing the starting point. That is read out
    lockless, which leads to the following problem:
    
    CPU0                               CPU1
    posix_timer_add()
      start = sig->posix_timer_id;
      lock(hash_lock);
      ...                              posix_timer_add()
      if (++sig->posix_timer_id < 0)
                                         start = sig->posix_timer_id;
         sig->posix_timer_id = 0;
    
    So CPU1 can observe a negative start value, i.e. -1, and the loop break
    never happens because the condition can never be true:
    
      if (sig->posix_timer_id == start)
         break;
    
    While this is unlikely to ever turn into an endless loop as the ID space is
    huge (INT_MAX), the racy read of the start value caught the attention of
    KCSAN and Dmitry unearthed that incorrectness.
    
    Rewrite it so that all id operations are under the hash lock.
    
    Reported-by: syzbot+5c54bd3eb218bb595aa9@syzkaller.appspotmail.com
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Link: https://lore.kernel.org/r/87bkhzdn6g.ffs@tglx
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/eeh: Set channel state after notifying the drivers [+ + +]
Author: Ganesh Goudar <ganeshgr@linux.ibm.com>
Date:   Thu Feb 9 16:26:49 2023 +0530

    powerpc/eeh: Set channel state after notifying the drivers
    
    [ Upstream commit 9efcdaac36e1643a1b7f5337e6143ce142d381b1 ]
    
    When a PCI error is encountered 6th time in an hour we
    set the channel state to perm_failure and notify the
    driver about the permanent failure.
    
    However, after upstream commit 38ddc011478e ("powerpc/eeh:
    Make permanently failed devices non-actionable"), EEH handler
    stops calling any routine once the device is marked as
    permanent failure. This issue can lead to fatal consequences
    like kernel hang with certain PCI devices.
    
    Following log is observed with lpfc driver, with and without
    this change, Without this change kernel hangs, If PCI error
    is encountered 6 times for a device in an hour.
    
    Without the change
    
     EEH: Beginning: 'error_detected(permanent failure)'
     PCI 0132:60:00.0#600000: EEH: not actionable (1,1,1)
     PCI 0132:60:00.1#600000: EEH: not actionable (1,1,1)
     EEH: Finished:'error_detected(permanent failure)'
    
    With the change
    
     EEH: Beginning: 'error_detected(permanent failure)'
     EEH: Invoking lpfc->error_detected(permanent failure)
     EEH: lpfc driver reports: 'disconnect'
     EEH: Invoking lpfc->error_detected(permanent failure)
     EEH: lpfc driver reports: 'disconnect'
     EEH: Finished:'error_detected(permanent failure)'
    
    To fix the issue, set channel state to permanent failure after
    notifying the drivers.
    
    Fixes: 38ddc011478e ("powerpc/eeh: Make permanently failed devices non-actionable")
    Suggested-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230209105649.127707-1-ganeshgr@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/eeh: Small refactor of eeh_handle_normal_event() [+ + +]
Author: Daniel Axtens <dja@axtens.net>
Date:   Fri Oct 15 18:06:27 2021 +1100

    powerpc/eeh: Small refactor of eeh_handle_normal_event()
    
    [ Upstream commit 10b34ece132ee46dc4e6459c765d180c422a09fa ]
    
    The control flow of eeh_handle_normal_event() is a bit tricky.
    
    Break out one of the error handling paths - rather than be in an else
    block, we'll make it part of the regular body of the function and put a
    'goto out;' in the true limb of the if.
    
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211015070628.1331635-1-dja@axtens.net
    Stable-dep-of: 9efcdaac36e1 ("powerpc/eeh: Set channel state after notifying the drivers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/perf/hv-24x7: add missing RTAS retry status handling [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri Feb 10 12:41:50 2023 -0600

    powerpc/perf/hv-24x7: add missing RTAS retry status handling
    
    [ Upstream commit cc4b26eab1859fa1a70711872caaf6414809973f ]
    
    The ibm,get-system-parameter RTAS function may return -2 or 990x,
    which indicate that the caller should try again. read_24x7_sys_info()
    ignores this, allowing transient failures in reporting processor
    module information.
    
    Move the RTAS call into a coventional rtas_busy_delay()-based loop,
    along with the parsing of results on success.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Fixes: 8ba214267382 ("powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-2-26929c8cce78@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/powernv/ioda: Skip unallocated resources when mapping to PE [+ + +]
Author: Frederic Barrat <fbarrat@linux.ibm.com>
Date:   Fri Jan 20 10:32:15 2023 +0100

    powerpc/powernv/ioda: Skip unallocated resources when mapping to PE
    
    [ Upstream commit e64e71056f323a1e178dccf04d4c0f032d84436c ]
    
    pnv_ioda_setup_pe_res() calls opal to map a resource with a PE. However,
    the code assumes the resource is allocated and it uses the resource
    address to find out the segment(s) which need to be mapped to the
    PE. In the unlikely case where the resource hasn't been allocated, the
    computation for the segment number is garbage, which can lead to
    invalid memory access and potentially a kernel crash, such as:
    
    [ ] pci_bus 0002:02: Configuring PE for bus
    [ ] pci 0002:02     : [PE# fc] Secondary bus 0x0000000000000002..0x0000000000000002 associated with PE#fc
    [ ] BUG: Kernel NULL pointer dereference on write at 0x00000000
    [ ] Faulting instruction address: 0xc00000000005eac4
    [ ] Oops: Kernel access of bad area, sig: 7 [#1]
    [ ] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
    [ ] Modules linked in:
    [ ] CPU: 12 PID: 1 Comm: swapper/20 Not tainted 5.10.50-openpower1 #2
    [ ] NIP:  c00000000005eac4 LR: c00000000005ea44 CTR: 0000000030061b9c
    [ ] REGS: c000200007383650 TRAP: 0300   Not tainted  (5.10.50-openpower1)
    [ ] MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 44000224  XER: 20040000
    [ ] CFAR: c00000000005eaa0 DAR: 0000000000000000 DSISR: 02080000 IRQMASK: 0
    [ ] GPR00: c00000000005dd98 c0002000073838e0 c00000000185de00 c000200fff018960
    [ ] GPR04: 00000000000000fc 0000000000000003 0000000000000000 0000000000000000
    [ ] GPR08: 0000000000000000 0000000000000000 0000000000000000 9000000000001033
    [ ] GPR12: 0000000031cb0000 c000000ffffe6a80 c000000000010a58 0000000000000000
    [ ] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [ ] GPR20: 0000000000000000 0000000000000000 0000000000000000 c00000000711e200
    [ ] GPR24: 0000000000000100 c000200009501120 c00020000cee2800 00000000000003ff
    [ ] GPR28: c000200fff018960 0000000000000000 c000200ffcb7fd00 0000000000000000
    [ ] NIP [c00000000005eac4] pnv_ioda_setup_pe_res+0x94/0x1a0
    [ ] LR [c00000000005ea44] pnv_ioda_setup_pe_res+0x14/0x1a0
    [ ] Call Trace:
    [ ] [c0002000073838e0] [c00000000005eb98] pnv_ioda_setup_pe_res+0x168/0x1a0 (unreliable)
    [ ] [c000200007383970] [c00000000005dd98] pnv_pci_ioda_dma_dev_setup+0x43c/0x970
    [ ] [c000200007383a60] [c000000000032cdc] pcibios_bus_add_device+0x78/0x18c
    [ ] [c000200007383aa0] [c00000000028f2bc] pci_bus_add_device+0x28/0xbc
    [ ] [c000200007383b10] [c00000000028f3a0] pci_bus_add_devices+0x50/0x7c
    [ ] [c000200007383b50] [c00000000028f3c4] pci_bus_add_devices+0x74/0x7c
    [ ] [c000200007383b90] [c00000000028f3c4] pci_bus_add_devices+0x74/0x7c
    [ ] [c000200007383bd0] [c00000000069ad0c] pcibios_init+0xf0/0x104
    [ ] [c000200007383c50] [c0000000000106d8] do_one_initcall+0x84/0x1c4
    [ ] [c000200007383d20] [c0000000006910b8] kernel_init_freeable+0x264/0x268
    [ ] [c000200007383dc0] [c000000000010a68] kernel_init+0x18/0x138
    [ ] [c000200007383e20] [c00000000000cbfc] ret_from_kernel_thread+0x5c/0x80
    [ ] Instruction dump:
    [ ] 7f89e840 409d000c 7fbbf840 409c000c 38210090 4848f448 809c002c e95e0120
    [ ] 7ba91764 38a00003 57a7043e 38c00000 <7c8a492e> 5484043e e87e0018 4bff23bd
    
    Hitting the problem is not that easy. It was seen with a (semi-bogus)
    PCI device with a class code of 0. The generic PCI framework doesn't
    allocate resources in such a case.
    
    The patch is simply skipping resources which are still flagged with
    IORESOURCE_UNSET.
    
    We don't have the problem with 64-bit mem resources, as the address of
    the resource is checked to be within the range of the 64-bit mmio
    window. See pnv_ioda_reserve_dev_m64_pe() and pnv_pci_is_m64().
    
    Reported-by: Andrew Jeffery <andrew@aj.id.au>
    Fixes: 23e79425fe7c ("powerpc/powernv: Simplify pnv_ioda_setup_pe_seg()")
    Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230120093215.19496-1-fbarrat@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries/lpar: add missing RTAS retry status handling [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri Feb 10 12:41:51 2023 -0600

    powerpc/pseries/lpar: add missing RTAS retry status handling
    
    [ Upstream commit daa8ab59044610aa8ef2ee45a6c157b5e11635e9 ]
    
    The ibm,get-system-parameter RTAS function may return -2 or 990x,
    which indicate that the caller should try again.
    
    pseries_lpar_read_hblkrm_characteristics() ignores this, making it
    possible to incorrectly detect TLB block invalidation characteristics
    at boot.
    
    Move the RTAS call into a coventional rtas_busy_delay()-based loop.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Fixes: 1211ee61b4a8 ("powerpc/pseries: Read TLB Block Invalidate Characteristics")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-3-26929c8cce78@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries/lparcfg: add missing RTAS retry status handling [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri Feb 10 12:41:52 2023 -0600

    powerpc/pseries/lparcfg: add missing RTAS retry status handling
    
    [ Upstream commit 5d08633e5f6564b60f1cbe09af3af40a74d66431 ]
    
    The ibm,get-system-parameter RTAS function may return -2 or 990x,
    which indicate that the caller should try again.
    
    lparcfg's parse_system_parameter_string() ignores this, making it
    possible to intermittently report incorrect SPLPAR characteristics.
    
    Move the RTAS call into a coventional rtas_busy_delay()-based loop.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-4-26929c8cce78@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/rtas: ensure 4KB alignment for rtas_data_buf [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri Feb 10 12:41:54 2023 -0600

    powerpc/rtas: ensure 4KB alignment for rtas_data_buf
    
    [ Upstream commit 836b5b9fcc8e09cea7e8a59a070349a00e818308 ]
    
    Some RTAS functions that have work area parameters impose alignment
    requirements on the work area passed to them by the OS. Examples
    include:
    
    - ibm,configure-connector
    - ibm,update-nodes
    - ibm,update-properties
    
    4KB is the greatest alignment required by PAPR for such
    buffers. rtas_data_buf used to have a __page_aligned attribute in the
    arch/ppc64 days, but that was changed to __cacheline_aligned for
    unknown reasons by commit 033ef338b6e0 ("powerpc: Merge rtas.c into
    arch/powerpc/kernel"). That works out to 128-byte alignment
    on ppc64, which isn't right.
    
    This was found by inspection and I'm not aware of any real problems
    caused by this. Either current RTAS implementations don't enforce the
    alignment constraints, or rtas_data_buf is always being placed at a
    4KB boundary by accident (or both, perhaps).
    
    Use __aligned(SZ_4K) to ensure the rtas_data_buf has alignment
    appropriate for all users.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Fixes: 033ef338b6e0 ("powerpc: Merge rtas.c into arch/powerpc/kernel")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-6-26929c8cce78@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/rtas: make all exports GPL [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Tue Jan 24 08:04:46 2023 -0600

    powerpc/rtas: make all exports GPL
    
    [ Upstream commit 9bce6243848dfd0ff7c2be6e8d82ab9b1e6c7858 ]
    
    The first symbol exports of RTAS functions and data came with the (now
    removed) scanlog driver in 2003:
    
    https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=f92e361842d5251e50562b09664082dcbd0548bb
    
    At the time this was applied, EXPORT_SYMBOL_GPL() was very new, and
    the exports of rtas_call() etc have remained non-GPL. As new APIs have
    been added to the RTAS subsystem, their symbol exports have followed
    the convention set by existing code.
    
    However, the historical evidence is that RTAS function exports have been
    added over time only to satisfy the needs of in-kernel users, and these
    clients must have fairly intimate knowledge of how the APIs work to use
    them safely. No out of tree users are known, and future ones seem
    unlikely.
    
    Arguably the default for RTAS symbols should have become
    EXPORT_SYMBOL_GPL once it was available. Let's make it so now, and
    exceptions can be evaluated as needed.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Laurent Dufour <laurent.dufour@fr.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230124140448.45938-3-nathanl@linux.ibm.com
    Stable-dep-of: 836b5b9fcc8e ("powerpc/rtas: ensure 4KB alignment for rtas_data_buf")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8169: use new PM macros [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Jan 24 22:17:17 2022 +0100

    r8169: use new PM macros
    
    commit 8fe6e670640e79adbe6fff5438cd324e468c280e upstream.
    
    This is based on series [0] that extended the PM core. Now the compiler
    can see the PM callbacks also on systems not defining CONFIG_PM.
    The optimizer will remove the functions then in this case.
    
    [0] https://lore.kernel.org/netdev/20211207002102.26414-1-paul@crapouillou.net/
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/bnxt_re: Return error for SRQ resize [+ + +]
Author: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Date:   Mon Jan 22 20:54:36 2024 -0800

    RDMA/bnxt_re: Return error for SRQ resize
    
    [ Upstream commit 3687b450c5f32e80f179ce4b09e0454da1449eac ]
    
    SRQ resize is not supported in the driver. But driver is not
    returning error from bnxt_re_modify_srq() for SRQ resize.
    
    Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")
    Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1705985677-15551-5-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/irdma: Add AE for too many RNRS [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Jan 31 17:38:49 2024 -0600

    RDMA/irdma: Add AE for too many RNRS
    
    [ Upstream commit 630bdb6f28ca9e5ff79e244030170ac788478332 ]
    
    Add IRDMA_AE_LLP_TOO_MANY_RNRS to the list of AE's processed as an
    abnormal asyncronous event.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@gmail.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-5-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/irdma: Fix KASAN issue with tasklet [+ + +]
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Jan 31 17:38:46 2024 -0600

    RDMA/irdma: Fix KASAN issue with tasklet
    
    [ Upstream commit bd97cea7b18a0a553773af806dfbfac27a7c4acb ]
    
    KASAN testing revealed the following issue assocated with freeing an IRQ.
    
    [50006.466686] Call Trace:
    [50006.466691]  <IRQ>
    [50006.489538]  dump_stack+0x5c/0x80
    [50006.493475]  print_address_description.constprop.6+0x1a/0x150
    [50006.499872]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.505742]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.511644]  kasan_report.cold.11+0x7f/0x118
    [50006.516572]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.522473]  irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.528232]  irdma_process_ceq+0xb2/0x400 [irdma]
    [50006.533601]  ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]
    [50006.540298]  irdma_ceq_dpc+0x44/0x100 [irdma]
    [50006.545306]  tasklet_action_common.isra.14+0x148/0x2c0
    [50006.551096]  __do_softirq+0x1d0/0xaf8
    [50006.555396]  irq_exit_rcu+0x219/0x260
    [50006.559670]  irq_exit+0xa/0x20
    [50006.563320]  smp_apic_timer_interrupt+0x1bf/0x690
    [50006.568645]  apic_timer_interrupt+0xf/0x20
    [50006.573341]  </IRQ>
    
    The issue is that a tasklet could be pending on another core racing
    the delete of the irq.
    
    Fix by insuring any scheduled tasklet is killed after deleting the
    irq.
    
    Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions")
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-2-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/irdma: Set the CQ read threshold for GEN 1 [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Jan 31 17:38:48 2024 -0600

    RDMA/irdma: Set the CQ read threshold for GEN 1
    
    [ Upstream commit 666047f3ece9f991774c1fe9b223139a9ef8908d ]
    
    The CQ shadow read threshold is currently not set for GEN 2.  This could
    cause an invalid CQ overflow condition, so remove the GEN check that
    exclused GEN 1.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-4-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/irdma: Validate max_send_wr and max_recv_wr [+ + +]
Author: Shiraz Saleem <shiraz.saleem@intel.com>
Date:   Wed Jan 31 17:38:47 2024 -0600

    RDMA/irdma: Validate max_send_wr and max_recv_wr
    
    [ Upstream commit ee107186bcfd25d7873258f3f75440e20f5e6416 ]
    
    Validate that max_send_wr and max_recv_wr is within the
    supported range.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Change-Id: I2fc8b10292b641fddd20b36986a9dae90a93f4be
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-3-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/qedr: Fix qedr_create_user_qp error flow [+ + +]
Author: Kamal Heib <kheib@redhat.com>
Date:   Thu Feb 8 17:36:28 2024 -0500

    RDMA/qedr: Fix qedr_create_user_qp error flow
    
    [ Upstream commit 5ba4e6d5863c53e937f49932dee0ecb004c65928 ]
    
    Avoid the following warning by making sure to free the allocated
    resources in case that qedr_init_user_queue() fail.
    
    -----------[ cut here ]-----------
    WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
    ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
    CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
    Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
    RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
    RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
    RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
    RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
    RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
    R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
    R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
    FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
    Call Trace:
    <TASK>
    ? show_trace_log_lvl+0x1c4/0x2df
    ? show_trace_log_lvl+0x1c4/0x2df
    ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ? __warn+0x81/0x110
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ? report_bug+0x10a/0x140
    ? handle_bug+0x3c/0x70
    ? exc_invalid_op+0x14/0x70
    ? asm_exc_invalid_op+0x16/0x20
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
    __fput+0x94/0x250
    task_work_run+0x5c/0x90
    do_exit+0x270/0x4a0
    do_group_exit+0x2d/0x90
    get_signal+0x87c/0x8c0
    arch_do_signal_or_restart+0x25/0x100
    ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
    exit_to_user_mode_loop+0x9c/0x130
    exit_to_user_mode_prepare+0xb6/0x100
    syscall_exit_to_user_mode+0x12/0x40
    do_syscall_64+0x69/0x90
    ? syscall_exit_work+0x103/0x130
    ? syscall_exit_to_user_mode+0x22/0x40
    ? do_syscall_64+0x69/0x90
    ? syscall_exit_work+0x103/0x130
    ? syscall_exit_to_user_mode+0x22/0x40
    ? do_syscall_64+0x69/0x90
    ? do_syscall_64+0x69/0x90
    ? common_interrupt+0x43/0xa0
    entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x1470abe3ec6b
    Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
    RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
    RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
    RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
    R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
    R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
    </TASK>
    --[ end trace 888a9b92e04c5c97 ]--
    
    Fixes: df15856132bc ("RDMA/qedr: restructure functions that create/destroy QPs")
    Signed-off-by: Kamal Heib <kheib@redhat.com>
    Link: https://lore.kernel.org/r/20240208223628.2040841-1-kheib@redhat.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/siw: Balance the reference of cep->kref in the error path [+ + +]
Author: Guoqing Jiang <guoqing.jiang@linux.dev>
Date:   Mon Aug 21 21:32:53 2023 +0800

    RDMA/siw: Balance the reference of cep->kref in the error path
    
    [ Upstream commit b056327bee09e6b86683d3f709a438ccd6031d72 ]
    
    The siw_connect can go to err in below after cep is allocated successfully:
    
    1. If siw_cm_alloc_work returns failure. In this case socket is not
    assoicated with cep so siw_cep_put can't be called by siw_socket_disassoc.
    We need to call siw_cep_put twice since cep->kref is increased once after
    it was initialized.
    
    2. If siw_cm_queue_work can't find a work, which means siw_cep_get is not
    called in siw_cm_queue_work, so cep->kref is increased twice by siw_cep_get
    and when associate socket with cep after it was initialized. So we need to
    call siw_cep_put three times (one in siw_socket_disassoc).
    
    3. siw_send_mpareqrep returns error, this scenario is similar as 2.
    
    So we need to remove one siw_cep_put in the error path.
    
    Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Link: https://lore.kernel.org/r/20230821133255.31111-2-guoqing.jiang@linux.dev
    Acked-by: Bernard Metzler <bmt@zurich.ibm.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/siw: Correct wrong debug message [+ + +]
Author: Guoqing Jiang <guoqing.jiang@linux.dev>
Date:   Mon Aug 21 21:32:54 2023 +0800

    RDMA/siw: Correct wrong debug message
    
    [ Upstream commit bee024d20451e4ce04ea30099cad09f7f75d288b ]
    
    We need to print num_sle first then pbl->max_buf per the condition.
    Also replace mem->pbl with pbl while at it.
    
    Fixes: 303ae1cdfdf7 ("rdma/siw: application interface")
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Link: https://lore.kernel.org/r/20230821133255.31111-3-guoqing.jiang@linux.dev
    Acked-by: Bernard Metzler <bmt@zurich.ibm.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/srpt: fix function pointer cast warnings [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 13 11:07:13 2024 +0100

    RDMA/srpt: fix function pointer cast warnings
    
    [ Upstream commit eb5c7465c3240151cd42a55c7ace9da0026308a1 ]
    
    clang-16 notices that srpt_qp_event() gets called through an incompatible
    pointer here:
    
    drivers/infiniband/ulp/srpt/ib_srpt.c:1815:5: error: cast from 'void (*)(struct ib_event *, struct srpt_rdma_ch *)' to 'void (*)(struct ib_event *, void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1815 |                 = (void(*)(struct ib_event *, void*))srpt_qp_event;
    
    Change srpt_qp_event() to use the correct prototype and adjust the
    argument inside of it.
    
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240213100728.458348-1-arnd@kernel.org
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/srpt: Support specifying the srpt_service_guid parameter [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Sun Feb 4 16:42:07 2024 -0800

    RDMA/srpt: Support specifying the srpt_service_guid parameter
    
    [ Upstream commit fdfa083549de5d50ebf7f6811f33757781e838c0 ]
    
    Make loading ib_srpt with this parameter set work. The current behavior is
    that setting that parameter while loading the ib_srpt kernel module
    triggers the following kernel crash:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    Call Trace:
     <TASK>
     parse_one+0x18c/0x1d0
     parse_args+0xe1/0x230
     load_module+0x8de/0xa60
     init_module_from_file+0x8b/0xd0
     idempotent_init_module+0x181/0x240
     __x64_sys_finit_module+0x5a/0xb0
     do_syscall_64+0x5f/0xe0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Cc: LiHonggang <honggangli@163.com>
    Reported-by: LiHonggang <honggangli@163.com>
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240205004207.17031-1-bvanassche@acm.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: pwm-regulator: Add validity checks in continuous .get_voltage [+ + +]
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Jan 13 23:46:26 2024 +0100

    regulator: pwm-regulator: Add validity checks in continuous .get_voltage
    
    [ Upstream commit c92688cac239794e4a1d976afa5203a4d3a2ac0e ]
    
    Continuous regulators can be configured to operate only in a certain
    duty cycle range (for example from 0..91%). Add a check to error out if
    the duty cycle translates to an unsupported (or out of range) voltage.
    
    Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Link: https://msgid.link/r/20240113224628.377993-2-martin.blumenstingl@googlemail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "x86/alternative: Make custom return thunk unconditional" [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Thu Feb 22 15:50:48 2024 +0100

    Revert "x86/alternative: Make custom return thunk unconditional"
    
    This reverts commit 08f7cfd44f77b2796582bc26164fdef44dd33b6c.
    
    Revert the backport of upstream commit:
    
      095b8303f383 ("x86/alternative: Make custom return thunk unconditional")
    
    in order to backport the full version now that
    
      770ae1b70952 ("x86/returnthunk: Allow different return thunks")
    
    has been backported.
    
    Revert it here so that the build breakage is kept at minimum.
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "x86/ftrace: Use alternative RET encoding" [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Thu Feb 22 13:46:09 2024 +0100

    Revert "x86/ftrace: Use alternative RET encoding"
    
    This reverts commit 3eb602ad6a94a76941f93173131a71ad36fa1324.
    
    Revert the backport of upstream commit
    
      1f001e9da6bb ("x86/ftrace: Use alternative RET encoding")
    
    in favor of a proper backport after backporting the commit which adds
    __text_gen_insn().
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RISC-V: fix funct4 definition for c.jalr in parse_asm.h [+ + +]
Author: Heiko Stuebner <heiko@sntech.de>
Date:   Fri Dec 23 23:13:21 2022 +0100

    RISC-V: fix funct4 definition for c.jalr in parse_asm.h
    
    [ Upstream commit a3775634f6da23f5511d0282d7e792cf606e5f3b ]
    
    The opcode definition for c.jalr is
        c.jalr c_rs1_n0  1..0=2 15..13=4 12=1 6..2=0
    
    This means funct4 consisting of bit [15:12] is 1001b, so the value is 0x9.
    
    Fixes: edde5584c7ab ("riscv: Add SW single-step support for KDB")
    Reported-by: Andrew Jones <ajones@ventanamicro.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
    Link: https://lore.kernel.org/r/20221223221332.4127602-2-heiko@sntech.de
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390: use the correct count for __iowrite64_copy() [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Fri Feb 16 20:48:14 2024 -0400

    s390: use the correct count for __iowrite64_copy()
    
    [ Upstream commit 723a2cc8d69d4342b47dfddbfe6c19f1b135f09b ]
    
    The signature for __iowrite64_copy() requires the number of 64 bit
    quantities, not bytes. Multiple by 8 to get to a byte length before
    invoking zpci_memcpy_toio()
    
    Fixes: 87bc359b9822 ("s390/pci: speed up __iowrite64_copy by using pci store block insn")
    Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/0-v1-9223d11a7662+1d7785-s390_iowrite64_jgg@nvidia.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/fair: Don't balance task to its current running CPU [+ + +]
Author: Yicong Yang <yangyicong@hisilicon.com>
Date:   Tue May 30 16:25:07 2023 +0800

    sched/fair: Don't balance task to its current running CPU
    
    [ Upstream commit 0dd37d6dd33a9c23351e6115ae8cdac7863bc7de ]
    
    We've run into the case that the balancer tries to balance a migration
    disabled task and trigger the warning in set_task_cpu() like below:
    
     ------------[ cut here ]------------
     WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240
     Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip>
     CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G           O       6.1.0-rc4+ #1
     Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021
     pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : set_task_cpu+0x188/0x240
     lr : load_balance+0x5d0/0xc60
     sp : ffff80000803bc70
     x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040
     x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001
     x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78
     x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000
     x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000
     x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000
     x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530
     x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e
     x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a
     x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001
     Call trace:
      set_task_cpu+0x188/0x240
      load_balance+0x5d0/0xc60
      rebalance_domains+0x26c/0x380
      _nohz_idle_balance.isra.0+0x1e0/0x370
      run_rebalance_domains+0x6c/0x80
      __do_softirq+0x128/0x3d8
      ____do_softirq+0x18/0x24
      call_on_irq_stack+0x2c/0x38
      do_softirq_own_stack+0x24/0x3c
      __irq_exit_rcu+0xcc/0xf4
      irq_exit_rcu+0x18/0x24
      el1_interrupt+0x4c/0xe4
      el1h_64_irq_handler+0x18/0x2c
      el1h_64_irq+0x74/0x78
      arch_cpu_idle+0x18/0x4c
      default_idle_call+0x58/0x194
      do_idle+0x244/0x2b0
      cpu_startup_entry+0x30/0x3c
      secondary_start_kernel+0x14c/0x190
      __secondary_switched+0xb0/0xb4
     ---[ end trace 0000000000000000 ]---
    
    Further investigation shows that the warning is superfluous, the migration
    disabled task is just going to be migrated to its current running CPU.
    This is because that on load balance if the dst_cpu is not allowed by the
    task, we'll re-select a new_dst_cpu as a candidate. If no task can be
    balanced to dst_cpu we'll try to balance the task to the new_dst_cpu
    instead. In this case when the migration disabled task is not on CPU it
    only allows to run on its current CPU, load balance will select its
    current CPU as new_dst_cpu and later triggers the warning above.
    
    The new_dst_cpu is chosen from the env->dst_grpmask. Currently it
    contains CPUs in sched_group_span() and if we have overlapped groups it's
    possible to run into this case. This patch makes env->dst_grpmask of
    group_balance_mask() which exclude any CPUs from the busiest group and
    solve the issue. For balancing in a domain with no overlapped groups
    the behaviour keeps same as before.
    
    Suggested-by: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20230530082507.10444-1-yangyicong@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/rt: Disallow writing invalid values to sched_rt_period_us [+ + +]
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Mon Oct 2 13:55:51 2023 +0200

    sched/rt: Disallow writing invalid values to sched_rt_period_us
    
    commit 079be8fc630943d9fc70a97807feb73d169ee3fc upstream.
    
    The validation of the value written to sched_rt_period_us was broken
    because:
    
      - the sysclt_sched_rt_period is declared as unsigned int
      - parsed by proc_do_intvec()
      - the range is asserted after the value parsed by proc_do_intvec()
    
    Because of this negative values written to the file were written into a
    unsigned integer that were later on interpreted as large positive
    integers which did passed the check:
    
      if (sysclt_sched_rt_period <= 0)
            return EINVAL;
    
    This commit fixes the parsing by setting explicit range for both
    perid_us and runtime_us into the sched_rt_sysctls table and processes
    the values with proc_dointvec_minmax() instead.
    
    Alternatively if we wanted to use full range of unsigned int for the
    period value we would have to split the proc_handler and use
    proc_douintvec() for it however even the
    Documentation/scheduller/sched-rt-group.rst describes the range as 1 to
    INT_MAX.
    
    As far as I can tell the only problem this causes is that the sysctl
    file allows writing negative values which when read back may confuse
    userspace.
    
    There is also a LTP test being submitted for these sysctl files at:
    
      http://patchwork.ozlabs.org/project/ltp/patch/20230901144433.2526-1-chrubis@suse.cz/
    
    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20231002115553.3007-2-chrubis@suse.cz
    [ pvorel: rebased for 5.15, 5.10 ]
    Reviewed-by: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sched/rt: Fix sysctl_sched_rr_timeslice intial value [+ + +]
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Wed Aug 2 17:19:05 2023 +0200

    sched/rt: Fix sysctl_sched_rr_timeslice intial value
    
    commit c7fcb99877f9f542c918509b2801065adcaf46fa upstream.
    
    There is a 10% rounding error in the intial value of the
    sysctl_sched_rr_timeslice with CONFIG_HZ_300=y.
    
    This was found with LTP test sched_rr_get_interval01:
    
    sched_rr_get_interval01.c:57: TPASS: sched_rr_get_interval() passed
    sched_rr_get_interval01.c:64: TPASS: Time quantum 0s 99999990ns
    sched_rr_get_interval01.c:72: TFAIL: /proc/sys/kernel/sched_rr_timeslice_ms != 100 got 90
    sched_rr_get_interval01.c:57: TPASS: sched_rr_get_interval() passed
    sched_rr_get_interval01.c:64: TPASS: Time quantum 0s 99999990ns
    sched_rr_get_interval01.c:72: TFAIL: /proc/sys/kernel/sched_rr_timeslice_ms != 100 got 90
    
    What this test does is to compare the return value from the
    sched_rr_get_interval() and the sched_rr_timeslice_ms sysctl file and
    fails if they do not match.
    
    The problem it found is the intial sysctl file value which was computed as:
    
    static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
    
    which works fine as long as MSEC_PER_SEC is multiple of HZ, however it
    introduces 10% rounding error for CONFIG_HZ_300:
    
    (MSEC_PER_SEC / HZ) * (100 * HZ / 1000)
    
    (1000 / 300) * (100 * 300 / 1000)
    
    3 * 30 = 90
    
    This can be easily fixed by reversing the order of the multiplication
    and division. After this fix we get:
    
    (MSEC_PER_SEC * (100 * HZ / 1000)) / HZ
    
    (1000 * (100 * 300 / 1000)) / 300
    
    (1000 * 30) / 300 = 100
    
    Fixes: 975e155ed873 ("sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds")
    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Petr Vorel <pvorel@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Tested-by: Petr Vorel <pvorel@suse.cz>
    Link: https://lore.kernel.org/r/20230802151906.25258-2-chrubis@suse.cz
    [ pvorel: rebased for 5.15, 5.10 ]
    Signed-off-by: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sched/rt: sysctl_sched_rr_timeslice show default timeslice after reset [+ + +]
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Wed Aug 2 17:19:06 2023 +0200

    sched/rt: sysctl_sched_rr_timeslice show default timeslice after reset
    
    commit c1fc6484e1fb7cc2481d169bfef129a1b0676abe upstream.
    
    The sched_rr_timeslice can be reset to default by writing value that is
    <= 0. However after reading from this file we always got the last value
    written, which is not useful at all.
    
    $ echo -1 > /proc/sys/kernel/sched_rr_timeslice_ms
    $ cat /proc/sys/kernel/sched_rr_timeslice_ms
    -1
    
    Fix this by setting the variable that holds the sysctl file value to the
    jiffies_to_msecs(RR_TIMESLICE) in case that <= 0 value was written.
    
    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Petr Vorel <pvorel@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Tested-by: Petr Vorel <pvorel@suse.cz>
    Cc: Mahmoud Adam <mngyadam@amazon.com>
    Link: https://lore.kernel.org/r/20230802151906.25258-3-chrubis@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scsi: jazz_esp: Only build if SCSI core is builtin [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Feb 13 21:59:53 2024 -0800

    scsi: jazz_esp: Only build if SCSI core is builtin
    
    [ Upstream commit 9ddf190a7df77b77817f955fdb9c2ae9d1c9c9a3 ]
    
    JAZZ_ESP is a bool kconfig symbol that selects SCSI_SPI_ATTRS.  When
    CONFIG_SCSI=m, this results in SCSI_SPI_ATTRS=m while JAZZ_ESP=y, which
    causes many undefined symbol linker errors.
    
    Fix this by only offering to build this driver when CONFIG_SCSI=y.
    
    [mkp: JAZZ_ESP is unique in that it does not support being compiled as a
    module unlike the remaining SPI SCSI HBA drivers]
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20240214055953.9612-1-rdunlap@infradead.org
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Nicolas Schier <nicolas@fjasle.eu>
    Cc: James E.J. Bottomley <jejb@linux.ibm.com>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: linux-scsi@vger.kernel.org
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202402112222.Gl0udKyU-lkp@intel.com/
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Use unsigned type for num_sge [+ + +]
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Dec 20 17:26:58 2023 +0100

    scsi: lpfc: Use unsigned type for num_sge
    
    [ Upstream commit d6c1b19153f92e95e5e1801d540e98771053afae ]
    
    LUNs going into "failed ready running" state observed on >1T and on even
    numbers of size (2T, 4T, 6T, 8T and 10T). The issue occurs when DIF is
    enabled at the host.
    
    The kernel logs:
    
      Cannot setup S/G List for HBAIO segs 1/1 SGL 512 SCSI 256: 3 0
    
    The host lpfc driver is failing to setup scatter/gather list (protection
    data) for the I/Os.
    
    The return type lpfc_bg_setup_sgl()/lpfc_bg_setup_sgl_prot() causes the
    compiler to remove the most significant bit. Use an unsigned type instead.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    [dwagner: added commit message]
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Link: https://lore.kernel.org/r/20231220162658.12392-1-dwagner@suse.de
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: target: core: Add TMF to tmr_list handling [+ + +]
Author: Dmitry Bogdanov <d.bogdanov@yadro.com>
Date:   Thu Jan 11 15:59:41 2024 +0300

    scsi: target: core: Add TMF to tmr_list handling
    
    [ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ]
    
    An abort that is responded to by iSCSI itself is added to tmr_list but does
    not go to target core. A LUN_RESET that goes through tmr_list takes a
    refcounter on the abort and waits for completion. However, the abort will
    be never complete because it was not started in target core.
    
     Unable to locate ITT: 0x05000000 on CID: 0
     Unable to locate RefTaskTag: 0x05000000 on CID: 0.
     wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
     wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
    ...
     INFO: task kworker/0:2:49 blocked for more than 491 seconds.
     task:kworker/0:2     state:D stack:    0 pid:   49 ppid:     2 flags:0x00000800
     Workqueue: events target_tmr_work [target_core_mod]
    Call Trace:
     __switch_to+0x2c4/0x470
     _schedule+0x314/0x1730
     schedule+0x64/0x130
     schedule_timeout+0x168/0x430
     wait_for_completion+0x140/0x270
     target_put_cmd_and_wait+0x64/0xb0 [target_core_mod]
     core_tmr_lun_reset+0x30/0xa0 [target_core_mod]
     target_tmr_work+0xc8/0x1b0 [target_core_mod]
     process_one_work+0x2d4/0x5d0
     worker_thread+0x78/0x6c0
    
    To fix this, only add abort to tmr_list if it will be handled by target
    core.
    
    Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
    Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: net: vrf-xfrm-tests: change authentication and encryption algos [+ + +]
Author: Magali Lemes <magali.lemes@canonical.com>
Date:   Tue Jun 13 09:32:21 2023 -0300

    selftests: net: vrf-xfrm-tests: change authentication and encryption algos
    
    [ Upstream commit cb43c60e64ca67fcc9d23bd08f51d2ab8209d9d7 ]
    
    The vrf-xfrm-tests tests use the hmac(md5) and cbc(des3_ede)
    algorithms for performing authentication and encryption, respectively.
    This causes the tests to fail when fips=1 is set, since these algorithms
    are not allowed in FIPS mode. Therefore, switch from hmac(md5) and
    cbc(des3_ede) to hmac(sha1) and cbc(aes), which are FIPS compliant.
    
    Fixes: 3f251d741150 ("selftests: Add tests for vrf and xfrms")
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Magali Lemes <magali.lemes@canonical.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250: Remove serial_rs485 sanitization from em485 [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jun 6 13:04:33 2022 +0300

    serial: 8250: Remove serial_rs485 sanitization from em485
    
    [ Upstream commit 84f2faa7852e1f55d89bb0c99b3a672b87b11f87 ]
    
    Serial core handles serial_rs485 sanitization.
    
    When em485 init fails, there are two possible paths of entry:
    
      1) uart_rs485_config (init path) that fully clears port->rs485 on
         error.
    
      2) ioctl path with a pre-existing, valid port->rs485 unto which the
         kernel falls back on error and port->rs485 should therefore be
         kept untouched. The temporary rs485 struct is not returned to
         userspace in case of error so its flag don't matter.
    
    ...Thus SER_RS485_ENABLED clearing on error can/should be dropped.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220606100433.13793-37-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: amba-pl011: Fix DMA transmission in RS485 mode [+ + +]
Author: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Date:   Fri Feb 16 23:47:08 2024 +0100

    serial: amba-pl011: Fix DMA transmission in RS485 mode
    
    commit 3b69e32e151bc4a4e3c785cbdb1f918d5ee337ed upstream.
    
    When DMA is used in RS485 mode make sure that the UARTs tx section is
    enabled before the DMA buffers are queued for transmission.
    
    Cc: stable@vger.kernel.org
    Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support")
    Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
    Link: https://lore.kernel.org/r/20240216224709.9928-2-l.sanfilippo@kunbus.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb: client: fix OOB in receive_encrypted_standard() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Mon Feb 12 02:23:11 2024 +0530

    smb: client: fix OOB in receive_encrypted_standard()
    
    [ Upstream commit eec04ea119691e65227a97ce53c0da6b9b74b0b7 ]
    
    Fix potential OOB in receive_encrypted_standard() if server returned a
    large shdr->NextCommand that would end up writing off the end of
    @next_buffer.
    
    Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses")
    Cc: stable@vger.kernel.org
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [Guru: receive_encrypted_standard() is present in file smb2ops.c,
    smb2ops.c file location is changed, modified patch accordingly.]
    Signed-off-by: Guruswamy Basavaiah <guruswamy.basavaiah@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb: client: fix parsing of SMB3.1.1 POSIX create context [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Mon Feb 12 02:23:13 2024 +0530

    smb: client: fix parsing of SMB3.1.1 POSIX create context
    
    [ Upstream commit 76025cc2285d9ede3d717fe4305d66f8be2d9346 ]
    
    The data offset for the SMB3.1.1 POSIX create context will always be
    8-byte aligned so having the check 'noff + nlen >= doff' in
    smb2_parse_contexts() is wrong as it will lead to -EINVAL because noff
    + nlen == doff.
    
    Fix the sanity check to correctly handle aligned create context data.
    
    Fixes: af1689a9b770 ("smb: client: fix potential OOBs in smb2_parse_contexts()")
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [Guru:smb2_parse_contexts()  is present in file smb2ops.c,
    smb2ops.c file location is changed, modified patch accordingly.]
    Signed-off-by: Guruswamy Basavaiah <guruswamy.basavaiah@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb: client: fix potential OOBs in smb2_parse_contexts() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Mon Feb 12 02:23:12 2024 +0530

    smb: client: fix potential OOBs in smb2_parse_contexts()
    
    [ Upstream commit af1689a9b7701d9907dfc84d2a4b57c4bc907144 ]
    
    Validate offsets and lengths before dereferencing create contexts in
    smb2_parse_contexts().
    
    This fixes following oops when accessing invalid create contexts from
    server:
    
      BUG: unable to handle page fault for address: ffff8881178d8cc3
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 4a01067 P4D 4a01067 PUD 0
      Oops: 0000 [#1] PREEMPT SMP NOPTI
      CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
      RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
      Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
      00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7
      7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
      RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
      RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
      RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
      RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
      R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
      R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
      FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
      PKRU: 55555554
      Call Trace:
       <TASK>
       ? __die+0x23/0x70
       ? page_fault_oops+0x181/0x480
       ? search_module_extables+0x19/0x60
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? exc_page_fault+0x1b6/0x1c0
       ? asm_exc_page_fault+0x26/0x30
       ? smb2_parse_contexts+0xa0/0x3a0 [cifs]
       SMB2_open+0x38d/0x5f0 [cifs]
       ? smb2_is_path_accessible+0x138/0x260 [cifs]
       smb2_is_path_accessible+0x138/0x260 [cifs]
       cifs_is_path_remote+0x8d/0x230 [cifs]
       cifs_mount+0x7e/0x350 [cifs]
       cifs_smb3_do_mount+0x128/0x780 [cifs]
       smb3_get_tree+0xd9/0x290 [cifs]
       vfs_get_tree+0x2c/0x100
       ? capable+0x37/0x70
       path_mount+0x2d7/0xb80
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? _raw_spin_unlock_irqrestore+0x44/0x60
       __x64_sys_mount+0x11a/0x150
       do_syscall_64+0x47/0xf0
       entry_SYSCALL_64_after_hwframe+0x6f/0x77
      RIP: 0033:0x7f8737657b1e
    
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [Guru: Removed changes to cached_dir.c and checking return value
    of smb2_parse_contexts in smb2ops.c]
    Signed-off-by: Guruswamy Basavaiah <guruswamy.basavaiah@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected [+ + +]
Author: Devyn Liu <liudingyuan@huawei.com>
Date:   Tue Jan 23 15:11:49 2024 +0800

    spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
    
    [ Upstream commit de8b6e1c231a95abf95ad097b993d34b31458ec9 ]
    
    Return IRQ_NONE from the interrupt handler when no interrupt was
    detected. Because an empty interrupt will cause a null pointer error:
    
        Unable to handle kernel NULL pointer dereference at virtual
      address 0000000000000008
        Call trace:
            complete+0x54/0x100
            hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
            __handle_irq_event_percpu+0x64/0x1e0
            handle_irq_event+0x7c/0x1cc
    
    Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
    Link: https://msgid.link/r/20240123071149.917678-1-liudingyuan@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: sh-msiof: avoid integer overflow in constants [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Tue Jan 30 10:40:53 2024 +0100

    spi: sh-msiof: avoid integer overflow in constants
    
    [ Upstream commit 6500ad28fd5d67d5ca0fee9da73c463090842440 ]
    
    cppcheck rightfully warned:
    
     drivers/spi/spi-sh-msiof.c:792:28: warning: Signed integer overflow for expression '7<<29'. [integerOverflow]
     sh_msiof_write(p, SIFCTR, SIFCTR_TFWM_1 | SIFCTR_RFWM_1);
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://msgid.link/r/20240130094053.10672-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tls: rx: drop pointless else after goto [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Apr 7 20:38:15 2022 -0700

    tls: rx: drop pointless else after goto
    
    [ Upstream commit d5123edd10cf9d324fcb88e276bdc7375f3c5321 ]
    
    Pointless else branch after goto makes the code harder to refactor
    down the line.
    
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: fdfbaec5923d ("tls: stop recv() if initial process_rx_list gave us non-DATA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tls: rx: jump to a more appropriate label [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Apr 7 20:38:14 2022 -0700

    tls: rx: jump to a more appropriate label
    
    [ Upstream commit bfc06e1aaa130b86a81ce3c41ec71a2f5e191690 ]
    
    'recv_end:' checks num_async and decrypted, and is then followed
    by the 'end' label. Since we know that decrypted and num_async
    are 0 at the start we can jump to 'end'.
    
    Move the init of decrypted and num_async to let the compiler
    catch if I'm wrong.
    
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: fdfbaec5923d ("tls: stop recv() if initial process_rx_list gave us non-DATA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tls: stop recv() if initial process_rx_list gave us non-DATA [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Feb 15 17:17:30 2024 +0100

    tls: stop recv() if initial process_rx_list gave us non-DATA
    
    [ Upstream commit fdfbaec5923d9359698cbb286bc0deadbb717504 ]
    
    If we have a non-DATA record on the rx_list and another record of the
    same type still on the queue, we will end up merging them:
     - process_rx_list copies the non-DATA record
     - we start the loop and process the first available record since it's
       of the same type
     - we break out of the loop since the record was not DATA
    
    Just check the record type and jump to the end in case process_rx_list
    did some work.
    
    Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/bd31449e43bd4b6ff546f5c51cf958c31c511deb.1708007371.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools headers UAPI: Sync linux/fscrypt.h with the kernel sources [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Dec 17 14:58:51 2020 -0300

    tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
    
    [ Upstream commit fabe0c61d842637b722344bcd49bfb1b76e2cc68 ]
    
    To pick the changes from:
    
      6b2a51ff03bf0c54 ("fscrypt: Add HCTR2 support for filename encryption")
    
    That don't result in any changes in tooling, just causes this to be
    rebuilt:
    
      CC      /tmp/build/perf-urgent/trace/beauty/sync_file_range.o
      LD      /tmp/build/perf-urgent/trace/beauty/perf-in.o
    
    addressing this perf build warning:
    
      Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h'
      diff -u tools/include/uapi/linux/fscrypt.h include/uapi/linux/fscrypt.h
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Nathan Huckleberry <nhuck@google.com>
    Link: https://lore.kernel.org/lkml/Yvzl8C7O1b+hf9GS@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools/virtio: fix build [+ + +]
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Tue Jul 5 09:22:49 2022 +0200

    tools/virtio: fix build
    
    [ Upstream commit d650f830f38b19039958f3f4504ceeb2b5922da7 ]
    
    Fix the build caused by the following changes:
    - phys_addr_t is now defined in tools/include/linux/types.h
    - dev_warn_once() is used in drivers/virtio/virtio_ring.c
    - linux/uio.h included by vringh.h use INT_MAX defined in limits.h
    
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Message-Id: <20220705072249.7867-1-sgarzare@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: cdns3: fix memory double free when handle zero packet [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Feb 2 10:42:17 2024 -0500

    usb: cdns3: fix memory double free when handle zero packet
    
    commit 5fd9e45f1ebcd57181358af28506e8a661a260b3 upstream.
    
    829  if (request->complete) {
    830          spin_unlock(&priv_dev->lock);
    831          usb_gadget_giveback_request(&priv_ep->endpoint,
    832                                    request);
    833          spin_lock(&priv_dev->lock);
    834  }
    835
    836  if (request->buf == priv_dev->zlp_buf)
    837      cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
    
    Driver append an additional zero packet request when queue a packet, which
    length mod max packet size is 0. When transfer complete, run to line 831,
    usb_gadget_giveback_request() will free this requestion. 836 condition is
    true, so cdns3_gadget_ep_free_request() free this request again.
    
    Log:
    
    [ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
    [ 1920.140696][  T150]
    [ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):
    [ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
    [ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]
    
    Add check at line 829, skip call usb_gadget_giveback_request() if it is
    additional zero length packet request. Needn't call
    usb_gadget_giveback_request() because it is allocated in this driver.
    
    Cc: stable@vger.kernel.org
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Roger Quadros <rogerq@kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20240202154217.661867-2-Frank.Li@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Feb 2 10:42:16 2024 -0500

    usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()
    
    commit cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6 upstream.
    
      ...
      cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);
      list_del_init(&priv_req->list);
      ...
    
    'priv_req' actually free at cdns3_gadget_ep_free_request(). But
    list_del_init() use priv_req->list after it.
    
    [ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4
    [ 1542.642868][  T534]
    [ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):
    [ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4
    [ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]
    [ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4
    [ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8
    [ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368
    [ 1542.685478][  T534]  ffs_func_disable+0x18/0x28
    
    Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this
    problem.
    
    Cc: stable@vger.kernel.org
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Roger Quadros <rogerq@kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20240202154217.661867-1-Frank.Li@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdnsp: blocked some cdns3 specific code [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Tue Feb 6 11:40:18 2024 +0100

    usb: cdnsp: blocked some cdns3 specific code
    
    commit 18a6be674306c9acb05c08e5c3fd376ef50a917c upstream.
    
    host.c file has some parts of code that were introduced for CDNS3 driver
    and should not be used with CDNSP driver.
    This patch blocks using these parts of codes by CDNSP driver.
    These elements include:
    - xhci_plat_cdns3_xhci object
    - cdns3 specific XECP_PORT_CAP_REG register
    - cdns3 specific XECP_AUX_CTRL_REG1 register
    
    cc: stable@vger.kernel.org
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/20240206104018.48272-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdnsp: fixed issue with incorrect detecting CDNSP family controllers [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Thu Feb 15 13:16:09 2024 +0100

    usb: cdnsp: fixed issue with incorrect detecting CDNSP family controllers
    
    commit 47625b018c6bc788bc10dd654c82696eb0a5ef11 upstream.
    
    Cadence have several controllers from 0x000403xx family but current
    driver suuport detecting only one with DID equal 0x0004034E.
    It causes that if someone uses different CDNSP controller then driver
    will use incorrect version and register space.
    Patch fix this issue.
    
    cc: stable@vger.kernel.org
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/20240215121609.259772-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: Don't disconnect if not started [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Fri Feb 16 00:41:02 2024 +0000

    usb: dwc3: gadget: Don't disconnect if not started
    
    commit b191a18cb5c47109ca696370a74a5062a70adfd0 upstream.
    
    Don't go through soft-disconnection sequence if the controller hasn't
    started. Otherwise, there will be timeout and warning reports from the
    soft-disconnection flow.
    
    Cc: stable@vger.kernel.org
    Fixes: 61a348857e86 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend")
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Closes: https://lore.kernel.org/linux-usb/20240215233536.7yejlj3zzkl23vjd@synopsys.com/T/#mb0661cd5f9272602af390c18392b9a36da4f96e6
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/e3be9b929934e0680a6f4b8f6eb11b18ae9c7e07.1708043922.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs [+ + +]
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Mon Feb 5 13:16:50 2024 +0530

    usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
    
    commit 76c51146820c5dac629f21deafab0a7039bc3ccd upstream.
    
    It is observed sometimes when tethering is used over NCM with Windows 11
    as host, at some instances, the gadget_giveback has one byte appended at
    the end of a proper NTB. When the NTB is parsed, unwrap call looks for
    any leftover bytes in SKB provided by u_ether and if there are any pending
    bytes, it treats them as a separate NTB and parses it. But in case the
    second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
    were parsed properly in the first NTB and saved in rx_list are dropped.
    
    Adding a few custom traces showed the following:
    [002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:
    req 000000003868811a length 1025/16384 zsI ==> 0
    [002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
    [002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
    [002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
    [002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
    [002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
    [002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
    
    In this case, the giveback is of 1025 bytes and block length is 1024.
    The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
    all datagrams in rx_list.
    
    Same is case with packets of size 2048:
    [002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:
    req 0000000011dfd96e length 2049/16384 zsI ==> 0
    [002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
    [002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
    
    Lecroy shows one byte coming in extra confirming that the byte is coming
    in from PC:
    
     Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590)
     - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
     --- Packet 4063861
           Data(1024 bytes)
           Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
     --- Packet 4063863
           Data(1 byte)
           Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
    
    According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
    because the non-zero wBlockLength has already told the function side the
    size of transfer to be expected. However, there are in-market NCM devices
    that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
    To deal with such devices, it pads an extra 0 at end so the transfer is no
    longer multiple of wMaxPacketSize.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Link: https://lore.kernel.org/r/20240205074650.200304-1-quic_kriskura@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: roles: don't get/set_role() when usb_role_switch is unregistered [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Mon Jan 29 17:37:39 2024 +0800

    usb: roles: don't get/set_role() when usb_role_switch is unregistered
    
    commit b787a3e781759026a6212736ef8e52cf83d1821a upstream.
    
    There is a possibility that usb_role_switch device is unregistered before
    the user put usb_role_switch. In this case, the user may still want to
    get/set_role() since the user can't sense the changes of usb_role_switch.
    
    This will add a flag to show if usb_role_switch is already registered and
    avoid unwanted behaviors.
    
    Fixes: fde0aa6c175a ("usb: common: Small class for USB role switches")
    cc: stable@vger.kernel.org
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240129093739.2371530-2-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: roles: fix NULL pointer issue when put module's reference [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Mon Jan 29 17:37:38 2024 +0800

    usb: roles: fix NULL pointer issue when put module's reference
    
    commit 1c9be13846c0b2abc2480602f8ef421360e1ad9e upstream.
    
    In current design, usb role class driver will get usb_role_switch parent's
    module reference after the user get usb_role_switch device and put the
    reference after the user put the usb_role_switch device. However, the
    parent device of usb_role_switch may be removed before the user put the
    usb_role_switch. If so, then, NULL pointer issue will be met when the user
    put the parent module's reference.
    
    This will save the module pointer in structure of usb_role_switch. Then,
    we don't need to find module by iterating long relations.
    
    Fixes: 5c54fcac9a9d ("usb: roles: Take care of driver module reference counting")
    cc: stable@vger.kernel.org
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240129093739.2371530-1-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
userfaultfd: fix mmap_changing checking in mfill_atomic_hugetlb [+ + +]
Author: Lokesh Gidra <lokeshgidra@google.com>
Date:   Wed Jan 17 14:37:29 2024 -0800

    userfaultfd: fix mmap_changing checking in mfill_atomic_hugetlb
    
    commit 67695f18d55924b2013534ef3bdc363bc9e14605 upstream.
    
    In mfill_atomic_hugetlb(), mmap_changing isn't being checked
    again if we drop mmap_lock and reacquire it. When the lock is not held,
    mmap_changing could have been incremented. This is also inconsistent
    with the behavior in mfill_atomic().
    
    Link: https://lkml.kernel.org/r/20240117223729.1444522-1-lokeshgidra@google.com
    Fixes: df2cc96e77011 ("userfaultfd: prevent non-cooperative events vs mcopy_atomic races")
    Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Brian Geffon <bgeffon@google.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Kalesh Singh <kaleshsingh@google.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Nicolas Geoffray <ngeoffray@google.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vdpa/mlx5: Don't clear mr struct on destroy MR [+ + +]
Author: Eli Cohen <elic@nvidia.com>
Date:   Mon Feb 6 14:19:56 2023 +0200

    vdpa/mlx5: Don't clear mr struct on destroy MR
    
    [ Upstream commit aef24311bd2d8a6d39a80c34f278b0fd1692aed3 ]
    
    Clearing the mr struct erases the lock owner and causes warnings to be
    emitted. It is not required to clear the mr so remove the memset call.
    
    Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code")
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Message-Id: <20230206121956.1149356-1-elic@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio-blk: Ensure no requests in virtqueues before deleting vqs. [+ + +]
Author: Yi Sun <yi.sun@unisoc.com>
Date:   Mon Jan 29 16:52:50 2024 +0800

    virtio-blk: Ensure no requests in virtqueues before deleting vqs.
    
    [ Upstream commit 4ce6e2db00de8103a0687fb0f65fd17124a51aaa ]
    
    Ensure no remaining requests in virtqueues before resetting vdev and
    deleting virtqueues. Otherwise these requests will never be completed.
    It may cause the system to become unresponsive.
    
    Function blk_mq_quiesce_queue() can ensure that requests have become
    in_flight status, but it cannot guarantee that requests have been
    processed by the device. Virtqueues should never be deleted before
    all requests become complete status.
    
    Function blk_mq_freeze_queue() ensure that all requests in virtqueues
    become complete status. And no requests can enter in virtqueues.
    
    Signed-off-by: Yi Sun <yi.sun@unisoc.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Link: https://lore.kernel.org/r/20240129085250.1550594-1-yi.sun@unisoc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ath11k: fix registration of 6Ghz-only phy without the full channel range [+ + +]
Author: Maxime Bizon <mbizon@freebox.fr>
Date:   Fri Apr 21 16:54:45 2023 +0200

    wifi: ath11k: fix registration of 6Ghz-only phy without the full channel range
    
    [ Upstream commit e2ceb1de2f83aafd8003f0b72dfd4b7441e97d14 ]
    
    Because of what seems to be a typo, a 6Ghz-only phy for which the BDF
    does not allow the 7115Mhz channel will fail to register:
    
      WARNING: CPU: 2 PID: 106 at net/wireless/core.c:907 wiphy_register+0x914/0x954
      Modules linked in: ath11k_pci sbsa_gwdt
      CPU: 2 PID: 106 Comm: kworker/u8:5 Not tainted 6.3.0-rc7-next-20230418-00549-g1e096a17625a-dirty #9
      Hardware name: Freebox V7R Board (DT)
      Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work
      pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : wiphy_register+0x914/0x954
      lr : ieee80211_register_hw+0x67c/0xc10
      sp : ffffff800b123aa0
      x29: ffffff800b123aa0 x28: 0000000000000000 x27: 0000000000000000
      x26: 0000000000000000 x25: 0000000000000006 x24: ffffffc008d51418
      x23: ffffffc008cb0838 x22: ffffff80176c2460 x21: 0000000000000168
      x20: ffffff80176c0000 x19: ffffff80176c03e0 x18: 0000000000000014
      x17: 00000000cbef338c x16: 00000000d2a26f21 x15: 00000000ad6bb85f
      x14: 0000000000000020 x13: 0000000000000020 x12: 00000000ffffffbd
      x11: 0000000000000208 x10: 00000000fffffdf7 x9 : ffffffc009394718
      x8 : ffffff80176c0528 x7 : 000000007fffffff x6 : 0000000000000006
      x5 : 0000000000000005 x4 : ffffff800b304284 x3 : ffffff800b304284
      x2 : ffffff800b304d98 x1 : 0000000000000000 x0 : 0000000000000000
      Call trace:
       wiphy_register+0x914/0x954
       ieee80211_register_hw+0x67c/0xc10
       ath11k_mac_register+0x7c4/0xe10
       ath11k_core_qmi_firmware_ready+0x1f4/0x570
       ath11k_qmi_driver_event_work+0x198/0x590
       process_one_work+0x1b8/0x328
       worker_thread+0x6c/0x414
       kthread+0x100/0x104
       ret_from_fork+0x10/0x20
      ---[ end trace 0000000000000000 ]---
      ath11k_pci 0002:01:00.0: ieee80211 registration failed: -22
      ath11k_pci 0002:01:00.0: failed register the radio with mac80211: -22
      ath11k_pci 0002:01:00.0: failed to create pdev core: -22
    
    Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20230421145445.2612280-1-mbizon@freebox.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: fix missing interfaces when dumping [+ + +]
Author: Michal Kazior <michal@plume.com>
Date:   Tue Jan 16 14:22:57 2024 +0000

    wifi: cfg80211: fix missing interfaces when dumping
    
    [ Upstream commit a6e4f85d3820d00694ed10f581f4c650445dbcda ]
    
    The nl80211_dump_interface() supports resumption
    in case nl80211_send_iface() doesn't have the
    resources to complete its work.
    
    The logic would store the progress as iteration
    offsets for rdev and wdev loops.
    
    However the logic did not properly handle
    resumption for non-last rdev. Assuming a system
    with 2 rdevs, with 2 wdevs each, this could
    happen:
    
     dump(cb=[0, 0]):
      if_start=cb[1] (=0)
      send rdev0.wdev0 -> ok
      send rdev0.wdev1 -> yield
      cb[1] = 1
    
     dump(cb=[0, 1]):
      if_start=cb[1] (=1)
      send rdev0.wdev1 -> ok
      // since if_start=1 the rdev0.wdev0 got skipped
      // through if_idx < if_start
      send rdev1.wdev1 -> ok
    
    The if_start needs to be reset back to 0 upon wdev
    loop end.
    
    The problem is actually hard to hit on a desktop,
    and even on most routers. The prerequisites for
    this manifesting was:
     - more than 1 wiphy
     - a few handful of interfaces
     - dump without rdev or wdev filter
    
    I was seeing this with 4 wiphys 9 interfaces each.
    It'd miss 6 interfaces from the last wiphy
    reported to userspace.
    
    Signed-off-by: Michal Kazior <michal@plume.com>
    Link: https://msgid.link/20240116142340.89678-1-kazikcz@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: avoid baid size integer overflow [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 20 13:04:02 2023 +0300

    wifi: iwlwifi: mvm: avoid baid size integer overflow
    
    [ Upstream commit 1a528ab1da324d078ec60283c34c17848580df24 ]
    
    Roee reported various hard-to-debug crashes with pings in
    EHT aggregation scenarios. Enabling KASAN showed that we
    access the BAID allocation out of bounds, and looking at
    the code a bit shows that since the reorder buffer entry
    (struct iwl_mvm_reorder_buf_entry) is 128 bytes if debug
    such as lockdep is enabled, then staring from an agg size
    512 we overflow the size calculation, and allocate a much
    smaller structure than we should, causing slab corruption
    once we initialize this.
    
    Fix this by simply using u32 instead of u16.
    
    Reported-by: Roee Goldfiner <roee.h.goldfiner@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230620125813.f428c856030d.I2c2bb808e945adb71bc15f5b2bac2d8957ea90eb@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: adding missing drv_mgd_complete_tx() call [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jan 31 16:48:23 2024 +0100

    wifi: mac80211: adding missing drv_mgd_complete_tx() call
    
    [ Upstream commit c042600c17d8c490279f0ae2baee29475fe8047d ]
    
    There's a call to drv_mgd_prepare_tx() and so there should
    be one to drv_mgd_complete_tx(), but on this path it's not.
    Add it.
    
    Link: https://msgid.link/20240131164824.2f0922a514e1.I5aac89b93bcead88c374187d70cad0599d29d2c8@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix race condition on enabling fast-xmit [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Thu Jan 4 19:10:59 2024 +0100

    wifi: mac80211: fix race condition on enabling fast-xmit
    
    [ Upstream commit bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f ]
    
    fast-xmit must only be enabled after the sta has been uploaded to the driver,
    otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls
    to the driver, leading to potential crashes because of uninitialized drv_priv
    data.
    Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://msgid.link/20240104181059.84032-1-nbd@nbd.name
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: wext-core: Fix -Wstringop-overflow warning in ioctl_standard_iw_point() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Thu Jun 15 12:04:07 2023 -0600

    wifi: wext-core: Fix -Wstringop-overflow warning in ioctl_standard_iw_point()
    
    [ Upstream commit 71e7552c90db2a2767f5c17c7ec72296b0d92061 ]
    
    -Wstringop-overflow is legitimately warning us about extra_size
    pontentially being zero at some point, hence potenially ending
    up _allocating_ zero bytes of memory for extra pointer and then
    trying to access such object in a call to copy_from_user().
    
    Fix this by adding a sanity check to ensure we never end up
    trying to allocate zero bytes of data for extra pointer, before
    continue executing the rest of the code in the function.
    
    Address the following -Wstringop-overflow warning seen when built
    m68k architecture with allyesconfig configuration:
                     from net/wireless/wext-core.c:11:
    In function '_copy_from_user',
        inlined from 'copy_from_user' at include/linux/uaccess.h:183:7,
        inlined from 'ioctl_standard_iw_point' at net/wireless/wext-core.c:825:7:
    arch/m68k/include/asm/string.h:48:25: warning: '__builtin_memset' writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
       48 | #define memset(d, c, n) __builtin_memset(d, c, n)
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
    include/linux/uaccess.h:153:17: note: in expansion of macro 'memset'
      153 |                 memset(to + (n - res), 0, res);
          |                 ^~~~~~
    In function 'kmalloc',
        inlined from 'kzalloc' at include/linux/slab.h:694:9,
        inlined from 'ioctl_standard_iw_point' at net/wireless/wext-core.c:819:10:
    include/linux/slab.h:577:16: note: at offset 1 into destination object of size 0 allocated by '__kmalloc'
      577 |         return __kmalloc(size, flags);
          |                ^~~~~~~~~~~~~~~~~~~~~~
    
    This help with the ongoing efforts to globally enable
    -Wstringop-overflow.
    
    Link: https://github.com/KSPP/linux/issues/315
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/ZItSlzvIpjdjNfd8@work
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/alternative: Make custom return thunk unconditional [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Aug 14 13:44:30 2023 +0200

    x86/alternative: Make custom return thunk unconditional
    
    Upstream commit: 095b8303f3835c68ac4a8b6d754ca1c3b6230711
    
    There is infrastructure to rewrite return thunks to point to any
    random thunk one desires, unwrap that from CALL_THUNKS, which up to
    now was the sole user of that.
    
      [ bp: Make the thunks visible on 32-bit and add ifdeffery for the
        32-bit builds. ]
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20230814121148.775293785@infradead.org
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/fpu: Stop relying on userspace for info to fault in xsave buffer [+ + +]
Author: Andrei Vagin <avagin@google.com>
Date:   Mon Jan 29 22:36:03 2024 -0800

    x86/fpu: Stop relying on userspace for info to fault in xsave buffer
    
    commit d877550eaf2dc9090d782864c96939397a3c6835 upstream.
    
    Before this change, the expected size of the user space buffer was
    taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed
    from user-space, so it is possible construct a sigreturn frame where:
    
     * fx_sw->xstate_size is smaller than the size required by valid bits in
       fx_sw->xfeatures.
     * user-space unmaps parts of the sigrame fpu buffer so that not all of
       the buffer required by xrstor is accessible.
    
    In this case, xrstor tries to restore and accesses the unmapped area
    which results in a fault. But fault_in_readable succeeds because buf +
    fx_sw->xstate_size is within the still mapped area, so it goes back and
    tries xrstor again. It will spin in this loop forever.
    
    Instead, fault in the maximum size which can be touched by XRSTOR (taken
    from fpstate->user_size).
    
    [ dhansen: tweak subject / changelog ]
    
    Fixes: fcb3635f5018 ("x86/fpu/signal: Handle #PF in the direct restore path")
    Reported-by: Konstantin Bogomolov <bogomolov@google.com>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrei Vagin <avagin@google.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc:stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240130063603.3392627-1-avagin%40google.com
    Link: https://lore.kernel.org/all/20240130063603.3392627-1-avagin%40google.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/ftrace: Use alternative RET encoding [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jun 14 23:15:40 2022 +0200

    x86/ftrace: Use alternative RET encoding
    
    Upstream commit: 1f001e9da6bbf482311e45e48f53c2bd2179e59c
    
    Use the return thunk in ftrace trampolines, if needed.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/ibt,paravirt: Use text_gen_insn() for paravirt_patch() [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Mar 8 16:30:20 2022 +0100

    x86/ibt,paravirt: Use text_gen_insn() for paravirt_patch()
    
    Upstream commit: ba27d1a80871eb8dbeddf34ec7d396c149cbb8d7
    
    Less duplication is more better.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lore.kernel.org/r/20220308154317.697253958@infradead.org
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/returnthunk: Allow different return thunks [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Sep 15 13:11:25 2022 +0200

    x86/returnthunk: Allow different return thunks
    
    Upstream commit: 770ae1b709528a6a173b5c7b183818ee9b45e376
    
    In preparation for call depth tracking on Intel SKL CPUs, make it possible
    to patch in a SKL specific return thunk.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220915111147.680469665@infradead.org
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/text-patching: Make text_gen_insn() play nice with ANNOTATE_NOENDBR [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Mar 8 16:30:19 2022 +0100

    x86/text-patching: Make text_gen_insn() play nice with ANNOTATE_NOENDBR
    
    Upstream commit: bbf92368b0b1fe472d489e62d3340d7897e9c697
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lore.kernel.org/r/20220308154317.638561109@infradead.org
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci: cleanup xhci_hub_control port references [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:04:59 2023 +0200

    xhci: cleanup xhci_hub_control port references
    
    [ Upstream commit faaae0190dcd1e230616c85bbc3b339f27ba5b81 ]
    
    Both port number and port structure of a port are referred to several
    times when handing hub requests in xhci.
    
    Use more suitable data types and readable names for these.
    Cleanup only, no functional changes
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: clear usb2 resume related variables in one place. [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:04 2023 +0200

    xhci: clear usb2 resume related variables in one place.
    
    [ Upstream commit 0e6275452ce26d7ff274a5c1b15ed581a26f7986 ]
    
    Initially resume related USB2 variables were cleared once port
    successfully resumed to U0. Later code was added to clean up
    stale resume variables in case of port failed to resume to U0.
    
    Clear the variables in one place after port is no longer resuming
    or in suspended U3 state.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-11-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: decouple usb2 port resume and get_port_status request handling [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:05 2023 +0200

    xhci: decouple usb2 port resume and get_port_status request handling
    
    [ Upstream commit b0425784b942fffbbdb804896197f1dbccda37c5 ]
    
    The get port status hub request code in xhci-hub.c will complete usb2
    port resume signalling if signalling has been going on for long enough.
    
    The code that completes the resume signalling, and the code that returns
    the port status have gotten too intertwined, so separate them a bit.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-12-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: move port specific items such as state completions to port structure [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:01 2023 +0200

    xhci: move port specific items such as state completions to port structure
    
    [ Upstream commit 2996e9fc00c378987c18ecbafe5624581b18c0d6 ]
    
    Now that we have a port structure for each port it makes sense to
    move per port variables, timestamps and completions there.
    Get rid of storing bitfileds and arrays of port specific items per bus.
    
    Move
    unsigned long           resume_done;
    insigned long           rexit_ports
    struct completion       rexit_done;
    struct completion       u3exit_done;
    
    Rename rexit_ports to rexit_active, and remove a redundant hcd
    speed check while checking if rexit_active is set.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-8-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: rename resume_done to resume_timestamp [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:03 2023 +0200

    xhci: rename resume_done to resume_timestamp
    
    [ Upstream commit a909d629ae77b97b6288bc3cfe68560454bf79c6 ]
    
    resume_done is just a timestamp, avoid confusing it with completions
    related to port state transitions that are named *_done
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-10-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: track port suspend state correctly in unsuccessful resume cases [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Sep 15 17:31:06 2023 +0300

    xhci: track port suspend state correctly in unsuccessful resume cases
    
    [ Upstream commit d7cdfc319b2bcf6899ab0a05eec0958bc802a9a1 ]
    
    xhci-hub.c tracks suspended ports in a suspended_port bitfield.
    This is checked when responding to a Get_Status(PORT) request to see if a
    port in running U0 state was recently resumed, and adds the required
    USB_PORT_STAT_C_SUSPEND change bit in those cases.
    
    The suspended_port bit was left uncleared if a device is disconnected
    during suspend. The bit remained set even when a new device was connected
    and enumerated. The set bit resulted in a incorrect Get_Status(PORT)
    response with a bogus USB_PORT_STAT_C_SUSPEND change
    bit set once the new device reached U0 link state.
    
    USB_PORT_STAT_C_SUSPEND change bit is only used for USB2 ports, but
    xhci-hub keeps track of both USB2 and USB3 suspended ports.
    
    Cc: stable@vger.kernel.org
    Reported-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Closes: https://lore.kernel.org/linux-usb/d68aa806-b26a-0e43-42fb-b8067325e967@quicinc.com/
    Fixes: 1d5810b6923c ("xhci: Rework port suspend structures for limited ports.")
    Tested-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230915143108.1532163-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
zonefs: Improve error handling [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu Feb 8 17:26:59 2024 +0900

    zonefs: Improve error handling
    
    commit 14db5f64a971fce3d8ea35de4dfc7f443a3efb92 upstream.
    
    Write error handling is racy and can sometime lead to the error recovery
    path wrongly changing the inode size of a sequential zone file to an
    incorrect value  which results in garbage data being readable at the end
    of a file. There are 2 problems:
    
    1) zonefs_file_dio_write() updates a zone file write pointer offset
       after issuing a direct IO with iomap_dio_rw(). This update is done
       only if the IO succeed for synchronous direct writes. However, for
       asynchronous direct writes, the update is done without waiting for
       the IO completion so that the next asynchronous IO can be
       immediately issued. However, if an asynchronous IO completes with a
       failure right before the i_truncate_mutex lock protecting the update,
       the update may change the value of the inode write pointer offset
       that was corrected by the error path (zonefs_io_error() function).
    
    2) zonefs_io_error() is called when a read or write error occurs. This
       function executes a report zone operation using the callback function
       zonefs_io_error_cb(), which does all the error recovery handling
       based on the current zone condition, write pointer position and
       according to the mount options being used. However, depending on the
       zoned device being used, a report zone callback may be executed in a
       context that is different from the context of __zonefs_io_error(). As
       a result, zonefs_io_error_cb() may be executed without the inode
       truncate mutex lock held, which can lead to invalid error processing.
    
    Fix both problems as follows:
    - Problem 1: Perform the inode write pointer offset update before a
      direct write is issued with iomap_dio_rw(). This is safe to do as
      partial direct writes are not supported (IOMAP_DIO_PARTIAL is not
      set) and any failed IO will trigger the execution of zonefs_io_error()
      which will correct the inode write pointer offset to reflect the
      current state of the one on the device.
    - Problem 2: Change zonefs_io_error_cb() into zonefs_handle_io_error()
      and call this function directly from __zonefs_io_error() after
      obtaining the zone information using blkdev_report_zones() with a
      simple callback function that copies to a local stack variable the
      struct blk_zone obtained from the device. This ensures that error
      handling is performed holding the inode truncate mutex.
      This change also simplifies error handling for conventional zone files
      by bypassing the execution of report zones entirely. This is safe to
      do because the condition of conventional zones cannot be read-only or
      offline and conventional zone files are always fully mapped with a
      constant file size.
    
    Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>