Linux 5.10.211

 
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>

 
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>

 
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: imx: Set default tuning step for imx6sx usdhc [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Wed Jul 26 15:57:47 2023 +0800

    ARM: dts: imx: Set default tuning step for imx6sx usdhc
    
    [ Upstream commit 0a2b96e42a0284c4fc03022236f656a085ca714a ]
    
    If the tuning step is not set, the tuning step is set to 1.
    For some sd cards, the following Tuning timeout will occur.
    
    Tuning failed, falling back to fixed sampling clock
    
    So set the default tuning step. This refers to the NXP vendor's
    commit below:
    
    https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/
    arch/arm/boot/dts/imx6sx.dtsi#L1108-L1109
    
    Fixes: 1e336aa0c025 ("mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting")
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    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: fsl_micfil: register platform component before registering cpu dai [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Fri Sep 3 18:30:04 2021 +0800

    ASoC: fsl_micfil: register platform component before registering cpu dai
    
    [ Upstream commit 0adf292069dcca8bab76a603251fcaabf77468ca ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: 47a70e6fc9a8 ("ASoC: Add MICFIL SoC Digital Audio Interface driver.")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1630665006-31437-4-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: boards: get codec device with ACPI instead of bus search [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Fri Aug 13 10:11:11 2021 -0500

    ASoC: Intel: boards: get codec device with ACPI instead of bus search
    
    [ Upstream commit d3409eb20d3ed7d9e021cd13243e9e63255a315f ]
    
    We have an existing 'adev' handle from which we can find the codec
    device, no need for an I2C bus search.
    
    Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210813151116.23931-4-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 721858823d7c ("ASoC: Intel: bytcr_rt5651: Drop reference count of ACPI device after use")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: boards: harden codec property handling [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Fri Aug 13 10:11:09 2021 -0500

    ASoC: Intel: boards: harden codec property handling
    
    [ Upstream commit c50f126b3c9ebb77585838726a3a490ad33b92cd ]
    
    In current ACPI-based devices, the DSDT does not include any of the
    properties required by the codec driver. This is not an ACPI
    limitation proper since the _DSD method could be used, as done for
    Camera and SoundWire in newer platforms. For legacy devices, there is
    unfortunately no other option than using a work-around: we add
    properties to the codec device from the machine driver.
    
    To avoid any issues with the codec driver being unbound, we need to
    keep a reference to the codec device until the card is removed.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Co-developed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210813151116.23931-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 721858823d7c ("ASoC: Intel: bytcr_rt5651: Drop reference count of ACPI device after use")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: bytcr_rt5651: Drop reference count of ACPI device after use [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Jan 12 13:28:49 2023 +0200

    ASoC: Intel: bytcr_rt5651: Drop reference count of ACPI device after use
    
    [ Upstream commit 721858823d7cdc8f2a897579b040e935989f6f02 ]
    
    Theoretically the device might gone if its reference count drops to 0.
    This might be the case when we try to find the first physical node of
    the ACPI device. We need to keep reference to it until we get a result
    of the above mentioned call. Refactor the code to drop the reference
    count at the correct place.
    
    While at it, move to acpi_dev_put() as symmetrical call to the
    acpi_dev_get_first_match_dev().
    
    Fixes: 02c0a3b3047f ("ASoC: Intel: bytcr_rt5651: add MCLK, quirks and cleanups")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20230112112852.67714-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
block: ataflop: fix breakage introduced at blk-mq refactoring [+ + +]
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Tue Oct 19 19:13:21 2021 +1300

    block: ataflop: fix breakage introduced at blk-mq refactoring
    
    [ Upstream commit 86d46fdaa12ae5befc16b8d73fc85a3ca0399ea6 ]
    
    Refactoring of the Atari floppy driver when converting to blk-mq
    has broken the state machine in not-so-subtle ways:
    
    finish_fdc() must be called when operations on the floppy device
    have completed. This is crucial in order to relase the ST-DMA
    lock, which protects against concurrent access to the ST-DMA
    controller by other drivers (some DMA related, most just related
    to device register access - broken beyond compare, I know).
    
    When rewriting the driver's old do_request() function, the fact
    that finish_fdc() was called only when all queued requests had
    completed appears to have been overlooked. Instead, the new
    request function calls finish_fdc() immediately after the last
    request has been queued. finish_fdc() executes a dummy seek after
    most requests, and this overwrites the state machine's interrupt
    hander that was set up to wait for completion of the read/write
    request just prior. To make matters worse, finish_fdc() is called
    before device interrupts are re-enabled, making certain that the
    read/write interupt is missed.
    
    Shifting the finish_fdc() call into the read/write request
    completion handler ensures the driver waits for the request to
    actually complete. With a queue depth of 2, we won't see long
    request sequences, so calling finish_fdc() unconditionally just
    adds a little overhead for the dummy seeks, and keeps the code
    simple.
    
    While we're at it, kill ataflop_commit_rqs() which does nothing
    but run finish_fdc() unconditionally, again likely wiping out an
    in-flight request.
    
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Fixes: 6ec3938cff95 ("ataflop: convert to blk-mq")
    CC: linux-block@vger.kernel.org
    CC: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Link: https://lore.kernel.org/r/20211019061321.26425-1-schmitzmic@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: ataflop: more blk-mq refactoring fixes [+ + +]
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Sun Oct 24 13:20:13 2021 +1300

    block: ataflop: more blk-mq refactoring fixes
    
    commit d28e4dff085c5a87025c9a0a85fb798bd8e9ca17 upstream.
    
    As it turns out, my earlier patch in commit 86d46fdaa12a (block:
    ataflop: fix breakage introduced at blk-mq refactoring) was
    incomplete. This patch fixes any remaining issues found during
    more testing and code review.
    
    Requests exceeding 4 k are handled in 4k segments but
    __blk_mq_end_request() is never called on these (still
    sectors outstanding on the request). With redo_fd_request()
    removed, there is no provision to kick off processing of the
    next segment, causing requests exceeding 4k to hang. (By
    setting /sys/block/fd0/queue/max_sectors_k <= 4 as workaround,
    this behaviour can be avoided).
    
    Instead of reintroducing redo_fd_request(), requeue the remainder
    of the request by calling blk_mq_requeue_request() on incomplete
    requests (i.e. when blk_update_request() still returns true), and
    rely on the block layer to queue the residual as new request.
    
    Both error handling and formatting needs to release the
    ST-DMA lock, so call finish_fdc() on these (this was previously
    handled by redo_fd_request()). finish_fdc() may be called
    legitimately without the ST-DMA lock held - make sure we only
    release the lock if we actually held it. In a similar way,
    early exit due to errors in ataflop_queue_rq() must release
    the lock.
    
    After minor errors, fd_error sets up to recalibrate the drive
    but never re-runs the current operation (another task handled by
    redo_fd_request() before). Call do_fd_action() to get the next
    steps (seek, retry read/write) underway.
    
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Fixes: 6ec3938cff95f (ataflop: convert to blk-mq)
    CC: linux-block@vger.kernel.org
    Link: https://lore.kernel.org/r/20211024002013.9332-1-schmitzmic@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [MSch: v5.10 backport merge conflict fix]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
btrfs: do not pin logs too early during renames [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jul 27 11:24:45 2021 +0100

    btrfs: do not pin logs too early during renames
    
    [ Upstream commit bd54f381a12ac695593271a663d36d14220215b2 ]
    
    During renames we pin the logs of the roots a bit too early, before the
    calls to btrfs_insert_inode_ref(). We can pin the logs after those calls,
    since those will not change anything in a log tree.
    
    In a scenario where we have multiple and diverse filesystem operations
    running in parallel, those calls can take a significant amount of time,
    due to lock contention on extent buffers, and delay log commits from other
    tasks for longer than necessary.
    
    So just pin logs after calls to btrfs_insert_inode_ref() and right before
    the first operation that can update a log tree.
    
    The following script that uses dbench was used for testing:
    
      $ cat dbench-test.sh
      #!/bin/bash
    
      DEV=/dev/nvme0n1
      MNT=/mnt/nvme0n1
      MOUNT_OPTIONS="-o ssd"
      MKFS_OPTIONS="-m single -d single"
    
      echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    
      umount $DEV &> /dev/null
      mkfs.btrfs -f $MKFS_OPTIONS $DEV
      mount $MOUNT_OPTIONS $DEV $MNT
    
      dbench -D $MNT -t 120 16
    
      umount $MNT
    
    The tests were run on a machine with 12 cores, 64G of RAN, a NVMe device
    and using a non-debug kernel config (Debian's default config).
    
    The results compare a branch without this patch and without the previous
    patch in the series, that has the subject:
    
     "btrfs: eliminate some false positives when checking if inode was logged"
    
    Versus the same branch with these two patches applied.
    
    dbench with 8 clients, results before:
    
     Operation      Count    AvgLat    MaxLat
     ----------------------------------------
     NTCreateX    4391359     0.009   249.745
     Close        3225882     0.001     3.243
     Rename        185953     0.065   240.643
     Unlink        886669     0.049   249.906
     Deltree          112     2.455   217.433
     Mkdir             56     0.002     0.004
     Qpathinfo    3980281     0.004     3.109
     Qfileinfo     697579     0.001     0.187
     Qfsinfo       729780     0.002     2.424
     Sfileinfo     357764     0.004     1.415
     Find         1538861     0.016     4.863
     WriteX       2189666     0.010     3.327
     ReadX        6883443     0.002     0.729
     LockX          14298     0.002     0.073
     UnlockX        14298     0.001     0.042
     Flush         307777     2.447   303.663
    
    Throughput 1149.6 MB/sec  8 clients  8 procs  max_latency=303.666 ms
    
    dbench with 8 clients, results after:
    
     Operation      Count    AvgLat    MaxLat
     ----------------------------------------
     NTCreateX    4269920     0.009   213.532
     Close        3136653     0.001     0.690
     Rename        180805     0.082   213.858
     Unlink        862189     0.050   172.893
     Deltree          112     2.998   218.328
     Mkdir             56     0.002     0.003
     Qpathinfo    3870158     0.004     5.072
     Qfileinfo     678375     0.001     0.194
     Qfsinfo       709604     0.002     0.485
     Sfileinfo     347850     0.004     1.304
     Find         1496310     0.017     5.504
     WriteX       2129613     0.010     2.882
     ReadX        6693066     0.002     1.517
     LockX          13902     0.002     0.075
     UnlockX        13902     0.001     0.055
     Flush         299276     2.511   220.189
    
    Throughput 1187.33 MB/sec  8 clients  8 procs  max_latency=220.194 ms
    
    +3.2% throughput, -31.8% max latency
    
    dbench with 16 clients, results before:
    
     Operation      Count    AvgLat    MaxLat
     ----------------------------------------
     NTCreateX    5978334     0.028   156.507
     Close        4391598     0.001     1.345
     Rename        253136     0.241   155.057
     Unlink       1207220     0.182   257.344
     Deltree          160     6.123    36.277
     Mkdir             80     0.003     0.005
     Qpathinfo    5418817     0.012     6.867
     Qfileinfo     949929     0.001     0.941
     Qfsinfo       993560     0.002     1.386
     Sfileinfo     486904     0.004     2.829
     Find         2095088     0.059     8.164
     WriteX       2982319     0.017     9.029
     ReadX        9371484     0.002     4.052
     LockX          19470     0.002     0.461
     UnlockX        19470     0.001     0.990
     Flush         418936     2.740   347.902
    
    Throughput 1495.31 MB/sec  16 clients  16 procs  max_latency=347.909 ms
    
    dbench with 16 clients, results after:
    
     Operation      Count    AvgLat    MaxLat
     ----------------------------------------
     NTCreateX    5711833     0.029   131.240
     Close        4195897     0.001     1.732
     Rename        241849     0.204   147.831
     Unlink       1153341     0.184   231.322
     Deltree          160     6.086    30.198
     Mkdir             80     0.003     0.021
     Qpathinfo    5177011     0.012     7.150
     Qfileinfo     907768     0.001     0.793
     Qfsinfo       949205     0.002     1.431
     Sfileinfo     465317     0.004     2.454
     Find         2001541     0.058     7.819
     WriteX       2850661     0.017     9.110
     ReadX        8952289     0.002     3.991
     LockX          18596     0.002     0.655
     UnlockX        18596     0.001     0.179
     Flush         400342     2.879   293.607
    
    Throughput 1565.73 MB/sec  16 clients  16 procs  max_latency=293.611 ms
    
    +4.6% throughput, -16.9% max latency
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: introduce btrfs_lookup_match_dir [+ + +]
Author: Marcos Paulo de Souza <mpdesouza@suse.com>
Date:   Mon Jul 26 16:19:09 2021 -0300

    btrfs: introduce btrfs_lookup_match_dir
    
    [ Upstream commit a7d1c5dc8632e9b370ad26478c468d4e4e29f263 ]
    
    btrfs_search_slot is called in multiple places in dir-item.c to search
    for a dir entry, and then calling btrfs_match_dir_name to return a
    btrfs_dir_item.
    
    In order to reduce the number of callers of btrfs_search_slot, create a
    common function that looks for the dir key, and if found call
    btrfs_match_dir_item_name.
    
    Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Stable-dep-of: 8dcbc26194eb ("btrfs: unify lookup return value when dir entry is missing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: tree-checker: check for overlapping extent items [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 3 14:28:47 2022 -0400

    btrfs: tree-checker: check for overlapping extent items
    
    [ Upstream commit 899b7f69f244e539ea5df1b4d756046337de44a5 ]
    
    We're seeing a weird problem in production where we have overlapping
    extent items in the extent tree.  It's unclear where these are coming
    from, and in debugging we realized there's no check in the tree checker
    for this sort of problem.  Add a check to the tree-checker to make sure
    that the extents do not overlap each other.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: unify lookup return value when dir entry is missing [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Oct 1 13:52:33 2021 +0100

    btrfs: unify lookup return value when dir entry is missing
    
    [ Upstream commit 8dcbc26194eb872cc3430550fb70bb461424d267 ]
    
    btrfs_lookup_dir_index_item() and btrfs_lookup_dir_item() lookup for dir
    entries and both are used during log replay or when updating a log tree
    during an unlink.
    
    However when the dir item does not exists, btrfs_lookup_dir_item() returns
    NULL while btrfs_lookup_dir_index_item() returns PTR_ERR(-ENOENT), and if
    the dir item exists but there is no matching entry for a given name or
    index, both return NULL. This makes the call sites during log replay to
    be more verbose than necessary and it makes it easy to miss this slight
    difference. Since we don't need to distinguish between those two cases,
    make btrfs_lookup_dir_index_item() always return NULL when there is no
    matching directory entry - either because there isn't any dir entry or
    because there is one but it does not match the given name and index.
    
    Also rename the argument 'objectid' of btrfs_lookup_dir_index_item() to
    'index' since it is supposed to match an index number, and the name
    'objectid' is not very good because it can easily be confused with an
    inode number (like the inode number a dir entry points to).
    
    CC: stable@vger.kernel.org # 4.14+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: 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>

 
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/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/syncobj: make lockdep complain on WAIT_FOR_SUBMIT v3 [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Jan 15 14:32:39 2021 +0100

    drm/syncobj: make lockdep complain on WAIT_FOR_SUBMIT v3
    
    [ Upstream commit 7621350c6bb20fb6ab7eb988833ab96eac3dcbef ]
    
    DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when we hold locks
    since we are basically waiting for userspace to do something.
    
    Holding a lock while doing so can trivial deadlock with page faults
    etc...
    
    So make lockdep complain when a driver tries to do this.
    
    v2: Add lockdep_assert_none_held() macro.
    v3: Add might_sleep() and also use lockdep_assert_none_held() in the
        IOCTL path.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://patchwork.freedesktop.org/patch/414944/
    Stable-dep-of: 3c43177ffb54 ("drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set")
    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>

 
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: 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>

 
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>

 
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>

 
hsr: Avoid double remove of a node. [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Nov 29 17:48:10 2022 +0100

    hsr: Avoid double remove of a node.
    
    [ Upstream commit 0c74d9f79ec4299365bbe803baa736ae0068179e ]
    
    Due to the hashed-MAC optimisation one problem become visible:
    hsr_handle_sup_frame() walks over the list of available nodes and merges
    two node entries into one if based on the information in the supervision
    both MAC addresses belong to one node. The list-walk happens on a RCU
    protected list and delete operation happens under a lock.
    
    If the supervision arrives on both slave interfaces at the same time
    then this delete operation can occur simultaneously on two CPUs. The
    result is the first-CPU deletes the from the list and the second CPUs
    BUGs while attempting to dereference a poisoned list-entry. This happens
    more likely with the optimisation because a new node for the mac_B entry
    is created once a packet has been received and removed (merged) once the
    supervision frame has been received.
    
    Avoid removing/ cleaning up a hsr_node twice by adding a `removed' field
    which is set to true after the removal and checked before the removal.
    
    Fixes: f266a683a4804 ("net/hsr: Better frame dispatch")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hvc/xen: prevent concurrent accesses to the shared ring [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Nov 30 16:09:11 2022 +0100

    hvc/xen: prevent concurrent accesses to the shared ring
    
    [ Upstream commit 6214894f49a967c749ee6c07cb00f9cede748df4 ]
    
    The hvc machinery registers both a console and a tty device based on
    the hv ops provided by the specific implementation.  Those two
    interfaces however have different locks, and there's no single locks
    that's shared between the tty and the console implementations, hence
    the driver needs to protect itself against concurrent accesses.
    Otherwise concurrent calls using the split interfaces are likely to
    corrupt the ring indexes, leaving the console unusable.
    
    Introduce a lock to xencons_info to serialize accesses to the shared
    ring.  This is only required when using the shared memory console,
    concurrent accesses to the hypercall based console implementation are
    not an issue.
    
    Note the conditional logic in domU_read_console() is slightly modified
    so the notify_daemon() call can be done outside of the locked region:
    it's an hypercall and there's no need for it to be done with the lock
    held.
    
    Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console')
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20221130150919.13935-1-roger.pau@citrix.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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>

 
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>

 
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>

 
irqchip/mips-gic: Don't touch vl_map if a local interrupt is not routable [+ + +]
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Mon Apr 24 11:31:55 2023 +0100

    irqchip/mips-gic: Don't touch vl_map if a local interrupt is not routable
    
    [ Upstream commit 2c6c9c049510163090b979ea5f92a68ae8d93c45 ]
    
    When a GIC local interrupt is not routable, it's vl_map will be used
    to control some internal states for core (providing IPTI, IPPCI, IPFDC
    input signal for core). Overriding it will interfere core's intetrupt
    controller.
    
    Do not touch vl_map if a local interrupt is not routable, we are not
    going to remap it.
    
    Before dd098a0e0319 (" irqchip/mips-gic: Get rid of the reliance on
    irq_cpu_online()"), if a local interrupt is not routable, then it won't
    be requested from GIC Local domain, and thus gic_all_vpes_irq_cpu_online
    won't be called for that particular interrupt.
    
    Fixes: dd098a0e0319 (" irqchip/mips-gic: Get rid of the reliance on irq_cpu_online()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Tested-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20230424103156.66753-2-jiaxun.yang@flygoat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iwlwifi: mvm: do more useful queue sync accounting [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Dec 9 23:16:31 2020 +0200

    iwlwifi: mvm: do more useful queue sync accounting
    
    [ Upstream commit 2f7a04c7b03b7fd63b7618e29295fc25732faac1 ]
    
    We're currently doing accounting on the queue sync with an
    atomic variable that counts down the number of remaining
    notifications that we still need.
    
    As we've been hitting issues in this area, modify this to
    track a bitmap of queues, not just the number of queues,
    and print out the remaining bitmap in the warning.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20201209231352.0a3fa177cd6b.I7c69ff999419368266279ec27dd618eb450908b3@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Stable-dep-of: 5f8a3561ea8b ("iwlwifi: mvm: write queue_sync_state only for sync")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iwlwifi: mvm: write queue_sync_state only for sync [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 31 12:14:41 2021 +0300

    iwlwifi: mvm: write queue_sync_state only for sync
    
    [ Upstream commit 5f8a3561ea8bf75ad52cb16dafe69dd550fa542e ]
    
    We use mvm->queue_sync_state to wait for synchronous queue sync
    messages, but if an async one happens inbetween we shouldn't
    clear mvm->queue_sync_state after sending the async one, that
    can run concurrently (at least from the CPU POV) with another
    synchronous queue sync.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20210331121101.d11c9bcdb4aa.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue Jun 6 21:59:26 2023 +0800

    jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint
    
    [ Upstream commit e34c8dd238d0c9368b746480f313055f5bab5040 ]
    
    Following process,
    
    jbd2_journal_commit_transaction
    // there are several dirty buffer heads in transaction->t_checkpoint_list
              P1                   wb_workfn
    jbd2_log_do_checkpoint
     if (buffer_locked(bh)) // false
                                __block_write_full_page
                                 trylock_buffer(bh)
                                 test_clear_buffer_dirty(bh)
     if (!buffer_dirty(bh))
      __jbd2_journal_remove_checkpoint(jh)
       if (buffer_write_io_error(bh)) // false
                                 >> bh IO error occurs <<
     jbd2_cleanup_journal_tail
      __jbd2_update_log_tail
       jbd2_write_superblock
       // The bh won't be replayed in next mount.
    , which could corrupt the ext4 image, fetch a reproducer in [Link].
    
    Since writeback process clears buffer dirty after locking buffer head,
    we can fix it by try locking buffer and check dirtiness while buffer is
    locked, the buffer head can be removed if it is neither dirty nor locked.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217490
    Fixes: 470decc613ab ("[PATCH] jbd2: initial copy of files from jbd")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230606135928.434610-5-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jbd2: recheck chechpointing non-dirty buffer [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Tue Jun 6 21:59:23 2023 +0800

    jbd2: recheck chechpointing non-dirty buffer
    
    [ Upstream commit c2d6fd9d6f35079f1669f0100f05b46708c74b7f ]
    
    There is a long-standing metadata corruption issue that happens from
    time to time, but it's very difficult to reproduce and analyse, benefit
    from the JBD2_CYCLE_RECORD option, we found out that the problem is the
    checkpointing process miss to write out some buffers which are raced by
    another do_get_write_access(). Looks below for detail.
    
    jbd2_log_do_checkpoint() //transaction X
     //buffer A is dirty and not belones to any transaction
     __buffer_relink_io() //move it to the IO list
     __flush_batch()
      write_dirty_buffer()
                                 do_get_write_access()
                                 clear_buffer_dirty
                                 __jbd2_journal_file_buffer()
                                 //add buffer A to a new transaction Y
       lock_buffer(bh)
       //doesn't write out
     __jbd2_journal_remove_checkpoint()
     //finish checkpoint except buffer A
     //filesystem corrupt if the new transaction Y isn't fully write out.
    
    Due to the t_checkpoint_list walking loop in jbd2_log_do_checkpoint()
    have already handles waiting for buffers under IO and re-added new
    transaction to complete commit, and it also removing cleaned buffers,
    this makes sure the list will eventually get empty. So it's fine to
    leave buffers on the t_checkpoint_list while flushing out and completely
    stop using the t_checkpoint_io_list.
    
    Cc: stable@vger.kernel.org
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Tested-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230606135928.434610-2-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: e34c8dd238d0 ("jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jbd2: remove redundant buffer io error checks [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Thu Jun 10 19:24:36 2021 +0800

    jbd2: remove redundant buffer io error checks
    
    [ Upstream commit 214eb5a4d8a2032fb9f0711d1b202eb88ee02920 ]
    
    Now that __jbd2_journal_remove_checkpoint() can detect buffer io error
    and mark journal checkpoint error, then we abort the journal later
    before updating log tail to ensure the filesystem works consistently.
    So we could remove other redundant buffer io error checkes.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20210610112440.3438139-5-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: e34c8dd238d0 ("jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint")
    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>

 
lan743x: fix for potential NULL pointer dereference with bare card [+ + +]
Author: Sergej Bauer <sbauer@blackbox.su>
Date:   Mon Nov 2 01:35:55 2020 +0300

    lan743x: fix for potential NULL pointer dereference with bare card
    
    [ Upstream commit e9e13b6adc338be1eb88db87bcb392696144bd02 ]
    
    This is the 3rd revision of the patch fix for potential null pointer dereference
    with lan743x card.
    
    The simpliest way to reproduce: boot with bare lan743x and issue "ethtool ethN"
    commant where ethN is the interface with lan743x card. Example:
    
    $ sudo ethtool eth7
    dmesg:
    [  103.510336] BUG: kernel NULL pointer dereference, address: 0000000000000340
    ...
    [  103.510836] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy]
    ...
    [  103.511629] Call Trace:
    [  103.511666]  lan743x_ethtool_get_wol+0x21/0x40 [lan743x]
    [  103.511724]  dev_ethtool+0x1507/0x29d0
    [  103.511769]  ? avc_has_extended_perms+0x17f/0x440
    [  103.511820]  ? tomoyo_init_request_info+0x84/0x90
    [  103.511870]  ? tomoyo_path_number_perm+0x68/0x1e0
    [  103.511919]  ? tty_insert_flip_string_fixed_flag+0x82/0xe0
    [  103.511973]  ? inet_ioctl+0x187/0x1d0
    [  103.512016]  dev_ioctl+0xb5/0x560
    [  103.512055]  sock_do_ioctl+0xa0/0x140
    [  103.512098]  sock_ioctl+0x2cb/0x3c0
    [  103.512139]  __x64_sys_ioctl+0x84/0xc0
    [  103.512183]  do_syscall_64+0x33/0x80
    [  103.512224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  103.512274] RIP: 0033:0x7f54a9cba427
    ...
    
    Previous versions can be found at:
    v1:
    initial version
        https://lkml.org/lkml/2020/10/28/921
    
    v2:
    do not return from lan743x_ethtool_set_wol if netdev->phydev == NULL, just skip
    the call of phy_ethtool_set_wol() instead.
        https://lkml.org/lkml/2020/10/31/380
    
    v3:
    in function lan743x_ethtool_set_wol:
    use ternary operator instead of if-else sentence (review by Markus Elfring)
    return -ENETDOWN insted of -EIO (review by Andrew Lunn)
    
    Signed-off-by: Sergej Bauer <sbauer@blackbox.su>
    
    Link: https://lore.kernel.org/r/20201101223556.16116-1-sbauer@blackbox.su
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    Linux 5.10.211
    
    Link: https://lore.kernel.org/r/20240227131558.694096204@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: av7110: prevent underflow in write_ts_to_decoder() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Tue Mar 7 11:00:23 2023 +0100

    media: av7110: prevent underflow in write_ts_to_decoder()
    
    [ Upstream commit eed9496a0501357aa326ddd6b71408189ed872eb ]
    
    The buf[4] value comes from the user via ts_play().  It is a value in
    the u8 range.  The final length we pass to av7110_ipack_instant_repack()
    is "len - (buf[4] + 1) - 4" so add a check to ensure that the length is
    not negative.  It's not clear that passing a negative len value does
    anything bad necessarily, but it's not best practice.
    
    With the new bounds checking the "if (!len)" condition is no longer
    possible or required so remove that.
    
    Fixes: fd46d16d602a ("V4L/DVB (11759): dvb-ttpci: Add TS replay capability")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    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: spinand: macronix: Add support for MX35LFxGE4AD [+ + +]
Author: YouChing Lin <ycllin@mxic.com.tw>
Date:   Thu Nov 5 15:23:40 2020 +0800

    mtd: spinand: macronix: Add support for MX35LFxGE4AD
    
    [ Upstream commit 5ece78de88739b4c68263e9f2582380c1fd8314f ]
    
    The Macronix MX35LF2GE4AD / MX35LF4GE4AD are 3V, 2G / 4Gbit serial
    SLC NAND flash device (with on-die ECC).
    
    Validated by read, erase, read back, write, read back and nandtest
    on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host
    (drivers/spi/spi-mxic.c).
    
    Signed-off-by: YouChing Lin <ycllin@mxic.com.tw>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/1604561020-13499-1-git-send-email-ycllin@mxic.com.tw
    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>

 
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: 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>

 
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: 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-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>

 
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>

 
platform/x86: intel-vbtn: Support for tablet mode on HP Pavilion 13 x360 PC [+ + +]
Author: Max Verevkin <me@maxverevkin.tk>
Date:   Tue Nov 24 15:16:52 2020 +0200

    platform/x86: intel-vbtn: Support for tablet mode on HP Pavilion 13 x360 PC
    
    [ Upstream commit 07b211992d6c0d80b321403244d43bbd2d6cf48c ]
    
    The Pavilion 13 x360 PC has a chassis-type which does not indicate it is
    a convertible, while it is actually a convertible. Add it to the
    dmi_switches_allow_list.
    
    Signed-off-by: Max Verevkin <me@maxverevkin.tk>
    Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    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>

 
powerpc/watchpoint: Workaround P10 DD1 issue with VSX-32 byte instructions [+ + +]
Author: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Date:   Fri Nov 6 10:26:50 2020 +0530

    powerpc/watchpoint: Workaround P10 DD1 issue with VSX-32 byte instructions
    
    [ Upstream commit 3d2ffcdd2a982e8bbe65fa0f94fb21bf304c281e ]
    
    POWER10 DD1 has an issue where it generates watchpoint exceptions when
    it shouldn't. The conditions where this occur are:
    
     - octword op
     - ending address of DAWR range is less than starting address of op
     - those addresses need to be in the same or in two consecutive 512B
       blocks
     - 'op address + 64B' generates an address that has a carry into bit
       52 (crosses 2K boundary)
    
    Handle such spurious exception by considering them as extraneous and
    emulating/single-steeping instruction without generating an event.
    
    [ravi: Fixed build warning reported by lkp@intel.com]
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201106045650.278987-1-ravi.bangoria@linux.ibm.com
    Stable-dep-of: 27646b2e02b0 ("powerpc/watchpoints: Annotate atomic context in more places")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/watchpoints: Annotate atomic context in more places [+ + +]
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Tue Aug 29 16:34:57 2023 +1000

    powerpc/watchpoints: Annotate atomic context in more places
    
    [ Upstream commit 27646b2e02b096a6936b3e3b6ba334ae20763eab ]
    
    It can be easy to miss that the notifier mechanism invokes the callbacks
    in an atomic context, so add some comments to that effect on the two
    handlers we register here.
    
    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230829063457.54157-4-bgray@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.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/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/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>

 
s390/cio: fix invalid -EBUSY on ccw_device_start [+ + +]
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Wed Feb 14 16:06:28 2024 +0100

    s390/cio: fix invalid -EBUSY on ccw_device_start
    
    commit 5ef1dc40ffa6a6cb968b0fdc43c3a61727a9e950 upstream.
    
    The s390 common I/O layer (CIO) returns an unexpected -EBUSY return code
    when drivers try to start I/O while a path-verification (PV) process is
    pending. This can lead to failed device initialization attempts with
    symptoms like broken network connectivity after boot.
    
    Fix this by replacing the -EBUSY return code with a deferred condition
    code 1 reply to make path-verification handling consistent from a
    driver's point of view.
    
    The problem can be reproduced semi-regularly using the following process,
    while repeating steps 2-3 as necessary (example assumes an OSA device
    with bus-IDs 0.0.a000-0.0.a002 on CHPID 0.02):
    
    1. echo 0.0.a000,0.0.a001,0.0.a002 >/sys/bus/ccwgroup/drivers/qeth/group
    2. echo 0 > /sys/bus/ccwgroup/devices/0.0.a000/online
    3. echo 1 > /sys/bus/ccwgroup/devices/0.0.a000/online ; \
       echo on > /sys/devices/css0/chp0.02/status
    
    Background information:
    
    The common I/O layer starts path-verification I/Os when it receives
    indications about changes in a device path's availability. This occurs
    for example when hardware events indicate a change in channel-path
    status, or when a manual operation such as a CHPID vary or configure
    operation is performed.
    
    If a driver attempts to start I/O while a PV is running, CIO reports a
    successful I/O start (ccw_device_start() return code 0). Then, after
    completion of PV, CIO synthesizes an interrupt response that indicates
    an asynchronous status condition that prevented the start of the I/O
    (deferred condition code 1).
    
    If a PV indication arrives while a device is busy with driver-owned I/O,
    PV is delayed until after I/O completion was reported to the driver's
    interrupt handler. To ensure that PV can be started eventually, CIO
    reports a device busy condition (ccw_device_start() return code -EBUSY)
    if a driver tries to start another I/O while PV is pending.
    
    In some cases this -EBUSY return code causes device drivers to consider
    a device not operational, resulting in failed device initialization.
    
    Note: The code that introduced the problem was added in 2003. Symptoms
    started appearing with the following CIO commit that causes a PV
    indication when a device is removed from the cio_ignore list after the
    associated parent subchannel device was probed, but before online
    processing of the CCW device has started:
    
    2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
    
    During boot, the cio_ignore list is modified by the cio_ignore dracut
    module [1] as well as Linux vendor-specific systemd service scripts[2].
    When combined, this commit and boot scripts cause a frequent occurrence
    of the problem during boot.
    
    [1] https://github.com/dracutdevs/dracut/tree/master/modules.d/81cio_ignore
    [2] https://github.com/SUSE/s390-tools/blob/master/cio_ignore.service
    
    Cc: stable@vger.kernel.org # v5.15+
    Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
    Tested-By: Thorsten Winkler <twinkler@linux.ibm.com>
    Reviewed-by: Thorsten Winkler <twinkler@linux.ibm.com>
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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/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>

 
seccomp: Invalidate seccomp mode to catch death failures [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Feb 7 20:21:13 2022 -0800

    seccomp: Invalidate seccomp mode to catch death failures
    
    [ Upstream commit 495ac3069a6235bfdf516812a2a9b256671bbdf9 ]
    
    If seccomp tries to kill a process, it should never see that process
    again. To enforce this proactively, switch the mode to something
    impossible. If encountered: WARN, reject all syscalls, and attempt to
    kill the process again even harder.
    
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Will Drewry <wad@chromium.org>
    Fixes: 8112c4f140fa ("seccomp: remove 2-phase API")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smb: client: fix OOB in receive_encrypted_standard() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Sun Feb 11 01:44:42 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:   Sun Feb 11 01:44:44 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:   Sun Feb 11 01:44:43 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>

 
task_stack, x86/cea: Force-inline stack helpers [+ + +]
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Mar 23 20:02:41 2022 +0100

    task_stack, x86/cea: Force-inline stack helpers
    
    [ Upstream commit e87f4152e542610d0b4c6c8548964a68a59d2040 ]
    
    Force-inline two stack helpers to fix the following objtool warnings:
    
      vmlinux.o: warning: objtool: in_task_stack()+0xc: call to task_stack_page() leaves .noinstr.text section
      vmlinux.o: warning: objtool: in_entry_stack()+0x10: call to cpu_entry_stack() leaves .noinstr.text section
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220324183607.31717-2-bp@alien8.de
    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>

 
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: 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>

 
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: 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: 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>

 
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/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
     [ Keep struct branch. ]
    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>

 
x86/uaccess: Implement macros for CMPXCHG on user addresses [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Feb 2 00:49:42 2022 +0000

    x86/uaccess: Implement macros for CMPXCHG on user addresses
    
    [ Upstream commit 989b5db215a2f22f89d730b607b071d964780f10 ]
    
    Add support for CMPXCHG loops on userspace addresses.  Provide both an
    "unsafe" version for tight loops that do their own uaccess begin/end, as
    well as a "safe" version for use cases where the CMPXCHG is not buried in
    a loop, e.g. KVM will resume the guest instead of looping when emulation
    of a guest atomic accesses fails the CMPXCHG.
    
    Provide 8-byte versions for 32-bit kernels so that KVM can do CMPXCHG on
    guest PAE PTEs, which are accessed via userspace addresses.
    
    Guard the asm_volatile_goto() variation with CC_HAS_ASM_GOTO_TIED_OUTPUT,
    the "+m" constraint fails on some compilers that otherwise support
    CC_HAS_ASM_GOTO_OUTPUT.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Co-developed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220202004945.2540433-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86: drop bogus "cc" clobber from __try_cmpxchg_user_asm() [+ + +]
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Jun 7 17:00:53 2022 +0200

    x86: drop bogus "cc" clobber from __try_cmpxchg_user_asm()
    
    commit 1df931d95f4dc1c11db1123e85d4e08156e46ef9 upstream.
    
    As noted (and fixed) a couple of times in the past, "=@cc<cond>" outputs
    and clobbering of "cc" don't work well together. The compiler appears to
    mean to reject such, but doesn't - in its upstream form - quite manage
    to yet for "cc". Furthermore two similar macros don't clobber "cc", and
    clobbering "cc" is pointless in asm()-s for x86 anyway - the compiler
    always assumes status flags to be clobbered there.
    
    Fixes: 989b5db215a2 ("x86/uaccess: Implement macros for CMPXCHG on user addresses")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Message-Id: <485c0c0b-a3a7-0b7c-5264-7d00c01de032@suse.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>